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

[sidehack]

You're probably butting into the power headroom already. In fact I'm surprised you didn't hit it already, but keeping the main regulator cool probably helps a little with Rdson current measurement.

More voltage should give you more ability to clock higher, but the main regulator is current limited. Shouldn't hurt anything to turn the voltage up a bit and see where it goes. If you suddenly drop to no hashing and only fans drawing power, you've tripped the OC and need to power cycle the whole unit. The voltage range capable with the pot is safe; just make sure you keep the chips cool and there should be no damage.

I've got a test unit I want to mess with, raise the current limit (will require replacing some parts to raise the safety ceiling) and repeat some of your tests to see about improved cooling efficiency and push the hashrate super high.

[1714949000]

1714949000

[1714949000]

1714949000

[n0nce]

The voltage range capable with the pot is safe; just make sure you keep the chips cool and there should be no damage.

Regarding safety and damage: I know all types of overclocking come with some amount of risk, but usually it is related to voltage and heat. What about pushing clock speed without changes to the voltage (potentially even slightly undervolting and improving cooling with better fans, ducts, thermal pads on the back...)?
Are there any hints that suggest a strong overclock deteriorates ASIC mining chips faster than stock clock speed? [while keeping voltage and heat on normal levels]

[sidehack]

As long as heat is managed, the only damage will be your hashrate tanking because the data no longer makes sense.

[n0nce]

As long as heat is managed, the only damage will be your hashrate tanking because the data no longer makes sense.

But can it produce more heat when clocked higher, even though the potentiometer is not touched?

In CPU overclocking, as long as you use fixed voltages, the heat output should not be affected by the clock speed. It is usually directly related to voltage.

[gergar]

https://github.com/kanoi/cgminer/blob/master/API-README#L70

So {"command":"ascset","parameter":"1,chip,0:0"}

However, you don't need to use JSON, so as per https://kano.is/gekko.php

java API "ascset|1,chip,0:0" MinerIP

I will give it a try, if not i will try to call using shell the JAVA Api, just wanted to avoid os calls. THANK YOU!

Whatever you use, there are 2 formats

"ascset|1,chip,0:0"
or
'{"command":"ascset","parameter":"1,chip,0:0"}'

(aside: I designed and wrote the cgminer API)

Hey @kano!!!! THANK YOU my code now works so i can test each chip and set temp telemetry on each this is amazing!!!

THANK YOU!!!

[gergar]

As long as heat is managed, the only damage will be your hashrate tanking because the data no longer makes sense.

But can it produce more heat when clocked higher, even though the potentiometer is not touched?

In CPU overclocking, as long as you use fixed voltages, the heat output should not be affected by the clock speed. It is usually directly related to voltage.

it does as more current will pass as it switches more times per second, so drains more power. these asics gets quite hot at 700-725 mhz the stock fan wont keep up, the 6600 rpm axial fan i set helps a lot to keep them but i see generating the push pull helped me to pull more heat out but i saw no hashrate improvements in my case.

i will test as @sidekick shared, i will now under and over volt it and do push pull with axials so y pass a ton of air to it to avoid having thermal issues and see where do we get

[sidehack]

Power use increases with voltage, because the tiny switch gates basically act as capacitors so with a higher voltage, there's proportionally more current transferred to flip the switch on and off.
Power use increases with clock speed, because there are more switch flips happening.

[100knot2dae]

Just wanted to report back that I have added thermal pads to the bottom heatsinks on the weekend. While everything went well, the expected cooling benefit hasn't really been met in my opinion.

Yes these heatsinks do get warmer now, so there is better heat dissipation. But not significant in a way to have a measureable impact on watts or hashrate. I had hoped these pads to be a thermal bonus for my efficiency setup (550Mhz, undervolted), but - if at all - they are probably more of use for the heavy overclocking case.

[cygan]

my small solo mining farm is now complete and i can say that a rpi4 8gb ram can handle all these miners (6 compac f sticks and 2 r909 pod miners) without any problems and crashes.
as you can also see, the rpi4 is using less than 500mb of memory.

Code:

cgminer version 4.12.1 - Started: [2023-02-23 15:39:58.371]
--------------------------------------------------------------------------------
 (5s):7.002T (1m):6.695T (5m):6.675T (15m):6.703T (avg):6.746Th/s
 A:242821020  R:119132  HW:96240  WU:94247.9/m
 Connected to solo.ckpool.org diff 4.11K with stratum as user .....
 Block: 49f875db...  Diff:43.1T  Started: [10:52:41.548]  Best share: 190M
--------------------------------------------------------------------------------
 [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: GSF 10051796: BM1397:01+ 525.00MHz T:525 P:525 (24:12) |  100% WU:100% | 320.0G / 311.3Gh/s WU: 4349.5/m
 1: GSF 10051619: BM1397:01+ 525.00MHz T:525 P:525 (24:12) |  100% WU:100% | 420.0G / 349.4Gh/s WU: 4881.4/m
 2: GSF 10053617: BM1397:01+ 525.00MHz T:525 P:525 (24:12) |  100% WU:100% | 294.1G / 325.8Gh/s WU: 4551.3/m
 3: GSF 10053622: BM1397:01+ 525.00MHz T:525 P:525 (24:12) |  100% WU:100% | 348.2G / 340.9Gh/s WU: 4762.2/m
 4: GSF 10051622: BM1397:01+ 525.00MHz T:515 P:521 (24:12) |  100% WU:100% | 325.9G / 307.7Gh/s WU: 4298.9/m
 5: GSF 10053618: BM1397:01+ 525.00MHz T:515 P:525 (24:12) |  100% WU:100% | 385.7G / 348.3Gh/s WU: 4866.4/m
 6: GSF 10070009: BM1397:06+ 670.00MHz T:670 P:652 (3:2)   | 87.5% WU: 90% | 2.350T / 2.430Th/s WU:33947.7/m
 7: GSF 10070003: BM1397:06+ 640.00MHz T:640 P:623 (3:2)   | 89.6% WU: 90% | 2.063T / 2.332Th/s WU:32590.6/m

[100knot2dae]

Does anybody actually power this pod miner with a barrel jack PSU, instead of a plain computer PSU?

@sidehack: You have mentioned in the first post

Like previous Terminus models, the miner runs on 12V power from either a standard 2.1/5.5mm barrel jack (rated for 8A) or a PCIe 6-pin jack

So, is the PCIe connector on this miner rated for higher current or are both connectors rated the same? Is there any (other) downside one should be aware of when using the barrel jack?

Thanks for letting me know.

[altair_tech]

Does anybody actually power this pod miner with a barrel jack PSU, instead of a plain computer PSU?

Yes, it works fine with 2.1/5.5 mm barrel jack PSU. Those are rated for upto 8 Amps, but I've gone upto 10Amps on 2 different 2.1/5.5mm barrel jack PSU's without any problem.
It is safer to run it on a PSU with 6-pin PCIe connector though, specially if you plan to overclock it over 120 Watts. Those are rated for much higher currents. For example on an antminer S9 , 9x PCIe connectors deliver 1650Watts. That's about 15 Amps per PCIe connector.

[NotFuzzyWarm]

A couple things to keep in mind:
Barrel jacks are not intended to deliver their maximum rated current 24x7x365

Barrel jacks are rated with the assumption that they are periodically disconnected/re-connected so any oxidation is scraped off and a fresh contact surface is made. At low to moderate currents this is not an issue, as you approach the connector max current rating it is definitely a concern.

As for PCIe plugs - max current is HIGHLY dependent on what kind of plating is on the pins. If silver or gold each pin *can* handle up to 5A per pin. Since there are 3x circuits and each takes 2 pins (1 feed, 1 return) you get the 15A max for the 6-pin connector. Safe max for tin plating is just 3A. Those max ratings also are highly dependent on what gauge & type of wire is used as the wire pulls heat away from the connection. Typically max current only applies to using 16ga copper wire.

[100knot2dae]

Barrel jacks are rated with the assumption that they are periodically disconnected/re-connected so any oxidation is scraped off and a fresh contact surface is made. At low to moderate currents this is not an issue, as you approach the connector max current rating it is definitely a concern.

Didn't know about that aspect, thanks for pointing this out. The PCIe connector definitely seems to be the better choice here.

[GlenAllan]

Hello, newb here... Having a pain getting my R909 to work properly on the same system as 4 Compac Fs. It was recommended i ask in here to see if anyone has an idea of what's going on instead of in my own post.

Command i'm running: /opt/homebrew/Cellar/cgminer/4.12.1/bin/cgminer -o stratum+tcp://solo.ckpool.org:3333 -u "my bitcoin address" -p x --gekko-r909-freq 500 --gekko-compacf-freq 545 --gekko-start-freq 300 --gekko-tune-up 85

I've tried running the R909 out of a free port on the Gekko Science hub, tried running both through a USB 2 hub out of the same USB port, tried running through different USB ports on the same computer, all no gos. It crashes resets and tries again. The WU: (Work uptime?) for the 909 gets stuck between 50 and 65% and never gets higher once the frequency is reached.

I should say the R909 works totally fine on a different computer by itself as a separate worker, or on the first computer without the Compac Fs running. I've tried running all devices on both an M1 Mac Mini and an iMac Pro, and on both the WU stays low for the 909, then resets.

Only other thing i can think of is i'm running the kanoi/cgminer fork that installs through homebrew. It is at version 4.12.1.

I'm new enough that this is all out of my depth. Any suggestions for what i should be doing here would be much appreciated.

Thanks!

[kano]

The sleep timer in OSX is the worst of the 3 OSes.

That's why:

API Usage
As before there's a global wait factor override to adjust the rate that work is sent to the miner.
The default should be fine which is 0.5 for Linux, 0.4 for Windows and 0.3 for Mac

One R909 is closely equivalent to 6xCompacF.
It definitely works OK on it's own, but timing can run amok when you have too many threads trying to time work to the chips on OSX.
That limit will of course be dependent upon the hardware, but by the looks of things for your case, 10 chips is too much for one.

[GlenAllan]

Okay, so are you saying there is a way to adjust the global wait factor? Or that it's not going to work on OSX at all? I'm running 18 USB devices on that machine no problem otherwise (yes i tested this without them hooked up). I did have USB issue on Intel Machines with too many hard drives connected, on a couple of machines, but i've never had any issue on Apple Silicon. I know you said OSX itself, but not sure if that would be any different.

[kano]

It's the 'timing', not exactly the number of 'devices'.

For a single R909 it has to send work around once every 4-5ms.
If it gets delays from thread switching, those delays wont normally be as low as 1ms on OSX.
You can see and compare the number in the estats output.

Check [Sleep... e.g. below

Code:

[STATS] => 1
[ID] => GSF0
[Elapsed] => 13417

[FreqComp] => 499.995331

[MaxTaskWait] => 4260
[WaitFactor0] => 0.500000
[GHGHs] => 1951.648580
[JobDataAge] => 0.004327
[JobsAvgms] => 4.27/4.27/4.27/4.27/4.27
[JobsMinMaxms] => 4.01:4.56/4.01:5.40/4.01:5.50/4.01:5.44/4.01:8.59

[Dups] => 17
[DupsReset] => 17
[Chips] => 6

[SleepN] => 16416669
[SleepAvgReq] => 1000.063289
[SleepAvgRes] => 1.074009
[SleepN1_1] => 32839824
[SleepAvgReq1_1] => 222.902610
[SleepAvgRes1_1] => 1.335763
[SleepN1_5] => 240071
[SleepAvgReq1_5] => 216.000991
[SleepAvgRes1_5] => 1.660623
[SleepInv] => 1

That's on an RPi4 doing 1.95TH/s on 1 of the 4 miners connected to it.
(2xR909, 1xCompacF, 1xNewPac)

It's calculated [FreqComp] => 499.995331 MHz is getting [GHGHs] => 1951.648580 GH/s (over the last 5 minutes)

It wants work [MaxTaskWait] => 4260 i.e. 4.2ms
Over the last 5 minutes it's averaging very well [JobsAvgms] => 4.27/4.27/4.27/4.27/4.27
Of course not every job is perfect, [JobsMinMaxms] => 4.01:4.56/4.01:5.40/4.01:5.50/4.01:5.44/4.01:8.59
JobsMinMaxms says what the min and max ms have been over the last 5 minutes

Sleep times:
Note there are normally 2 sleeps per job sent.
16416669 with an average of 1000.063289 microseconds averaged 107.4009% of the requested delay (for all that averaged less than 110% delay)
32839824 with an avg of 222.902610us avg 133.5763% of the requested delay (for all between 110 and 150%)
240071 with an avg of 216.000991us avg 166.0623% (for that were over 150%)

I'd expect your OSX numbers to be a lot worse and get progressively worse with more miners.

This all boils down to CPU and OS sleep time accuracy of usleep() on that OS
Surprisingly it is hard for all OS to sleep a thread 1ms and wake it up 1ms after the call.
The order of accuracy is Linux > Windows > OSX

Thus:

API Usage
As before there's a global wait factor override to adjust the rate that work is sent to the miner.
The default should be fine which is 0.5 for Linux, 0.4 for Windows and 0.3 for Mac

As explained on https://kano.is/gekko.php#apu
If you have CPU spare you can try lowering the wait factor.
What it means is it will try to send work faster than the R909 needs.
Which means if it is sending it slower than it needs, it will make the averages better.

[GlenAllan]

Huh, i haven't actually used the API to do anything yet, so i might give some adjustments a try.

Otherwise i do have a couple of Raspberry Pis, so i can repurpose one for this. It was being used for live video triggering for video production, but i don't think i need both for that. Interesting that a Pi running Linux can work better than a Mac or Windows machine.

Out of curiosity, what's the best distro for this on the Pi. Actually i can just go look that up.

Thanks for the info! Would be nice if this wasn't an issue, but i'll get around it. I do have CPU to spare.

[GlenAllan]

And to be sure i'm not just an idiot, is it as simple as enabling the api and then adding the wait factor commend, like this:
/opt/homebrew/Cellar/cgminer/4.12.1/bin/cgminer -o stratum+tcp://solo.ckpool.org:3333 -u "BTC Address -p x --gekko-r909-freq 500 --gekko-compacf-freq 545 --gekko-start-freq 300 --gekko-tune-up 85 --api-listen --api-allow "W:192.168.1.0/24,W:127.0.0.1" --gekko-wait-factor 0.1

Assuming that's correct (which i don't assume). How low is safe to go? 0.01, etc?

[GlenAllan]

Never mind. I found the part. Helps to actually read more. Now to figure out how to use the API properly.

java API "ascset|0,waitfactor,0.6" minerIP

Now where to put the adjustment.