Quote from: th3.r00t on April 08, 2016, 04:41:38 PM

Quote from: joblo on April 08, 2016, 04:29:57 PM

You missed the release announcement, it's hash count, not rate.

So, if I understand correctly...

Code:

accepted: 135/135 (100%), 23.40 MH, 856.04 kH/s yes!

I should read this like this:
cpuminer submited a share with 856.04 kH/s, which was produced by 23.40 Mhashes done by cpu.

Is that correct?
And why do we need so much clutter on the reporting side?

Yes and you can easilly calculate your effective hash rate by dividing the hash count
by the time since the last submission. Comparing with the miner hashrate will give you
an efficiency factor for that share.

You're opinion is noted. I'm not the first to implement this but I'll go with the flow.

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.