Page 1 of 5
RESOLVED: Seems this bug is still hanging around.....
Posted: Wed Jul 06, 2016 4:25 pm
by GenTarkin
I mentioned this months ago, nothing seems to have been done about it. This time I took screenshots.
As you can see, the bfgminer network difficulty does not reflect what coins prohashing says I should be mining.
Its as if bfgminer sometimes is never issued a work/coin switch. This can go on for minutes sometimes(bfgminer will be mining a coin that doesnt agree w/ the prohashing webgui). It seems it fixes itself once the pool issues another coin switch. But mining on the wrong coin could cause a huge loss of profit.
Re: Seems this bug is still hanging around.....
Posted: Wed Jul 06, 2016 5:51 pm
by Steve Sokolowski
Thanks. This picture helps a lot. I'm investigating it now, but the reason we were never able to figure it out before is because it is so difficult. Hopefully these pictures will shed new light and I'll be able to get back to you by the weekend with more information.
Re: Seems this bug is still hanging around.....
Posted: Wed Jul 06, 2016 7:34 pm
by GenTarkin
Yeah, and if I had to estimate ... this happens about a good 10-20% of the time.
Re: Seems this bug is still hanging around.....
Posted: Thu Jul 07, 2016 1:37 am
by CritterDog
I dont know if this is related to your titans. But I notice on my A2 110Mhs machines the GUI on ProHash does not keep up with shares submitted on my cgminer program. Cgminer will sometimes show up to 100 more share blocks submitted then the pool shows. But when the pool switches coins it seems to catch up and match. But they do not ever stay in sync constant. cgminer is submitting all the time where as the pool seems like its stuck and does not reflect the same share count until it switches coins. Then we start the process over..
Re: Seems this bug is still hanging around.....
Posted: Thu Jul 07, 2016 11:24 am
by GenTarkin
CritterDog wrote:I dont know if this is related to your titans. But I notice on my A2 110Mhs machines the GUI on ProHash does not keep up with shares submitted on my cgminer program. Cgminer will sometimes show up to 100 more share blocks submitted then the pool shows. But when the pool switches coins it seems to catch up and match. But they do not ever stay in sync constant. cgminer is submitting all the time where as the pool seems like its stuck and does not reflect the same share count until it switches coins. Then we start the process over..
Yeah, Im not talking about the share submission stat. Thats not as huge a deal as miners potentially mining the wrong coins entirely for half a minute or more.
Re: Seems this bug is still hanging around.....
Posted: Thu Jul 07, 2016 11:31 am
by GenTarkin
Quick question to the devs...
Does your coin switching algo consider coins' blockchain block orphan rate?
Because when I watch the live coin status list it seems sometimes coins get switched to when their profitability is only slightly higher then the current coin but the switched to coin has a far greater orphan rate which would end up w/ a net loss in profitability.
Re: Seems this bug is still hanging around.....
Posted: Sat Jul 09, 2016 4:08 pm
by Steve Sokolowski
GenTarkin wrote:Quick question to the devs...
Does your coin switching algo consider coins' blockchain block orphan rate?
Because when I watch the live coin status list it seems sometimes coins get switched to when their profitability is only slightly higher then the current coin but the switched to coin has a far greater orphan rate which would end up w/ a net loss in profitability.
The orphan rates are considered as part of the payout rate. The "profitability" statistics displayed in the chart include the orphan rate in their considerations. However, miners are usually not reassigned to coins that are slightly more profitable; that only happens when a new block is found. Otherwise, the work restart losses would exceed any gains.
In other news, I discovered that there are some cases when miners were mining stale blocks. I wasn't able to determine how that happened, but I added a workaround to reassign those miners when that problem occurs. Let me know if you see this problem happen again.
Re: Seems this bug is still hanging around.....
Posted: Sat Jul 09, 2016 4:09 pm
by Steve Sokolowski
CritterDog wrote:I dont know if this is related to your titans. But I notice on my A2 110Mhs machines the GUI on ProHash does not keep up with shares submitted on my cgminer program. Cgminer will sometimes show up to 100 more share blocks submitted then the pool shows. But when the pool switches coins it seems to catch up and match. But they do not ever stay in sync constant. cgminer is submitting all the time where as the pool seems like its stuck and does not reflect the same share count until it switches coins. Then we start the process over..
The "share count" is an estimate of how many shares have been processed to that point, and it may be a few seconds behind. The profit earned from shares isn't calculated immediately; higher priority tasks include submitting blocks and reassigning work. You shouldn't be concerned with the "share count" number.
Re: Seems this bug is still hanging around.....
Posted: Sun Jul 10, 2016 2:22 pm
by GenTarkin
Steve Sokolowski wrote:GenTarkin wrote:Quick question to the devs...
Does your coin switching algo consider coins' blockchain block orphan rate?
Because when I watch the live coin status list it seems sometimes coins get switched to when their profitability is only slightly higher then the current coin but the switched to coin has a far greater orphan rate which would end up w/ a net loss in profitability.
The orphan rates are considered as part of the payout rate. The "profitability" statistics displayed in the chart include the orphan rate in their considerations. However, miners are usually not reassigned to coins that are slightly more profitable; that only happens when a new block is found. Otherwise, the work restart losses would exceed any gains.
In other news, I discovered that there are some cases when miners were mining stale blocks. I wasn't able to determine how that happened, but I added a workaround to reassign those miners when that problem occurs. Let me know if you see this problem happen again.
The issue I displayed in OP still happens, in fact now it carries across multiple coin switches =( ... maybe the live worker just doesnt switch properly on the webgui? I dont know but ... today my Titan would be mining a net diff 240 coin and a coin w/ that diff wouldnt even be listed in the top 25 coins mined on bottom of graphs page, meanwhile my live worker shows it should be mining a diff 111 coins(megacoin) ... then my Titan would switch to a diff 10 randomly and the live worker sill showed megacoin! Then after a good 30 seconds or so ... the live worker and my titan would finally switch to a coin they agreed on lol!
Re: Seems this bug is still hanging around.....
Posted: Sun Jul 10, 2016 2:36 pm
by GenTarkin
Further observation:
I noticed when the miner gets "stuck" like shown in OP on a particular coin.... bfgminer says "pool 0 is issuing work for an old block"
So it shows a different block hash(Im assuming the hash of the actual block I should be mining), but bfgminer is still stuck on working on the old block(coin) which is reflected by the block hash shown in the message I just quoted and the net diff shown in bfgminer.