I'm not sure how much value it adds but it helps identify if you're throwing away
wasted hash. It's really the hash count that matters and the time, from the pool's
point of view, it took to produce it. The hashrate displayed by the miner
is a derivative value based on it's perception of the scan period.
If the CPU is throwing away hash the periods won't match and the CPU will display
an eroneously high hashrate. I could put in code to display when this occurs but it
would be in the critical code path and would affect performance. The current method,
though perhaps more verbose, is implemented off the critical path.
wasted hash. It's really the hash count that matters and the time, from the pool's
point of view, it took to produce it. The hashrate displayed by the miner
is a derivative value based on it's perception of the scan period.
If the CPU is throwing away hash the periods won't match and the CPU will display
an eroneously high hashrate. I could put in code to display when this occurs but it
would be in the critical code path and would affect performance. The current method,
though perhaps more verbose, is implemented off the critical path.
I understand the idea now.
IMHO, It seems good to have this, but somewhere else, like in debug maybe?
I definetely don't want to lose performance, so if it's too much work and/or affect the miner itself, just leave it there.
I'm not sure why you're so concerned about that particular bit of output. If verbosity is your issue you should use --quiet
which suppresses the per-thread output.
Have you expresed your concerns to Wolf0? The hashcount is in his hodlminer too. Like I said I don't really have
an opinion about it but I'll go with the flow. If Wolf0 backs it out and no one else implements it I will back out too.
Edit: If this is realy important to you I can build a custom version with the output to your exact specifications, for a fee.
