Quote from: vh on April 22, 2019, 05:45:27 AM

Just double checking everything, I notice I'm counting hw_errors, nonces after flush events. Not significant, but will do better to only include the ones that pass test_nonce.

As you mentioned below it may well just be the variance of a small sample.
I just listed the previous options coz I saw the same effect with rockmoney so thought of possible reasons if we kept getting an underestimate.

Quote from: vh on April 22, 2019, 05:45:27 AM

Yeah, every time a nonce is found, the driver reports upstream (device diff x 2^32).

To perfectly track with pool side value, I would probably need to go straight with the formula provided, using pool diff instead of device diff and not count lower diff values.

No, I don't think you need to match the pool, just ensure you are counting nonces based on the nonce difficulty in the chip
(and valid nonces)

One of the things I had to rewrite when I fixed the Bitmain S1/S2/S3 driver was the nonce difficulty.
As I mentioned previously, I'm not sure if BM handle that in the FPGA or the actual chip, but I sent a power of 2 work difficulty from cgminer to the FPGA.
In your case if you are actually mining internally at 1 Diff (I'd hope not) then yeah each nonce validly estimates as PoW of 2^32
I would presume that internally (i.e. not cgminer) it's mining at higher than 1 Diff also, since the USB bus would be getting hit pretty hard if you had a few of these all mining at 1 Diff.
So e.g. for 2000 Diff on the pool that would be 1024 Diff internally.
I set it in my version of the driver pretty clearly with comments

lowestdiffbits in https://github.com/vthoang/cgminer/blob/r606/driver-bitmain.c#L534

Quote from: vh on April 22, 2019, 05:45:27 AM

As it is, I'm thinking I may have requested the pool difficulty to be a tad on the too high side:

Given the lower number of total accepted shares, it's still within the margin of error:

Confidence Level:
Margin of error for sample size = 1/sqrt(n), 1/sqrt(661) = 3.8%

Next test set:


Worker  : R606-d0s5r002
Device  : Lab Workbench
Setting : 5 (Default for devices)
Run     : 12 Hours @ kano.is, AsicBoost on.  (heading towards 24h)

http://23.108.83.14/images/R606-d0s2r002-00.JPG

Duration: 43410
Total difficulty of accepted shares: 9444098.0
Calculated hash rate: Diff * 2^32 / Time = 9444098 * 2^32 / 43410 = 934GH/s

934 vs 937 = 99.7%
Margin of error for sample size = 1/sqrt(n), 1/sqrt(3777) = 1.6%

I'll post the final stats for this one if it survives the full 24hr without a hiccup.

Heh, awesome when people understand what they are saying

Yep when you've done, I'll go back and add up everything on the pool side and spit out another number for this run.

Quote from: rockmoney on April 22, 2019, 04:43:42 AM

Our dealer sample R606 has been mining fairly consistently on kano's pool for the past few days now, using the latest cgminer vh build.

@kano - feel free to collect any data from that same worker of mine you used before, and share with vh if needed.

OK, stats (again) right now from a single non-stop client on the pool still running at the moment:

This one last started/connected at 2019-04-21 04:21:34+00 and is still mining, so about 28 hours.
I'll add up until the previous hour: 2019-04-22 07:59:59 since it is currently mining and I run the stats a few times
(and the pool logs hourly so the current hour log will keep changing)

Last share during the previous hour is 2019-04-22 07:59:55+00
So elapsed time is 1day 3hrs 38mins 21sec = 99501sec
Total Accepted shares is: 5124 (so this run should be pretty accurate)
Total Accepted Diff is: 20998152.0 (every share was 4098 Diff)

Hash rate is Diff * 2^32 / Time = 20998152.0 * 2^32 / 99501 = 906.4GH/s

default (20000000) shares = 1221
AB shares = 3903