RESOLVED: Seems this bug is still hanging around.....

Encounter a problem related to the pool or have a request for a feature? Post your issue here and we will help you out.
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.
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Seems this bug is still hanging around.....

Post by Steve Sokolowski » Mon Jul 11, 2016 5:31 pm

GenTarkin wrote: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.
We added some code to record work restarts into a table so that they can be analyzed during the week. We'll use your account as an example.

I'll get back to you soon to let you know what we find out.
GenTarkin
Posts: 135
Joined: Wed Dec 02, 2015 10:52 am

Re: Seems this bug is still hanging around.....

Post by GenTarkin » Mon Jul 11, 2016 8:10 pm

Steve Sokolowski wrote:
GenTarkin wrote: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.
We added some code to record work restarts into a table so that they can be analyzed during the week. We'll use your account as an example.

I'll get back to you soon to let you know what we find out.

Awesome! Guess we will find out. Afterall, maybe its just bfgminer being retarded.
User avatar
Chris Sokolowski
Site Admin
Posts: 945
Joined: Wed Aug 27, 2014 12:47 pm
Location: State College, PA

Re: Seems this bug is still hanging around.....

Post by Chris Sokolowski » Tue Jul 12, 2016 12:22 am

Does the "old work" apply to the merge-mined coins? We do need to send work refreshes to prevent miners from disconnecting, and we will send stale merge-mined work while the primary coins is still valid so that we don't cause the miner to restart.
GenTarkin
Posts: 135
Joined: Wed Dec 02, 2015 10:52 am

Re: Seems this bug is still hanging around.....

Post by GenTarkin » Tue Jul 12, 2016 1:50 pm

Chris Sokolowski wrote:Does the "old work" apply to the merge-mined coins? We do need to send work refreshes to prevent miners from disconnecting, and we will send stale merge-mined work while the primary coins is still valid so that we don't cause the miner to restart.
You asking me? I have no way of knowing.
All I know is last night I watched the pool set my worker(pool webgui) to LTC from a different coin, yet my Titan was stuck on the old coin for minutes and never went to LTC. Then the pool worker switched to a diff coin and finally my Titan switched to the matching coin.
It happens often. Same example as in the OP.

When this happens, bfgminer always states "pool x is issuing work for old block" ... it rarely states "pool x caught up to current block" in these cases.
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Seems this bug is still hanging around.....

Post by Steve Sokolowski » Tue Jul 12, 2016 7:44 pm

GenTarkin wrote:
Chris Sokolowski wrote:Does the "old work" apply to the merge-mined coins? We do need to send work refreshes to prevent miners from disconnecting, and we will send stale merge-mined work while the primary coins is still valid so that we don't cause the miner to restart.
You asking me? I have no way of knowing.
All I know is last night I watched the pool set my worker(pool webgui) to LTC from a different coin, yet my Titan was stuck on the old coin for minutes and never went to LTC. Then the pool worker switched to a diff coin and finally my Titan switched to the matching coin.
It happens often. Same example as in the OP.

When this happens, bfgminer always states "pool x is issuing work for old block" ... it rarely states "pool x caught up to current block" in these cases.
Could you try to confirm if the following happened:

1. You were assigned to a coin with a long block time, like litecoins
2. A very profitable coin came up, so you switched to that coin for a few seconds until the next block was found
3. That coin is no longer more profitable than the coin with a long block time, like litecoins, so you switched back

My current theory is that the miners think that the block which you switched back to is stale because the difficult coin height is usually lower than the block height of the easy network. The block isn't stale; there were no blocks found since the last switch, so it's still valid and it is the most profitable work available. But the miner decides that, because this would never happen if you were mining a single coin, the pool is incorrectly configured and incorrectly takes matters into its own hands, wasting effort.

Is that what is happening? If so, could you modify your firmware to account for the situation when the same block is resent to the miner after a block in the middle?
GenTarkin
Posts: 135
Joined: Wed Dec 02, 2015 10:52 am

Re: Seems this bug is still hanging around.....

Post by GenTarkin » Tue Jul 12, 2016 8:15 pm

Steve Sokolowski wrote:
GenTarkin wrote:
Chris Sokolowski wrote:Does the "old work" apply to the merge-mined coins? We do need to send work refreshes to prevent miners from disconnecting, and we will send stale merge-mined work while the primary coins is still valid so that we don't cause the miner to restart.
You asking me? I have no way of knowing.
All I know is last night I watched the pool set my worker(pool webgui) to LTC from a different coin, yet my Titan was stuck on the old coin for minutes and never went to LTC. Then the pool worker switched to a diff coin and finally my Titan switched to the matching coin.
It happens often. Same example as in the OP.

When this happens, bfgminer always states "pool x is issuing work for old block" ... it rarely states "pool x caught up to current block" in these cases.
Could you try to confirm if the following happened:

1. You were assigned to a coin with a long block time, like litecoins
2. A very profitable coin came up, so you switched to that coin for a few seconds until the next block was found
3. That coin is no longer more profitable than the coin with a long block time, like litecoins, so you switched back

My current theory is that the miners think that the block which you switched back to is stale because the difficult coin height is usually lower than the block height of the easy network. The block isn't stale; there were no blocks found since the last switch, so it's still valid and it is the most profitable work available. But the miner decides that, because this would never happen if you were mining a single coin, the pool is incorrectly configured and incorrectly takes matters into its own hands, wasting effort.

Is that what is happening? If so, could you modify your firmware to account for the situation when the same block is resent to the miner after a block in the middle?

Im confused, the steps you outlined is what *should* be happening as indicated by the webgui worker.
In reality whats happening on the miner itself is, steps 1 & 2 work fine but when bfgminer is issued a switch to go back to litecoins(as per your example). It doesnt happen, it states "pool x is issuing work for old block" and the miner keeps mining the coin which is no longer profitable ... until another work switch command is given by the pool(either because of new block on old coin, new coin or new coin switch).
I cant mess around w/ bfgminer or titan driver thats in bfgminer, so I cant change this in firmware.
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Seems this bug is still hanging around.....

Post by Steve Sokolowski » Wed Jul 13, 2016 9:07 am

GenTarkin wrote:
Steve Sokolowski wrote:
GenTarkin wrote:
You asking me? I have no way of knowing.
All I know is last night I watched the pool set my worker(pool webgui) to LTC from a different coin, yet my Titan was stuck on the old coin for minutes and never went to LTC. Then the pool worker switched to a diff coin and finally my Titan switched to the matching coin.
It happens often. Same example as in the OP.

When this happens, bfgminer always states "pool x is issuing work for old block" ... it rarely states "pool x caught up to current block" in these cases.
Could you try to confirm if the following happened:

1. You were assigned to a coin with a long block time, like litecoins
2. A very profitable coin came up, so you switched to that coin for a few seconds until the next block was found
3. That coin is no longer more profitable than the coin with a long block time, like litecoins, so you switched back

My current theory is that the miners think that the block which you switched back to is stale because the difficult coin height is usually lower than the block height of the easy network. The block isn't stale; there were no blocks found since the last switch, so it's still valid and it is the most profitable work available. But the miner decides that, because this would never happen if you were mining a single coin, the pool is incorrectly configured and incorrectly takes matters into its own hands, wasting effort.

Is that what is happening? If so, could you modify your firmware to account for the situation when the same block is resent to the miner after a block in the middle?

Im confused, the steps you outlined is what *should* be happening as indicated by the webgui worker.
In reality whats happening on the miner itself is, steps 1 & 2 work fine but when bfgminer is issued a switch to go back to litecoins(as per your example). It doesnt happen, it states "pool x is issuing work for old block" and the miner keeps mining the coin which is no longer profitable ... until another work switch command is given by the pool(either because of new block on old coin, new coin or new coin switch).
I cant mess around w/ bfgminer or titan driver thats in bfgminer, so I cant change this in firmware.
If it's easy to find this bug, could you pay attention to the exact time, down to the second, when it occurred, and report that to me along with the worker_name that had the work assigned? Use time.gov as your clock.
GenTarkin
Posts: 135
Joined: Wed Dec 02, 2015 10:52 am

Re: Seems this bug is still hanging around.....

Post by GenTarkin » Wed Jul 13, 2016 1:58 pm

Steve Sokolowski wrote:
GenTarkin wrote:
Steve Sokolowski wrote:
Could you try to confirm if the following happened:

1. You were assigned to a coin with a long block time, like litecoins
2. A very profitable coin came up, so you switched to that coin for a few seconds until the next block was found
3. That coin is no longer more profitable than the coin with a long block time, like litecoins, so you switched back

My current theory is that the miners think that the block which you switched back to is stale because the difficult coin height is usually lower than the block height of the easy network. The block isn't stale; there were no blocks found since the last switch, so it's still valid and it is the most profitable work available. But the miner decides that, because this would never happen if you were mining a single coin, the pool is incorrectly configured and incorrectly takes matters into its own hands, wasting effort.

Is that what is happening? If so, could you modify your firmware to account for the situation when the same block is resent to the miner after a block in the middle?

Im confused, the steps you outlined is what *should* be happening as indicated by the webgui worker.
In reality whats happening on the miner itself is, steps 1 & 2 work fine but when bfgminer is issued a switch to go back to litecoins(as per your example). It doesnt happen, it states "pool x is issuing work for old block" and the miner keeps mining the coin which is no longer profitable ... until another work switch command is given by the pool(either because of new block on old coin, new coin or new coin switch).
I cant mess around w/ bfgminer or titan driver thats in bfgminer, so I cant change this in firmware.
If it's easy to find this bug, could you pay attention to the exact time, down to the second, when it occurred, and report that to me along with the worker_name that had the work assigned? Use time.gov as your clock.
Um.... Ive already provided that in the OP screenshot. But Ill do it again =)
GenTarkin
Posts: 135
Joined: Wed Dec 02, 2015 10:52 am

Re: Seems this bug is still hanging around.....

Post by GenTarkin » Wed Jul 13, 2016 2:46 pm

Alright, heres another example. Its been doing this a bunch today now.
Image

Starting at time: 11:34:31 am DST(PST)
Titan was mining a diff 137 coin (dont ask me what this is because it wasnt what the pool worker said it should be)
Then the pool worker was switched to GameCredit and bfgminer shows the diff switch to 1.15k (which is correct)
Then the pool worker switched to LTC yet bfgminer shows the message "pool is issuing work for an old block" and bfgminer gets stuck mining GameCredit when it should be mining what the pool worker says .. LTC(Diff should show 42.5k in bfgminer)
GenTarkin
Posts: 135
Joined: Wed Dec 02, 2015 10:52 am

Re: Seems this bug is still hanging around.....

Post by GenTarkin » Wed Jul 13, 2016 3:27 pm

Question ... is the live worker status a "Verified Status?" as-in when it says Im mining a specific coin, has it verified that against the shares my miner returns or is the live worker status just a "miner supposed to be mining this coin so we are going to assume it is..." type?
If it was the former then its likely its just the way bfgminer is reporting its work for some reason and its lieing, if its the latter then I guess its still possible that the miner is indeed mining the wrong coin as I suspect.
Locked