Topic: Very unofficial review of the BitaxeGamma miner. - page 2. (Read 1184 times)
v2.4.0 of the software is out, suggest everyone updates if only for the temperature sensor fixes. Updated on my end very easily with zero issues!
it died I went to make the heatsink better and when I assembled it back together its dark.
I am going to send it back for a repair as I do like the unit. Just be careful of your heatsinks.
I am going to send it back for a repair as I do like the unit. Just be careful of your heatsinks.
But rock it does. Northbridge heatsinks are designed for chips with large packages and/or integrated heat spreaders, more like 25mm square than 8mm square. With that much area, a 2-point mount is okay because there's no leverage to rock it. A small chip in the middle might as well be a single point fulcrum. It's super easy to upset.
We're already designing an improved heatsink (more dissipative surface area on the fins) with 4-point M3 screw mounting, like what's been working on our stickminers for most of the last decade. Might have samples in the next week.
Phil, I think yours went out before I started lapping the heatsink underside. The ones we got in were not exactly smooth either, and the smoother and flatter the mating surface, the better.
We're already designing an improved heatsink (more dissipative surface area on the fins) with 4-point M3 screw mounting, like what's been working on our stickminers for most of the last decade. Might have samples in the next week.
Phil, I think yours went out before I started lapping the heatsink underside. The ones we got in were not exactly smooth either, and the smoother and flatter the mating surface, the better.
Also hey Phil, since we started lapping heatsinks (removing the yellow anodize and smoothing any striations or lack of flatness in the surface), we've been able to run 525/1060 on every unit that's gone out with Noctua fans. Still annoyed at 2-point mounting but the heatsink surface is the biggest problem with heat transfer on the unit you received.
That would also work! I need to wait until my new power supply comes before I can push for higher hash
I've strapped a 60mm 5v fan to the back of the unit and the voltage regulator temp dropped from 64 degrees to 46! Massive drop! On top of that it brought down the ASIC temp from 54 to around 51 which is nice as well. I think a nice 60mm fan on the back isn't a silly idea, especially if you're asking a bit more voltage from the unit
I have this under the unit
https://www.amazon.com/dp/B09QMC1458?ref=ppx_yo2ov_dt_b_fed_asin_title&th=1
I mounted four feet on the miner with some long bolts
https://www.amazon.com/dp/B09QMC1458?ref=ppx_yo2ov_dt_b_fed_asin_title&th=1
50 mm fan
50 mm heat sink
miner
four feet with bolts
so double fan
I am doing
18.6 watts
55 c chip
51 c voltage regulator
freq 490
volts 1060
1th
18.6 watts per th
I've strapped a 60mm 5v fan to the back of the unit and the voltage regulator temp dropped from 64 degrees to 44! Massive drop! On top of that it brought down the ASIC temp from 54 to around 50 which is nice as well. I think a nice 60mm fan on the back isn't a silly idea, especially if you're asking a bit more voltage from the unit
There is another small test: Ice Tower + Noctua and the Argon THRML + Noctua: https://plebbase.com/research/ice-tower-argon-thrml-60mm-and-otzi-bitaxe-gamma-what-can-they-do-62
yeah but the european seller sells the unit with the ice tower and the noctua.
which means easy setup for the miner.
I don’t mind tweaking gear, but I was a bit busy and would have preferred the model to come truly ready out of the box.
the ice tower +noctua is really good gets to freq 600 which is good enough.
There is another small test: Ice Tower + Noctua and the Argon THRML + Noctua: https://plebbase.com/research/ice-tower-argon-thrml-60mm-and-otzi-bitaxe-gamma-what-can-they-do-62
there are many ways to configure the bitaxeGamma in terms of cooling. and as philipma1957 has already said and as mentioned in the blog article, the combination ice tower with the noctua fan is the best one
here you achieve the very best values in terms of the efficiency of the new miner
btw sidehack please check your pm
here you achieve the very best values in terms of the efficiency of the new miner
btw sidehack please check your pm
Also hey Phil, since we started lapping heatsinks (removing the yellow anodize and smoothing any striations or lack of flatness in the surface), we've been able to run 525/1060 on every unit that's gone out with Noctua fans. Still annoyed at 2-point mounting but the heatsink surface is the biggest problem with heat transfer on the unit you received.
"Ice Tower with Noctua NF-A4x20 5V PWM
I was very bullish about the test with the Ice Tower and the Noctua fan, this combination has already produced excellent results on the Bitaxe Ultra and Bitaxe Supra."
https://plebbase.com/research/naked-lama-um-gamma-i-mean-bitaxe-gamma-61
cyan did a ton of research it looks good.
Also hey Phil, since we started lapping heatsinks (removing the yellow anodize and smoothing any striations or lack of flatness in the surface), we've been able to run 525/1060 on every unit that's gone out with Noctua fans. Still annoyed at 2-point mounting but the heatsink surface is the biggest problem with heat transfer on the unit you received.
Someone please talk me out of this...
I'm itching to buy this
https://www.aliexpress.com/item/1005005859027667.html?channel=twinner
And pair it with this
https://www.aliexpress.com/item/1005005671845842.html?channel=twinner
To cool the BitAxe, could always add more units in series too because of the size of the rad. I know it's TOTALLY overkill but damned if it won't look cool haha
I'm itching to buy this
https://www.aliexpress.com/item/1005005859027667.html?channel=twinner
And pair it with this
https://www.aliexpress.com/item/1005005671845842.html?channel=twinner
To cool the BitAxe, could always add more units in series too because of the size of the rad. I know it's TOTALLY overkill but damned if it won't look cool haha
I've done some profiling on my miners (not BitAxe, not its esp miner software, running on a slower single core controller);
Workgen max/avg 2953,1115.783936
PoolWork max/avg 3188,1798.692139
Nonce handling max/avg 4193,545.223022
(all numbers are microseconds)
Explanation: Workgen is the routine that prepares and sends the next (usually sequential in some form of another) job for the asic(s). PoolWork is the routine that receives the work from the pool in json format, decodes it, calculates the merkle root and prepares and sends this work as a job to the asic(s). Nonce handling is the routine that receives the responsre from the asic(s), checks it, and if it has a high enough difficulty, sends it to the pool.
As my controller is single core all routines can be, and are interrupted to handle the wireless communication, which explains the big difference between max and average numbers (I would say the network routines take ~2..2.5ms).
How to interpret these numbers?
First you have to realize that the asics are stand alone hash blocks. You give them a job and they will cycle through the nonce space and version bits and report nonces back to the controller whenever a nonce/version is found that has a high enough difficulty. The controller has to send a new job to them BEFORE they finish cycling through all nonce/version variations. The timing is not critical as long as the controller does not exceed this time.
So, in my case my controller has to send a new job at least every ~4ms to run the asics at full speed (I use ~50ms for my miners, the exact value is calculated by the software and depends on asic type and frequency).
So, now you've made sure the asics run at full speed. That leaves latency and is more difficult to classify. I think (and you may have other ideas) that only the time it takes to handle the nonce and report shares to the pool affects this. On average this takes my controller ~500us. In that 500us another miner might find a valid block solution. This happens on average every 600000ms, so my controller has a 1 in 1200000 chance that its found block solution is stale because of slow processing...
Workgen max/avg 2953,1115.783936
PoolWork max/avg 3188,1798.692139
Nonce handling max/avg 4193,545.223022
(all numbers are microseconds)
Explanation: Workgen is the routine that prepares and sends the next (usually sequential in some form of another) job for the asic(s). PoolWork is the routine that receives the work from the pool in json format, decodes it, calculates the merkle root and prepares and sends this work as a job to the asic(s). Nonce handling is the routine that receives the responsre from the asic(s), checks it, and if it has a high enough difficulty, sends it to the pool.
As my controller is single core all routines can be, and are interrupted to handle the wireless communication, which explains the big difference between max and average numbers (I would say the network routines take ~2..2.5ms).
How to interpret these numbers?
First you have to realize that the asics are stand alone hash blocks. You give them a job and they will cycle through the nonce space and version bits and report nonces back to the controller whenever a nonce/version is found that has a high enough difficulty. The controller has to send a new job to them BEFORE they finish cycling through all nonce/version variations. The timing is not critical as long as the controller does not exceed this time.
So, in my case my controller has to send a new job at least every ~4ms to run the asics at full speed (I use ~50ms for my miners, the exact value is calculated by the software and depends on asic type and frequency).
So, now you've made sure the asics run at full speed. That leaves latency and is more difficult to classify. I think (and you may have other ideas) that only the time it takes to handle the nonce and report shares to the pool affects this. On average this takes my controller ~500us. In that 500us another miner might find a valid block solution. This happens on average every 600000ms, so my controller has a 1 in 1200000 chance that its found block solution is stale because of slow processing...
So even if the bitaxe is 10x slower than
1 out of every 120,000 blocks that it hits will be lost due to it being 10x slower than the controller you have measured.
Considering that the bitaxe world wide has only hit 1 block it was and is unlikely that we will ever see a bitaxe miss a block due to controller speed.
At most maybe the bitaxe will hit 10 blocks a year if it sells a lot more of them.
That would mean 100 blocks in ten years or a 1 in 12000 chance of a stale block
And for all of the above to,be true we are talking 10s of thousands need to be sold.
125,000 bitaxes doing 1th would hit a block every 36-37 days about 10 a year
Of course the more likely reason to go stale is long ping times.
So maybe the low cost 32 chip will never be an issue.
My unit is plugging along nicely set to freq,460 volt 1060
I've done some profiling on my miners (not BitAxe, not its esp miner software, running on a slower single core controller);
Workgen max/avg 2953,1115.783936
PoolWork max/avg 3188,1798.692139
Nonce handling max/avg 4193,545.223022
(all numbers are microseconds)
Explanation: Workgen is the routine that prepares and sends the next (usually sequential in some form of another) job for the asic(s). PoolWork is the routine that receives the work from the pool in json format, decodes it, calculates the merkle root and prepares and sends this work as a job to the asic(s). Nonce handling is the routine that receives the response from the asic(s), checks it, and if it has a high enough difficulty, sends it to the pool.
As my controller is single core all routines can be, and are interrupted to handle the wireless communication, which explains the big difference between max and average numbers (I would say the network routines take ~2..2.5ms).
How to interpret these numbers?
First you have to realize that the asics are stand alone hash blocks. You give them a job and they will cycle through the nonce space and version bits and report nonces back to the controller whenever a nonce/version is found that has a high enough difficulty. The controller has to send a new job to them BEFORE they finish cycling through all nonce/version variations. The timing is not critical as long as the controller does not exceed this time.
So, in my case my controller has to send a new job at least ~4ms before the cycling finishes to run the asics at full speed (I use ~50ms for my miners, the exact value is calculated by the software and depends on asic type and frequency, see bottom of post for details).
So, now you've made sure the asics run at full speed. That leaves latency and is more difficult to classify. I think (and you may have other ideas) that only the time it takes to handle the nonce and report shares to the pool affects this. On average this takes my controller ~500us. In that 500us another miner might find a valid block solution. This happens on average every 600000ms, so my controller has a 1 in 1200000 chance that its found block solution is stale because of slow processing...
Job timing:
Tjob = (Nonce range * #Version variations asic cycles through) / (Asic Frequency * #cores * #asics) * latency safety margin
where
Nonce range is the range that the asics cycle through (2^32 in a perfect world, but antminer asics do not search the entire range, eg the bm1366 searches from 00000000h upto DFFFFFFFh).
#version variations is between 1 and FFFFh depending on configuration, default is 8.
#cores depends on asic type, the bm1366 has ~894
latency safety margin is used to lower Tjob to prevent latency in the wireless routines prevent supplying a new job in time to the asics. I use 0.8.
So, for a 500MHz bm1366 you get (3758096383 * 8 ) / (500000000 * 894 * 1) * 0.8 = 0.0538s
Workgen max/avg 2953,1115.783936
PoolWork max/avg 3188,1798.692139
Nonce handling max/avg 4193,545.223022
(all numbers are microseconds)
Explanation: Workgen is the routine that prepares and sends the next (usually sequential in some form of another) job for the asic(s). PoolWork is the routine that receives the work from the pool in json format, decodes it, calculates the merkle root and prepares and sends this work as a job to the asic(s). Nonce handling is the routine that receives the response from the asic(s), checks it, and if it has a high enough difficulty, sends it to the pool.
As my controller is single core all routines can be, and are interrupted to handle the wireless communication, which explains the big difference between max and average numbers (I would say the network routines take ~2..2.5ms).
How to interpret these numbers?
First you have to realize that the asics are stand alone hash blocks. You give them a job and they will cycle through the nonce space and version bits and report nonces back to the controller whenever a nonce/version is found that has a high enough difficulty. The controller has to send a new job to them BEFORE they finish cycling through all nonce/version variations. The timing is not critical as long as the controller does not exceed this time.
So, in my case my controller has to send a new job at least ~4ms before the cycling finishes to run the asics at full speed (I use ~50ms for my miners, the exact value is calculated by the software and depends on asic type and frequency, see bottom of post for details).
So, now you've made sure the asics run at full speed. That leaves latency and is more difficult to classify. I think (and you may have other ideas) that only the time it takes to handle the nonce and report shares to the pool affects this. On average this takes my controller ~500us. In that 500us another miner might find a valid block solution. This happens on average every 600000ms, so my controller has a 1 in 1200000 chance that its found block solution is stale because of slow processing...
Job timing:
Tjob = (Nonce range * #Version variations asic cycles through) / (Asic Frequency * #cores * #asics) * latency safety margin
where
Nonce range is the range that the asics cycle through (2^32 in a perfect world, but antminer asics do not search the entire range, eg the bm1366 searches from 00000000h upto DFFFFFFFh).
#version variations is between 1 and FFFFh depending on configuration, default is 8.
#cores depends on asic type, the bm1366 has ~894
latency safety margin is used to lower Tjob to prevent latency in the wireless routines prevent supplying a new job in time to the asics. I use 0.8.
So, for a 500MHz bm1366 you get (3758096383 * 8 ) / (500000000 * 894 * 1) * 0.8 = 0.0538s
So some say the controller is too slow and some say it is not to slow.
I know
fuzzy
kano
sidehack
have been here a long time
I do not know skot very well = the designer of this gear. he claims the controller is good enough.
I am not so sure how to clearly demo speed of dueling controllers on a 1 chip unit.
Since I do not know how to do this if someone can clearly demo controller speed on a 1 chip 1370 bitaxe
vs controller speed on any other 1 chip 1370 miner please show it to us.
for know I am playing with heatsink and cooling.
freq of 525
volt of 1100 below
pretty stable
I know
fuzzy
kano
sidehack
have been here a long time
I do not know skot very well = the designer of this gear. he claims the controller is good enough.
I am not so sure how to clearly demo speed of dueling controllers on a 1 chip unit.
Since I do not know how to do this if someone can clearly demo controller speed on a 1 chip 1370 bitaxe
vs controller speed on any other 1 chip 1370 miner please show it to us.
for know I am playing with heatsink and cooling.
freq of 525
volt of 1100 below
pretty stable
As has been pointed out in other threads, the ESP32 micro-controller used is an extraordinarily poor choice for miners. It is made for use in very simple IoT devices such as sensors, thermostats, wearables, etc. that do not need good performance. Even the maker of them clearly states that. Even the best one only has 2 cores/threads which means that at best it can process hashes and do I/O without having to interrupt the processes provided the main and I/O threads are programmed to run independently. AFAIK the one used in the BitAxe has only 1 core...
All of that out of the way, does it work? Sure - but when there is a change of work and when it talks to the WiFi things slow down a lot. Because Skot is/was an IoT developer it makes some sense that he'd pick the ESP32 just because he is familiar with it. Unfortunately he did not know that you REALLY need a REAL multi-core/threaded CPU to ensure decent performance so the various processes running do not have to interrupt each other. Even the original RasPi-1 used a more capable chip. ref https://www.elprocus.com/difference-between-esp32-vs-raspberry-pi/
FYI, while the 1st ones from Sidehack will be using the same micro he is already redesigning it to use the Pi Nano to eliminate the processing bottlenecks and also allow using USB along with hardwired LAN connections.
edit: struckout comment on redesign.
Sorry for the long quote..All of that out of the way, does it work? Sure - but when there is a change of work and when it talks to the WiFi things slow down a lot. Because Skot is/was an IoT developer it makes some sense that he'd pick the ESP32 just because he is familiar with it. Unfortunately he did not know that you REALLY need a REAL multi-core/threaded CPU to ensure decent performance so the various processes running do not have to interrupt each other. Even the original RasPi-1 used a more capable chip. ref https://www.elprocus.com/difference-between-esp32-vs-raspberry-pi/
edit: struckout comment on redesign.
But I'll post some facts so everyone can form their own opinion;
- The average blocktime is 10 min. (600.000ms)
- My single core esp32-c3's need less than 1ms to check (including crc check/difficulty check/stale check) and submit a found nonce.
- The wireless connection has a sub 20ms latency
- Latency to the pool (solo.ckpool.org for me) including the wireless latency is around 50ms
So, according to my poor math due to the very slow esp32 I will get an additional rejected share every 12.000 submitted shares, ... I know, its shocking
In reality my rejected shares are anywhere between 1 in 750 .. 3000 shares submitted (depending on connection/pool load?).
In short: the speed of the controller does not in any way/shape or form matter. You can overload an esp32 by (mis)configuring the asic(s), but why would you do that?
...
Sigh ...
Quote
The hash rate of the miner is just the miner ... and it's design and code.
The catch with the esp32 is that it takes milliseconds to change work - that's a problem. Doesn't matter if it only needs work every 2 seconds, BUT for a network block change, it needs the work as soon as the network sends new work to the miner. Delaying that is bad, microseconds are OK, but milliseconds are not. Consider if you are 5ms from a pool node and your miner is slower to change work than the pool can send work to you - doesn't that sound like a bad idea - especially as it's not necessary at all if you use a normal controller. Every miner except the bitaxe does use an appropriate controller.
On top of all that, the mining process itself is time dependent. You want things to happen quickly and data to be sent and received quickly. Nonces coming back from the chips to be processed quickly and network sends of that data to the pool to be quick. Why on earth would you choose a controller that's about 500 times slower than all the others?
Oh you can save $5 - wow what a fucking stupid design.
The catch with the esp32 is that it takes milliseconds to change work - that's a problem. Doesn't matter if it only needs work every 2 seconds, BUT for a network block change, it needs the work as soon as the network sends new work to the miner. Delaying that is bad, microseconds are OK, but milliseconds are not. Consider if you are 5ms from a pool node and your miner is slower to change work than the pool can send work to you - doesn't that sound like a bad idea - especially as it's not necessary at all if you use a normal controller. Every miner except the bitaxe does use an appropriate controller.
On top of all that, the mining process itself is time dependent. You want things to happen quickly and data to be sent and received quickly. Nonces coming back from the chips to be processed quickly and network sends of that data to the pool to be quick. Why on earth would you choose a controller that's about 500 times slower than all the others?
Oh you can save $5 - wow what a fucking stupid design.Now if you wanna know work generation time in cgminer, run a gekko and read it.
It's not a 'Oh wow I got one work to generate superfast', it's there for all work it generates while mining, with a total and average time.
✂️
So pretty sure that finding a better heatsink is the way to go.
I have multiple ones to test.
And a new fan coming.
✂️
So pretty sure that finding a better heatsink is the way to go.
I have multiple ones to test.
And a new fan coming.
✂️
if you are already testing, i would highly recommend this great blog article. i also posted it here a few days ago.
you are sure to find a suitable setup for your bitaxeGamma
https://plebbase.com/research/naked-lama-um-gamma-i-mean-bitaxe-gamma-61
your blog and sidehacks suggestion is why I started playing with heatsinks .
it was a good read.
at helso yeah i can get it up to freq 525 and 1150volt
which is close to 22 watts. not quite stable at that setting. but I think when I get the new fan it will be able to run the default
525
1150
for days on end
✂️
So pretty sure that finding a better heatsink is the way to go.
I have multiple ones to test.
And a new fan coming.
✂️
So pretty sure that finding a better heatsink is the way to go.
I have multiple ones to test.
And a new fan coming.
✂️
if you are already testing, i would highly recommend this great blog article. i also posted it here a few days ago.
you are sure to find a suitable setup for your bitaxeGamma
https://plebbase.com/research/naked-lama-um-gamma-i-mean-bitaxe-gamma-61
Agreed, I think it's just about finding the right fan/heatsink combo. Whether I'll settle on this or try something else I don't know but it definitely is surprising just how much heat such a little chip can pump out.
Then again, shouldn't really be surprised, my no-limits 14900K can chug down 400~W at full tilt which necessitated direct die cooling. I did think about putting this thing under water but I think just a few $$$ too many for such a small project; I did find a nice block however
Then again, shouldn't really be surprised, my no-limits 14900K can chug down 400~W at full tilt which necessitated direct die cooling. I did think about putting this thing under water but I think just a few $$$ too many for such a small project; I did find a nice block however
Stock for now, like I said, no time. But I plan to return to it in the next day or two. I think this fan is definitely the limiting factor here now; that and I need a better PSU which is also on the way.
Only issue now is the heatsinks weight makes the stand topple over, I'll need to do some modifying there too. The game never ends but boy do I love to tinker
Only issue now is the heatsinks weight makes the stand topple over, I'll need to do some modifying there too. The game never ends but boy do I love to tinker
Well cygan myself and you all got much better results using better heatsinks.
So pretty sure that finding a better heatsink is the way to go.
I have multiple ones to test.
And a new fan coming.
The mean well psu I linked above is really good and it allows 4.5 to 5.5 volts at up to 18 amps.
I have yet to settle on heatsink and fan.
Stock for now, like I said, no time. But I plan to return to it in the next day or two. I think this fan is definitely the limiting factor here now; that and I need a better PSU which is also on the way.
Only issue now is the heatsinks weight makes the stand topple over, I'll need to do some modifying there too. The game never ends but boy do I love to tinker
Only issue now is the heatsinks weight makes the stand topple over, I'll need to do some modifying there too. The game never ends but boy do I love to tinker
Jump to: