-
Notifications
You must be signed in to change notification settings - Fork 90
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
[Mining] Clear the calculated hash speed at mining start. #966
Conversation
This avoids having the hash speed affected by a gap in mining or a change in the number of mining threads, without requiring users to call `setminingalgo` on the same algorithm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 55c60f8
utACK 55c60f8 |
I've got this on startup (after a power outage) on #966 and #967. On the first one,
It's a different dbus number on the second one. Not sure if this happened when I started them up yesterday. (Possibly.) I don't remember seeing this previously, but I don't see anything relevant to it in the code changes. ... 6-year old post related to Qt, may be relevant. ... This does not prevent the Qt wallet starting up, though. Come to think of it, I think this is unrelated to this PR, so I will put it in a new issue, if I don't find the same already there. |
79102e2 [Mining] Track a recent mining hashrate. (Zannick) Pull request description: ### Issue In `getmininginfo`, it isn't clear that it computes the `hashspeed` by counting all hashes made since the start of hashing and dividing by the elapsed time, which tends to smooth out fluctuations but also (prior to #966) can include periods of time when the miner is off or the number of threads different. ### Solution This adds a field to `getmininginfo` called `hashspeed_recent` which is a sum of each thread's most recent round of hashing (where a round is either a fixed number of hashes or ends with a new block). ### Tested On regtest chain with sha256d and randomx. Tree-SHA512: e2d73e32d50ca201c7ac4240c7cfd0a6892b34620cdde9c3b23036810c9dc539d402cacb14f221de99b26ba2738fb412903c932431b4b5ece6cad0a80d0c695b
This avoids having the hash speed affected by a gap in mining
or a change in the number of mining threads, without requiring
users to call
setminingalgo
on the same algorithm.