Topic: GekkoScience Terminus R606 750GH (up to 1TH) quiet miner, now shipping - page 23. (Read 11704 times)

200AH  Lifo4 batteries..  2 200watt panels and 3000w inverter.  that is on my shed.

I have 35 323W panels on my roof.

What solar setup have you got? Just curious as I'm contemplating one for my 5xNewpacs and Terminus (when globally released).

that looks good my solar setup needs this,  the 20 newpacs are killing my battery

Testing out a testing setup.

http://www.kano.is/worker.php?a=1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr.r606-test3

14 pods, 550MHz (750GH) each for 10.5TH ideally. It's still ramping up now but if you want to get some stats it'll be going for at least a few hours.

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.


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


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.

---

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

Decent amount of time on setting 5.

@rockmoney

Keep sending me those headers as you cycle through them.   Super useful in fine tuning.

@kano


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.


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.

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)

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.

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.

Also beyond a lottery machine, I would say this is a brilliant under the desk foot warmer or stack a few and now it's a money making heater.

Yep 661 shares in total - all 2000.0 Diff - for the single clientid, matched in the logs.

I've not looked at your code, but I can guess there might be an overestimate due to a number of possibilities:

Firstly, from the old icarus driver that Xiangfu wrote, then I redesigned it quite extensively for timing and minimising I/O, there's the issue of aborting work every time and thus you can't include the end of the hash cycle. Not sure if you've still done that with the BM chips.
But in any case, any aborted work should be estimated down based on the abort time vs full expected hash time.

Secondly, the BM FPGA return shares at a given Difficulty, so counting hashes can only be done assuming Diff*2^32 for each nonce.
I'm not sure where that is, in the chip or in the FPGA, so counting hashes for that in BM miners isn't hashes, but should be that Diff*2^32

Nextly, for AB, the chip clearly DOES NOT do a full hash cycle for all shares.

So really all this ends up with, is saying that the most accurate comparable hash rate between miners is the internal work Diff per nonce that comes back to cgminer, and then to get the current preferred (fake) hash rate, multiply that by 2^32

Lastly, the whole H/s design of all miners is now a complete fallacy.
Chips never did a full hash before anyway, so the hash counting is IMO incorrect.
Bitcoin should move away for H/s and use PD/s (Proof of Work Diff) since the actual number of hashes done is well below the numbers all AB miners report, and as mentioned, no miner since the GPU days ever did a full hash anyway.

But this all, hopefully, may help you find where the difference is

Thanks Kano.

"extra bit" to "standard" ratio is very close to 3:1, which is as expected.

That hash rate is only 95% of what was on screen.  I'm going to lean towards one hour being too small.

Looks like I should have included the full ending output:


Using the same formula, i still only end up with 479GH/s

Duration: 11847
Total difficulty of accepted shares: 1322000.0
Calculated hash rate: Diff * 2^32 / Time =  1322000 * 2^32 / 11847 = 479GH/s

I guess a better one-to-one question would be are the total accepted share reported by cgminer matching what you can see for the entire time period.

If that matches, it takes us up from 95% to 98%, but still a little off.

I'll have another one running to a unique worker for 24hr to get a better sampling of data.

OK, from the single clientid, the first share was 2019-04-21 13:16:10+00, last share was 2019-04-21 16:32:50+00
so I checked the shares from 15:00:00 to 16:32:50 (1hr 32min 50sec = 5570sec)

Accepted share count: 302
Total difficulty of accepted shares: 604000.0 (they were all 2000.0 diff)
Calculated hash rate: Diff * 2^32 / Time =  604000 * 2^32 / 5570 = 465GH/s

For the block version of those 302 accepted shares mined,
78 had a standard block version number (20000000) and the other 224 had extra bits in the block version.

Great to hear, thanks for checking us out!

vh, I know we DM'd but let me know if there a specific command you want me run in the batch file for winx as well.

Center link of my signature, I've updated it with a few additional recently reviewed miners.  

It should provide a better view of where these unit fits in, in the bigger picture of miners.

Sharing Moment:

Worker  : R606-d1s0r001
Device  : Early Prototype*
Setting : 0
Run     : 3 Hours @ kano.is, AsicBoost on.

489GH/s @ 39.12W = 0.80 J/GH

I'm emphasizing early prototype.   It's not as well behaved as sidehack's on hand production ones, from which he's actively sharing current data.

@Kano, can you pull the last hour of stats for that worker to see how that matched up?

Off to minefarmbuy site to buy a few

Cheap power does get a positive return. These miners make money if you have 5 cent power.

But they truly work best as a solo miner.

They are quiet and not costly to run.

At 100 watts one unit uses 72 kwatts a month. So 7.20 usd a month to run it. If you have 10 cent power.
If you solo mine them on other sha coins it is easier to hit blocks with them.
Many years ago I hit a few ppc blocks with sidehack compacs.

Perfect excuse to buy this, thanks Phil.

It is a lottery ticket machine.

I will mine my one at solo.ckpool  from now til it breaks not caring if it ever earns money.

I do this with my Apollo Ltc Miners which did hit 2 Doge blocks and earn 20000 doge.

I will make a pretty setup of the 3 miners along with 3 newpacs and mine away

The use purpose for this is more of a hobby miner than a industrial grade miner turning profit.

Depends on your cost of power. And what BTC does in price and difficulty.
But probably years. As of now with free power you are only going to be pulling in $75 / yr with 1TH

https://www.cryptocompare.com/mining/calculator/btc?

-Dave