GekkoScience has a new pod miner, just in time for Christmas

[RKG456]

Thought I would provide an update with my setup. I got the 2nd R909 and 5th Compac-F up and running on a 2nd RPi4.  I have been mining ViaBTC pool with the rig setups below and the 24hour mining results are: 10-Min Avg. HashRate fluctuates between 5.5TH/s and 7.5TH/s.   All is working great and the R909s are AWESOME!

1st Rig: 1x R909, 4 Compac-Fs and 2 NewPacs.

Code:

 cgminer version 4.12.1 - Started: [2023-01-09 22:10:42.856]
--------------------------------------------------------------------------------
 (5s):4.208T (1m):3.642T (5m):3.670T (15m):3.680T (avg):3.302Th/s
 A:39440384  R:8192  HW:47379  WU:46131.1/m
 Connected to bitcoin.viabtc.io diff 4.1K with stratum as user N0F34R.NPandT
 Block: 11fe4e31...  Diff:34.1T  Started: [11:59:55.799]  Best share: 31.6M
--------------------------------------------------------------------------------
 [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: GSF 10070012: BM1397:06+ 600.00MHz T:600 P:600 (3:2)       | 96.3% WU:^87% | 2.745T / 2.104Th/s WU:29401.4/m
 1: GSH 10041663: BM1387:02+ 375.00MHz T:375 P:375 (100:50)    | 98.9% WU:^88% | 87.78G / 75.03Gh/s WU: 1048.2/m
 2: GSH 10038894: BM1387:02+ 375.00MHz T:375 P:375 (100:50)    | 98.6% WU:^88% | 82.19G / 74.92Gh/s WU: 1046.6/m
 3: GSF 10052154: BM1397:01+ 450.00MHz T:450 P:449 (28:14)     |  100% WU:100% | 287.0G / 242.7Gh/s WU: 3390.6/m
 4: GSF 10053864: BM1397:01+ 450.00MHz T:450 P:450 (28:14)     |  100% WU:100% | 337.9G / 267.3Gh/s WU: 3734.2/m
 5: GSF 10050104: BM1397:01+ 450.00MHz T:450 P:450 (28:14)     |  100% WU:100% | 317.0G / 269.7Gh/s WU: 3767.1/m
 6: GSF 10054544: BM1397:01+ 450.00MHz T:450 P:450 (28:14)     |  100% WU:100% | 306.3G / 267.9Gh/s WU: 3743.0/m

2nd Rig: 1x R909 and 1x Compac-F. 

Code:

 cgminer version 4.12.1 - Started: [2023-01-09 08:51:23.596]
--------------------------------------------------------------------------------
 (5s):2.266T (1m):2.598T (5m):2.554T (15m):2.528T (avg):2.234Th/s
 A:50655232  R:4096  HW:60608  WU:31211.2/m
 Connected to bitcoin.viabtc.io diff 4.1K with stratum as user N0F34R.T9andCF
 Block: 11fe4e31...  Diff:34.1T  Started: [11:59:55.782]  Best share: 118M
--------------------------------------------------------------------------------
 [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: GSF 10070032: BM1397:06+ 575.00MHz T:575 P:575 (3:2)      |  100% WU:^86% | 2.211T / 1.995Th/s WU:27878.9/m
 1: GSF 10053931: BM1397:01+ 400.00MHz T:400 P:400 (31:16)    |  100% WU:100% | 259.0G / 238.5Gh/s WU: 3332.3/m
--------------------------------------------------------------------------------

Updated Rig video link: https://youtu.be/MHAziVzA6I8

[n0nce]

All is working great and the R909s are AWESOME!

They really are! It seems to me like sidehack did good work on the thermal design. Super beefy heatsinks on both sides, with nice channel for the air, all in all running great.
I've ran 600MHz for over 48h without touching the voltage knob, and got no anomalies in error rate or anything.

Now testing 650MHz just using --gekko-r909-freq 650 on all cores, stock voltage.

Updated Rig video link: https://youtu.be/MHAziVzA6I8

Nice setup! For what it's worth, you could run multiple cgminer instances all on a single Pi, or are you getting issues when too many USB devices are connected?

[RKG456]

Nice setup! For what it's worth, you could run multiple cgminer instances all on a single Pi, or are you getting issues when too many USB devices are connected?

Essentially with all of the fans being plugged in I was running out of usb ports.   The original setup for Rig 1 was running stable as it was so I didn't want to change it. Given I have many Raspberry Pi and other Single Board computers laying about, I figured I would just spit it into two mining rigs.  That way I could relocate one if need be. Plus test mining against different pools to see how things went.  Right now it is a little cramped in that one area. With Rig 1 I have a keyboard and mouse connected. With Rig 2 I am forcing myself to work it remotely.

[n0nce]

Essentially with all of the fans being plugged in I was running out of usb ports.

I see, makes sense!

So I tried to do something that I'd not suggest anyone else to do
Of course try it if you really know what you are doing and have a 5kRPM fan, high quality power and are using linux

The aim was to see how fast I can get the R909 going - and I've got a record so far, we'll see who can beat it
My production R909 has one chip not as good as the other 5, so someone with 6 perfect chips should be able to beat it.

Anyway, I put in a 5kRPM fan, set the blue screw close to maximum, set 5 chips to ... 725MHz ... and the dodgy chip to 500MHz.

Results after hours of running (that I posted in discord earlier):

Code:

(5s):5.067T (1m):5.046T (5m):5.105T (15m):5.098T (avg):5.024Th/s
 A:36261324  R:23056  HW:8786576  WU:70192.7/m
 Connected to               diff 2.88K with stratum as user
 Block: 5fd33018...  Diff:34.1T  Started: [19:45:10.943]  Best share: 84.9M
--------------------------------------------------------------------------------
 0: GSF 10008346: BM1397:01+ 450.00MHz T:450 P:450 (28:14) |  100% WU:100% | 307.9G / 292.5Gh/s WU: 4086.1/m
 1: GSF 10008000: BM1397:06+ 500.00MHz T:500 P:500 (4:2)   |  100% WU: 98% | 2.265T / 1.970Th/s WU:27525.2/m
 2: GSF 10055348: BM1397:01+ 450.00MHz T:450 P:450 (28:14) |  100% WU:100% | 296.0G / 286.5Gh/s WU: 4001.8/m
 3: GSF 10070004: BM1397:06+ 687.50MHz T:500 P:665 (3:2)   | 90.4% WU: 89% | 2.433T / 2.475Th/s WU:34579.3/m

Massive >20% hardware errors, but "3: GSF 10070004: BM1397:06+" powering along at 2.475Th/s

Hey kano, I'm running 700MHz for around an hour now, without changes to the voltage screw and the NF-A8 PWM running at 2200RPM. Seems stable and good so far. I'm finally getting over 2.5TH/s (that was my goal), so I guess I beat you, with stock voltage!

Just to make sure: worst that can happen when aiming for too high clock speeds is that it crashes or returns faulty hashes, right? Or is there any 'risk' to pushing the overclock as long as the voltage screw is not touched? And the error rate is displayed through those Java API commands, right? The only way I've checked my error rate so far was the log printed when killing cgminer.

Proof:

Code:

 (5s):2.647T (1m):2.735T (5m):2.639T (15m):2.602T (avg):2.585Th/s
 A:3259855  R:0  HW:1984  WU:36123.2/m
 Connected to stratum.kano.is diff 1.62K with stratum as user
 Block: 4b258ede...  Diff:34.1T  Started: [07:05:45.608]  Best share: 1.5M
--------------------------------------------------------------------------------
 0: GSF 10070017: BM1397:06+ 700.00MHz T:700 P:697 (3:2) | 94.2% WU: 92% | 2.615T / 2.585Th/s WU:36125.3/m

2.585Th/s

[cygan]

✂
Hey kano, I'm running 700MHz for around an hour now, without changes to the voltage screw and the NF-A8 PWM running at 2200RPM. Seems stable and good so far. I'm finally getting over 2.5TH/s (that was my goal), so I guess I beat you, with stock voltage!
✂

you definitely beat him
i will try my luck with my 2 r909 pod miner, only i would have to know how to adjust the rotations of the noctua fans ...

[n0nce]

you definitely beat him
i will try my luck with my 2 r909 pod miner, only i would have to know how to adjust the rotations of the noctua fans ...

Good luck!
The fan header on the R909 doesn't seem to output a fan curve so whatever you plug in, will run at its max speed. For the NF-A8 PWM, that should be 2200RPM.

You could plug in the included (with the fan) low-noise adapter that reduces it to a fixed 1750RPM but then the airflow will be less than the original fan so I'd be very careful with temps.

[kano]

Hey kano, I'm running 700MHz for around an hour now, without changes to the voltage screw and the NF-A8 PWM running at 2200RPM. Seems stable and good so far. I'm finally getting over 2.5TH/s (that was my goal), so I guess I beat you, with stock voltage!

Just to make sure: worst that can happen when aiming for too high clock speeds is that it crashes or returns faulty hashes, right? Or is there any 'risk' to pushing the overclock as long as the voltage screw is not touched? And the error rate is displayed through those Java API commands, right? The only way I've checked my error rate so far was the log printed when killing cgminer.

Proof:

Code:

 (5s):2.647T (1m):2.735T (5m):2.639T (15m):2.602T (avg):2.585Th/s
 A:3259855  R:0  HW:1984  WU:36123.2/m
 Connected to stratum.kano.is diff 1.62K with stratum as user
 Block: 4b258ede...  Diff:34.1T  Started: [07:05:45.608]  Best share: 1.5M
--------------------------------------------------------------------------------
 0: GSF 10070017: BM1397:06+ 700.00MHz T:700 P:697 (3:2) | 94.2% WU: 92% | 2.615T / 2.585Th/s WU:36125.3/m

2.585Th/s

Well that A says 1.5 hours so definitely higher hash rate than me

I wonder if 725MHz is just too high for them (as per my >20% HW) and 700 is the limit?

Also as mentioned in my case, one chips is somewhat of a dud,
so I had to keep pushing the freq higher to get closer to 2.5T,
so for you all 6 chips running OK at 700 will give a higher avg for you also "BM1397:06+ 700.00MHz"
(though my dud does about 25% of 500MHz when you set it to 500MHz)

'Error rate' is HW / (A+R+HW) = 1984 / (3259855 + 0 + 1984)

I changed cgminer to report HW on the screen correctly for the Gekkos - it used to only count HW occurrences, but alas most miners don't return nonces at diff1 - so for the Gekko's it uses the ticket per HW.
In the case of the R909 that's 64 - i.e. 1984 / 64 = 31 bad nonces returned (and each nonce returned is worth 64)

Yes you can kill it - no it's not bullet proof.
It is unlikely to kill it, but as you push it harder that means you are pushing the chips harder also.
If you overload the power it will just switch off, and then the 'fuse' will need a power cycle and letting it cool will fix that.
But the chips themselves, I've no idea under what circumstances they might be at risk.
Maybe sidehack knows?

[n0nce]

Well that A says 1.5 hours so definitely higher hash rate than me

I wonder if 725MHz is just too high for them (as per my >20% HW) and 700 is the limit?

That's definitely possible. I'm running 650MHz now, since after a few hours it had dropped to 690MHz and I don't feel like pushing it to its max right now. Yet still I am getting 2.487Th/s on average. Still super close to that 2.5 mark, or 3.8% lower than my previous result, while reducing clock by 50MHz, so a 7.2% reduction in clock speed.
This indicates to me that above 650, we get into diminishing returns.

Yes you can kill it - no it's not bullet proof.
It is unlikely to kill it, but as you push it harder that means you are pushing the chips harder also.

I guess on its basic level, the transistors are going to be 'pushed' to switch faster; but in the realms of CPU overclocking I've never heard of a high frequency killing chips / diminishing their lifespan. It's usually the required higher voltage that does the most harm, to the best of my knowledge at least.

If you overload the power it will just switch off, and then the 'fuse' will need a power cycle and letting it cool will fix that.
But the chips themselves, I've no idea under what circumstances they might be at risk.
Maybe sidehack knows?

Feedback by sidehack would be amazing!

[kano]

I'm running 650MHz now, since after a few hours it had dropped to 690MHz and I don't feel like pushing it to its max right now.

I initially got up to 2.497TH/s after more than an hour, hoping it would reach 2.5, but by the next day it was down to 2.475Th/s
I just let it go at 725/500 since, well, it didn't die, just the HW % kept rising.

[n0nce]

I'm running 650MHz now, since after a few hours it had dropped to 690MHz and I don't feel like pushing it to its max right now.

I initially got up to 2.497TH/s after more than an hour, hoping it would reach 2.5, but by the next day it was down to 2.475Th/s

While also clocking itself down a bit? Or did you lock the frequencies?
I haven't done any such fancy stuff and it went down to 690 by itself, as mentioned before. So the sweet spot is probably between 650 and 700MHz depending on silicon lottery.
But I do think this behavior (automatic down clocking to a stable frequency) is a really great feature of cgminer. Much better than overly pushing the chip and just getting invalid blocks out of it.

I just let it go at 725/500 since, well, it didn't die, just the HW % kept rising.

For what it's worth, my HW% was always in check so far. It still downclocked. Oh well; again: diminishing returns, anyway.

[cygan]

I'm running 650MHz now, since after a few hours it had dropped to 690MHz and I don't feel like pushing it to its max right now.

I initially got up to 2.497TH/s after more than an hour, hoping it would reach 2.5, but by the next day it was down to 2.475Th/s
I just let it go at 725/500 since, well, it didn't die, just the HW % kept rising.

i have now replaced the two fans with the nactua nf-a8 pwm and started the two r909 pod miners at 690mhz - before that i turned the blue screw to about 1 o'clock
now the two r909 run just over 2.5 hours and this is how the performance looks:

Code:

4: GSF 10070009: BM1397:06+ 680.00MHz T:680 P:646 (3:2)   | 90.4% WU: 89% | 2.222T / 2.435Th/s WU:34028.6/m
5: GSF 10070003: BM1397:06+ 650.00MHz T:650 P:643 (3:2)   | 83.7% WU: 84% | 2.141T / 2.196Th/s WU:30681.2/m

somehow the 2.5th/s does not want to fall...

[n0nce]

I'm running 650MHz now, since after a few hours it had dropped to 690MHz and I don't feel like pushing it to its max right now.

I initially got up to 2.497TH/s after more than an hour, hoping it would reach 2.5, but by the next day it was down to 2.475Th/s
I just let it go at 725/500 since, well, it didn't die, just the HW % kept rising.

i have now replaced the two fans with the nactua nf-a8 pwm and started the two r909 pod miners at 690mhz - before that i turned the blue screw to about 1 o'clock
now the two r909 run just over 2.5 hours and this is how the performance looks:

Code:

4: GSF 10070009: BM1397:06+ 680.00MHz T:680 P:646 (3:2)   | 90.4% WU: 89% | 2.222T / 2.435Th/s WU:34028.6/m
5: GSF 10070003: BM1397:06+ 650.00MHz T:650 P:643 (3:2)   | 83.7% WU: 84% | 2.141T / 2.196Th/s WU:30681.2/m

somehow the 2.5th/s does not want to fall...

Weird; they're not running 690, though. Maybe decrease the voltage a little. Could be that they get too hot, return faulty computations and cgminer tells them to clock down. If they ran at stable 690.00MHz, they should right about reach 2.5TH/s.
Of course, there's some silicon lottery involved, but give that a shot. In my experience with Compac F, chips clocking down was usually a sign of bad cooling / too high voltage.

Can you show the line with A, R and HW numbers?

[cygan]

@n0nce
so you mean i should turn the blue screw again around 12 o'clock or reduce the mhz rate?🤔

[n0nce]

@n0nce
so you mean i should turn the blue screw again around 12 o'clock or reduce the mhz rate?🤔

Maybe first turn back the screw (I guess try something between 12 and 1) and try 690MHz. If that doesn't hold stable, try 680MHz, going down in 10MHz steps. In my experience, going above 650MHz was effortless at stock voltage.

[kano]

As mentioned on the gekko page,
https://kano.is/gekko.php#rang
the '[ChipNRanges]' data will give you a good idea what each chip is doing.

e.g. for my one before (data abbreviated to save space)

Code:

   [FreqLocked] => true
   [Chip0Ranges] => 882/998/1010/1035/1021/971/5917/94.54%
   [Chip0FreqReply] => 725.000000
   [Chip1Ranges] => 141/153/170/155/161/148/928/21.50%
   [Chip1FreqReply] => 500.000000
   [Chip2Ranges] => 1011/1136/1136/1082/1115/1098/6578/105.10%
   [Chip2FreqReply] => 725.000000
   [Chip3Ranges] => 834/1030/1003/1049/927/996/5839/93.29%
   [Chip3FreqReply] => 725.000000
   [Chip4Ranges] => 1022/1127/1162/1120/1164/1083/6678/106.70%
   [Chip4FreqReply] => 725.000000
   [Chip5Ranges] => 891/984/1071/1046/1028/1051/6071/97.00%
   [Chip5FreqReply] => 725.000000

Edit:
Oh I should show Dups and Nonces since that also shows if CPU/USB can't handle it:

Code:

   [Elapsed] => 31047
   [Nonces] => 1560325
   [Dups] => 7383
   [DupsReset] => 7383

   [Chip0Nonces] => 246973
   [Chip0Dups] => 8
   [Chip1Nonces] => 42874
   [Chip1Dups] => 267
   [Chip2Nonces] => 272900
   [Chip2Dups] => 57
   [Chip3Nonces] => 242216
   [Chip3Dups] => 11
   [Chip4Nonces] => 272852
   [Chip4Dups] => 6113
   [Chip5Nonces] => 243088
   [Chip5Dups] => 927

The first 3 are the most relevant numbers.

Chip4Dups might be suggesting that chip 4 can't handle 725MHz as well as the other 4 good ones, or is near it's limit - though I'm not sure

[cygan]

@n0nce
so you mean i should turn the blue screw again around 12 o'clock or reduce the mhz rate?🤔

Maybe first turn back the screw (I guess try something between 12 and 1) and try 690MHz. If that doesn't hold stable, try 680MHz, going down in 10MHz steps. In my experience, going above 650MHz was effortless at stock voltage.

now everything runs just over 24h but I still can not reach the limit of 2.

Code:

4: GSF 10070009: BM1397:06+ 680.00MHz T:680 P:655 (3:2)   | 88.4% WU: 90% | 2.792T / 2.453Th/s WU:34281.3/m
 5: GSF 10070003: BM1397:06+ 640.00MHz T:640 P:621 (3:2)   | 89.8% WU: 90% | 1.961T / 2.331Th/s WU:32575.2/m

and here are the a, r and hw data (but there are 4 more compac f sticks connected)

Code:

A:131834880  R:54432  HW:51456  WU:85740.4/m

[n0nce]

@n0nce
so you mean i should turn the blue screw again around 12 o'clock or reduce the mhz rate?

Maybe first turn back the screw (I guess try something between 12 and 1) and try 690MHz. If that doesn't hold stable, try 680MHz, going down in 10MHz steps. In my experience, going above 650MHz was effortless at stock voltage.

now everything runs just over 24h but I still can not reach the limit of 2.

Code:

4: GSF 10070009: BM1397:06+ 680.00MHz T:680 P:655 (3:2)   | 88.4% WU: 90% | 2.792T / 2.453Th/s WU:34281.3/m
 5: GSF 10070003: BM1397:06+ 640.00MHz T:640 P:621 (3:2)   | 89.8% WU: 90% | 1.961T / 2.331Th/s WU:32575.2/m

and here are the a, r and hw data (but there are 4 more compac f sticks connected)

Code:

A:131834880  R:54432  HW:51456  WU:85740.4/m

You've got an error rate of 0.0008025419406, in other words 0.08% which is excellent.
If I were you, I'd slightly increase clock speeds. I'm not sure if I missed something, so are you deliberately running one R909 at 640MHz and one at 680?

I wonder if 725MHz is just too high for them (as per my >20% HW) and 700 is the limit?

That's definitely possible. I'm running 650MHz now, since after a few hours it had dropped to 690MHz and I don't feel like pushing it to its max right now. Yet still I am getting 2.487Th/s on average. Still super close to that 2.5 mark, or 3.8% lower than my previous result, while reducing clock by 50MHz, so a 7.2% reduction in clock speed.
This indicates to me that above 650, we get into diminishing returns.

Update on this: It does seem like the sweet spot is right between 650MHz and 700MHz. I've turned mine back up a bit from 650MHz (just slightly over 2TH/s after a day) to 675MHz and I'm back on 2.531Th/s after an hour. Let's see what this looks like in a few hours.

[cygan]

✂
If I were you, I'd slightly increase clock speeds. I'm not sure if I missed something, so are you deliberately running one R909 at 640MHz and one at 680?
✂

no, both were started with 680 only the one went down step by step to 640
maybe i should turn the screw a little on the one r909 (640) after all?

[kano]

Got my R909 delivered today and got all my miners going except the R808 I got off of ebay appears to have pooped out. It was working then got stuck on Found 0 Chips..
...

Check it's not a software version issue - i.e. if it was working before, use the version of software from before just for the R808 and see if it's ok.
I've no idea if the R808 works with the current code.
I've run R909, R606, CompacF, NewPac, 2Pac and Compac on the new version (and you should use the new 4.12.1 version for those six)

As I mentioned in Discord, this turns out to be that the old magic '60' calc is no good for the R808.
Side effect was an average of about once per half an hour of it deciding to reset due to a slow nonce.

I've updated git with a fix for the R808 (and I've run it on all the miners now together) and the new calc is more reasonable (and more accurate)
So only if you have an old R808 you should do the update steps in https://kano.is/gekko.php#lin and it should fix that.

Edit; of course it wont fix a dead R808 - but it will fix it if it was resetting repeatedly, unnecessarily.

[n0nce]

✂
If I were you, I'd slightly increase clock speeds. I'm not sure if I missed something, so are you deliberately running one R909 at 640MHz and one at 680?
✂

no, both were started with 680 only the one went down step by step to 640
maybe i should turn the screw a little on the one r909 (640) after all?

What I noticed is that sometimes the automatic 'step down' is a bit too aggressive; i.e. if you set the target frequency too high (like 680MHz maybe), it might step down to 640MHz, even though it would hold 650MHz just fine if you used that as a target.
So before fiddling with voltages, I'd try to (manually) find a stable frequency target by increasing / decreasing it in 50MHz or 25MHz steps and letting it run for a few hours.

Right now, after 12h on 675MHz, I have a 2.310Th/s average. That's substantially more than the ~2TH at 650MHz. As you can tell, I'm having a blast fine-tuning this thing. And I'm just getting started (need to install Java & such..).