Hash internal verification on last job before epoch change causes delays

[AndreaLanfranchi]

Describe the bug If last job before switch from two valid epochs produces a solution which needs to be verified (i.e. --noeval is not set) the verification process takes seconds instead of milliseconds.

Additional context This is actually an issue shared among ethminer and ethash library by @chfast Epoch context is held into ethash library in a static_thread pointer which gets updated on every epoch change. On epoch change pointer's structure is immediately valued with epoch's light cache (which requires some time). Ethminer has only one thread which retrieves epoch context (for dispatch to miners) and hash verification (when --noeval is not set). In such it may happen this :

• epoch 1 is detected and dispatched to miners adn they begin to hash
• new stratum package carries new epoch 2 while miners are still hashing on previous epoch
• Farm thread updates epoch context with new data for epoch 2 (including light cache) and dispatch context to all miners
• a miner completes is last batch and finds a solution on last job of previous epoch 1 and submits to farm
• farm invokes verify from ethash passing epoch number 1 as verification context
• ethash library reverts back pointer for epoch_context to epoch 1 recreating light cache once again and eventually verifies hash ( delay here )

Additionally epoch context pointer is now set to epoch 1 (should be 2) as long as a new verification for valid hash on epoch 2 is invoked.

Not a show stopper nor a big problem (in a case like that solution would be accounted for sure as stale) but something to take into account if/when some logic revision will be performed

[chfast]

Hi Andrea,

This "managed" API from ethash library is optional. It was added for convenience as I expected it would reflect common context handling strategy. I'm open for suggestions how to improve it.

But ethminer can use the main API where it has to handle contexts on its own. It wouldn't be a problem to keep one future ethash context precomputed. Provided someone wants to implement it.

[AndreaLanfranchi]

Hi Pawel, of course this is not an accusation. I'm aware of possibility to have a cache of contexts but also am aware that needs some further refactoring on ethminer.

Just wanted to signal that, as I stumbled into this issue, that this may happen. I reiterate is nothing that voids ethminer or ethash library.

I'd leave the issue open for future reference in case someone has some spare time to spend on the project.

[chfast]

of course this is not an accusation

I never felt as it were.