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