Prohashing Mining Pool Forums

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.

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.

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.

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.

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?

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.

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.

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 =)

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


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)

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.