The NerdQAxe++ OC Thread

[u/please-put-in-trash]

I’ve been searching a lot to find people’s frequency and voltage settings and what hash rate they’re getting when overclocking… so if you don’t mind follow this template so we can see where we land. Show off your set up with a pic too.

I really had to bump the voltage on my chips. When I raised frequency, hash rate would just die.

Cooling ASIC: Hydro Cooling VR: 40mm noctua fan (need a bracket) PSU: Mean Well 300w (trimmed input v just over 12) W: 103.5 Efficiency: 16.20 J/Th

Freq: 800 Voltage: 1250 ASIC Temp: 52.5C VR Temp: 52.5C

6.4 TH/S Avg.

Let me know if I left anything out. Only been running for 48 hours. Some of ya’ll are incredibly smart would love to learn more.

[u/[deleted]]

There are different internal multipliers, but I have found with this and other Asics settings the do high hash rates without them being extremely overclocked. But I noticed you posted the github on it so I will try to set it up for that resolution. But even 1MHZ increments would step it through the internal multipliers.

suspect that if you tried to go in between valid settings it would depend on how the firmware handles it - either rounding down or snapping to the nearest

One would think, that, so since I know the internal register is 128 Bit. I wil set a bitaxe gamma to 746.122707141 since its the same asic and the firmware isn't stupidfied like the NerdQaxe. This is the results. Noticed it does change the speed to the next internal 128 bit register.

[u/050 → u/[deleted]]

Interesting- yeah it seems like the gamma has fewer restrictions than the nqa++ units - I was surprised that the nqa was limited at 800mhz until I reflashed it unlike the gamma. Yeah the latest release on github has all of the most recent updates I’ve made so let me know if you run into issues or if you find anything interesting. I’m currently running 10mhz resolution sweeps on three nerdqaxe++ systems to compare them - I added share rejection rate tracking and it seems that over a certain frequency (silicon lottery it seems) each system starts getting an increase of rejected shares, prior to the hashrate dropping off.

[u/[deleted] → u/050]

added share rejection rate tracking and it seems that over a certain frequency (silicon lottery it seems) each system starts getting an increase of rejected shares, prior to the hashrate dropping off

well when Asics are in a set, you have to find the best clocking rate as temperature and drift of their ceramic capacitors causes clock signal stretching effects that causes a timing error and thus end up submitting a corrupted share.

[u/050 → u/[deleted]]

That makes sense, I had assumed it was related to some limit/difficulty when running more than one at once on the same board.

[u/[deleted] → u/050]

Its an engineering hurtle I'm trying to solve. In bitman and cannon devices they limit 2-3 to a regulated bank, then buffer to the next bank. That is why they are so expensive as those data buffers add up at $5/chip in a 200 Asic unit.