[Mining] Clear the calculated hash speed at mining start.#966
[Mining] Clear the calculated hash speed at mining start.#966CaveSpectre11 merged 1 commit intoVeil-Project:masterfrom
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.
|
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
setminingalgoon the same algorithm.