-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Node does not commit new sealing work when it should #586
Comments
Well ! I've tried a few things, such as restoring --miner.notify and trying every version between v1.12.12 and v1.12.16. So now I feel that the problem is closely related to peering, maybe the rate limiting system needs tweaking ? |
Thanks for the thoughtful report! I'll look at it right away and get back to you. |
@Ewemek I've identified what I believe to be the problem and am drafting a patch.
This is the workaround I would have offered, and with it you shouldn't see any more spurious pauses. Only a minute's pause or so should do. If you'd like, please email me at [email protected] and we can continue this conversation directly and in more depth. |
Hi, I'm a pool operator and we've just updated from
v1.12.12
tov1.12.16
. We now face a problem where the node commits new sealing work very rarely. The pool is calling getWork() very often but still gets the same work, until a new one is committed. As you can see in the logs, the node did not generate a work for heights 18,717,898 to 18,717,890 (included) although we did ask for a new job in the meantime.We have enough peers (~170) and relevant options we use are:
--mine --miner.threads 0
. We recently dropped the--miner.notify
maybe this is related.But after investigation, I feel that our problem is related to this commit: 6f51aed. To be more specific, I have the impression that the mining process get stopped but never gets started back. In particular, the
shouldStart
is never actually used, I guess this is a regression but I can't know for sure it's related to my problem.System information
Geth version:
v1.12.16
Expected behaviour
New work should be committed at least when a block for a new height is processed.
Actual behaviour
Node is not committing new works when it should.
Steps to reproduce the behaviour
Run v1.12.16 with following options:
--mine --miner.threads 0
Backtrace
The text was updated successfully, but these errors were encountered: