RESOLVED: Seems this bug is still hanging around.....
Forum rules
Welcome to the System Support forum! Encounter a problem related to the pool? Post your issue here and we will help you out.
Keep in mind that the forums are monitored by PROHASHING less closely than the official support channels, so if you have a pressing issue, please submit an official support ticket so that our Support Analyst can look into your issue in a timely manner.
We cannot answer financial questions related to your account on a public forum, so those questions should always be submitted through the orange Support button on prohashing.com/about.
For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
Welcome to the System Support forum! Encounter a problem related to the pool? Post your issue here and we will help you out.
Keep in mind that the forums are monitored by PROHASHING less closely than the official support channels, so if you have a pressing issue, please submit an official support ticket so that our Support Analyst can look into your issue in a timely manner.
We cannot answer financial questions related to your account on a public forum, so those questions should always be submitted through the orange Support button on prohashing.com/about.
For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
RESOLVED: Seems this bug is still hanging around.....
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.
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.
Last edited by GenTarkin on Fri Jul 15, 2016 9:07 pm, edited 2 times in total.
- Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Seems this bug is still hanging around.....
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.....
Yeah, and if I had to estimate ... this happens about a good 10-20% of the time.
- CritterDog
- Posts: 267
- Joined: Tue Feb 23, 2016 11:21 am
Re: Seems this bug is still hanging around.....
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.....
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.....
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.
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.
- Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Seems this bug is still hanging around.....
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.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.
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.
- Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Seems this bug is still hanging around.....
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.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..
Re: Seems this bug is still hanging around.....
Steve Sokolowski wrote: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.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.
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.....
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.
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.