Topic: GekkoScience has a new pod miner, just in time for Christmas - page 5. (Read 6937 times)

Does changing things in the api set the hardware after it's connected to something else? All of a sudden i'm only getting 3 of the 6 chips on the r909 showing up after a move to a different machine. Just wondering.

i run my rpi 4 8gb ram with 2 r909 and a total of 6 compac f sticks (so a total of 18 chips) and that without any problems and performance loss. of the said 8gb ram my rpi doesn't even consume 500mb for this configuration. so i could imagine that you could connect at least one (third) r909 pod miner to the same rpi.
as os i use the raspios bullseye: https://www.raspberrypi.com/software/operating-systems/

And as for the OS... I was going to go for Ubuntu MATE for being a bit lighter. Any reason to do anything different if i want a desktop UI?

I see... Well right now i just want to optimize for 4 Compac Fs and 1 r909. I assume then that is actually about as much as i could do outside of adding a couple more Compac Fs.

Good to know!

I think the practical limit for a Pi is around 15 chips, so that'll run two R909 by itself. I don't know that anyone's gotten expected speed out of three together on one Pi.

What a trip! Well i've got a Pi 4 with 8GB RAM running on an SSD, so i'll grab Ubuntu and get it going for mining and see what performance i'm missing from all of these then. Should be interesting to set up!

I did all the wait factor adjustments on the Mac and it just didn't really do much. I did test the commands to be sure they were working, it just didn't do anything meaningful. So Pi it is!

Yeah the Pi runs these guys pretty well but it's entirely because of the OS scheduler that it's better than more powerful machines with OSX or MSX. Our production testers are old Dell 755 machines from approximately 2008 that are stable with 10xR909 at stock speed. Meanwhile, on a newer stronger Mac...

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.

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?

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.

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

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:

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.

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.

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

That's why:

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.

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!

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

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.

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.

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
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.

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.

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.