Prohashing Mining Pool Forums

CritterDog wrote:30 mins later Mega looking much better restart still a tad high I will give it some more time

Hey Critterdog, what is your work restart delay w/ an A2?
You set your vardiff really high. I use 8192 on Titan, My work restart delay averages like .75-.99 seconds as measured by prohashing.

yep it seems I get better results if i set the d= argument on static. Seems I get less blocks set on dynamic...

GenTarkin wrote:

CritterDog wrote:30 mins later Mega looking much better restart still a tad high I will give it some more time

Hey Critterdog, what is your work restart delay w/ an A2?
You set your vardiff really high. I use 8192 on Titan, My work restart delay averages like .75-.99 seconds as measured by prohashing.

When you say Vardiff you mean the Difficulty? I normally set my A2 on 4096.. I just tried not setting it and let prohash set it auto but it was causeing high restarts normally my restarts stay under 1 sec. But if I dont set it myself it goes above a second on restart

Now I am down to .58 sec on restart set to 4096 on the A2 sits at about 103Mhs most the time

Are you sure that the change was caused by the static difficulty, or was it possibly caused by the optimization that Chris made a short while ago?

Steve Sokolowski wrote:Are you sure that the change was caused by the static difficulty, or was it possibly caused by the optimization that Chris made a short while ago?

Well, I just tried 16384 from my normal 8192 on Titan and my work restart delay went from usually .775sec-1sec to over 1second consistently. Its now at 1.05+ consistently.
So, it seems higher vardiff = a measured higher work restart delay. Which...shouldnt be the case.

Hrm...well now I dont know what to think. Is the restart delay a figure of the entire mining session(since that worker connected?) or is it a short term measurement. Because, came back to my webgui on pool after a few hours of mining @ 16384 and now it shows restart delay at .685 for the live worker. Its one of the lowest measurements Ive seen yet.
Also, is a penalty below 1.000 a good or bad thing. Its at .997...

Im still surprised at how bad my rejects are. This pool used to be right around 1% for me. Now after all the "code enhancements" within the past few months...its 4x-5x worse =( at 4-5% rejects on average.

Steve Sokolowski wrote:Are you sure that the change was caused by the static difficulty, or was it possibly caused by the optimization that Chris made a short while ago?

I am not sure.. I changed the A2 to 8192 and it seems about the same as 4096.. this A2 usually stays around 103-106 Mhs on litecoinpool.. My restart times here are .50 to .80 sec normal.. But I did notice when it mines certain coins sometimes the A2 takes a hit and the hashrate drops sometimes all the way down in the 80-85Mhs until it switches off the coin then it will jump back up but sometimes it fails to jump back up and I usually do a restart. The coin I noticed it was doing this most on was Casinocoin and a few others but I really noticed Casino coin it did not like for some reason.

Now since the changes it seems steady. On the A2 I am sitting steady at 103.50Mhs which is about as good as I can get off this.
Average mining efficiency now states 99.60. The best I have seen is about 99.80 but I have 5 total miners running. So far So good as of now.
Been sitting on Annoncoin a lot but the test for me is when I see Casinocoin pop up if my A2 stays at 103Mhs then thats a big improvement.

But yes I dont want to speak to soon but looks like whatever you did helped my overall hashrate

Just hit Casinocoin twice and it stayed at 104Mhs so looks better as of now and now also I am hitting 106Mhs on the A2

GenTarkin wrote:

Steve Sokolowski wrote:Are you sure that the change was caused by the static difficulty, or was it possibly caused by the optimization that Chris made a short while ago?

Well, I just tried 16384 from my normal 8192 on Titan and my work restart delay went from usually .775sec-1sec to over 1second consistently. Its now at 1.05+ consistently.
So, it seems higher vardiff = a measured higher work restart delay. Which...shouldnt be the case.

Hrm...well now I dont know what to think. Is the restart delay a figure of the entire mining session(since that worker connected?) or is it a short term measurement. Because, came back to my webgui on pool after a few hours of mining @ 16384 and now it shows restart delay at .685 for the live worker. Its one of the lowest measurements Ive seen yet.
Also, is a penalty below 1.000 a good or bad thing. Its at .997...

Im still surprised at how bad my rejects are. This pool used to be right around 1% for me. Now after all the "code enhancements" within the past few months...its 4x-5x worse =( at 4-5% rejects on average.

It looks like we got CritterDog's issues fixed, so I think we've made progress.

It would make sense that the work restart delay would be higher for a higher difficulty, because the work restart delay is the time until your miner submits the first share after being sent work. With a higher difficulty, you would expect it to be higher. However, for normal miners, the difference shouldn't be significant enough to result in a penalty. If you use Titans, they have work restart times of 4s or higher, and that's when they get penalized.

.997 means that your miners are being assigned to a less efficient coin 0.3% of the time, but they are being assigned to those coins because if they were assigned to the most efficient coin, they would lose money. .997 is probably better than average - the average is .98, I think, which means you're getting a bonus.

I'll have Chris investigate the reject rate. What is the most common cause of rejects for you? Are they stale shares?

Steve Sokolowski wrote:

GenTarkin wrote:

Steve Sokolowski wrote:Are you sure that the change was caused by the static difficulty, or was it possibly caused by the optimization that Chris made a short while ago?

Well, I just tried 16384 from my normal 8192 on Titan and my work restart delay went from usually .775sec-1sec to over 1second consistently. Its now at 1.05+ consistently.
So, it seems higher vardiff = a measured higher work restart delay. Which...shouldnt be the case.

Hrm...well now I dont know what to think. Is the restart delay a figure of the entire mining session(since that worker connected?) or is it a short term measurement. Because, came back to my webgui on pool after a few hours of mining @ 16384 and now it shows restart delay at .685 for the live worker. Its one of the lowest measurements Ive seen yet.
Also, is a penalty below 1.000 a good or bad thing. Its at .997...

Im still surprised at how bad my rejects are. This pool used to be right around 1% for me. Now after all the "code enhancements" within the past few months...its 4x-5x worse =( at 4-5% rejects on average.

It looks like we got CritterDog's issues fixed, so I think we've made progress.

It would make sense that the work restart delay would be higher for a higher difficulty, because the work restart delay is the time until your miner submits the first share after being sent work. With a higher difficulty, you would expect it to be higher. However, for normal miners, the difference shouldn't be significant enough to result in a penalty. If you use Titans, they have work restart times of 4s or higher, and that's when they get penalized.

.997 means that your miners are being assigned to a less efficient coin 0.3% of the time, but they are being assigned to those coins because if they were assigned to the most efficient coin, they would lose money. .997 is probably better than average - the average is .98, I think, which means you're getting a bonus.

I'll have Chris investigate the reject rate. What is the most common cause of rejects for you? Are they stale shares?

Ah, that makes sense. I didnt realize it was timed from work restart request sent to receiving first share from miner. If its based on first share then yeahp that explains the longer time. But...thats not really an accurate way to gauge work restart delay =/
If my Titan averages 1s "measured work restart delays" that means, from the time switching to another coin, to the pool receiving the 1st share ... my Titan averages 1s doing that, which is well below your mentioned 4s ...
I also watch bfgminer and between coin switches...there is hardly ever a delay that long for the first share acceptance(especially if I set vardiff at like 4096/8192.

Yes, my share rejects are from "stale shares"