Search content
Sort by
Showing 20 of 23 results by rapsacw
⭐ Merited by NotFuzzyWarm (1)
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...
⭐ Merited by philipma1957 (1)
this is interesting but I believe it is for the 1368 or 1366 chip correct?
the 1370 chip would do 1000 gh or maybe 1100 gh at your freq.
which is double the work. which would mean more rejects .
That's where the configuring of the asic comes in. The speed of the asic is not (meaningfully) related to the work the controller needs to do when the asic(s) are correctly configured. You can configure the asic to require few work updates and also produce only high difficulty (and thus rarely occurring) results. The only hard limit on the maximum #asics a controller can handle is the number of asic strings that can be connected to the controller and that depends on the number of serial ports the controller has.the 1370 chip would do 1000 gh or maybe 1100 gh at your freq.
which is double the work. which would mean more rejects .
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?
..
I have now reworked a few things.
1. I supply the VDDIO_18 pin with 1.2V (using the chips power supply)
2. Checked if the crystal oscillator is still working with 1.2V and it is.
I did not look at your schematics, but you can (and should if you want to save cost) use Vcore for 1.2V. I have all my miners converted to 1.2V this way. Also you can make the 0.8V with a simple resistor divider from the Vcore (any voltage between 0.7V and 0.95V will work in my testing). The asic draws less than 10mA on the 0.8V line.I have now reworked a few things.
1. I supply the VDDIO_18 pin with 1.2V (using the chips power supply)
2. Checked if the crystal oscillator is still working with 1.2V and it is.
.. I think I would love to have such miner in my house running all the time like heater in the corner. I would be more than happy to pay the bills for it since it will be generating something all the time. I am anyway holder of bitcoin so if they just mine and sit in my wallet then also I would be more than happy.
However, this has to be real simple layman consumable product with not much wirings, not much maintenance kind of stuff. Since I am not a hard core miner I would be more focused on the hobby scale and flashing it as if I do mine.
The only practical heating use I can think of is an egg incubator for 1-5 eggs The miner is 'fire and forget' once you've got it running. It will start mining after power up without intervention. The configuration isn't hard either. That leaves the assembly; I'm not going to produce complete kits for different reasons, so in the end you will have to at least fix the heatsink (not sure if I will sell them with the pcb) and fan (ditto) to the pcb (and apply thermal compound), either using tie wraps (that is what I am using rn) or 3d printed or laser cut brackets, and get a suitable usb charger + usb-c cable (and optional usb trigger pcb so you can power the miner with 9V). You can find some more info on this here https://github.com/rapsacw/aSiNine_and8
⭐ Merited by JayJuanGee (1)
Seriously?
Took me less than an hour to analyse the work data control necessary for an S19 chip.
Of course someone else spent many hours connecting up all the hardware to dump and format the data so I could do it,
but if you're gonna say it's that hard without trying, then I'd worry about anyone using anything you built.
While 'we' do already have the info to do a 3rd party miner with the chip, unfortunately it's not a priority at the moment
Ok, now try to do it without access to miner (and a pool(emulation) so you know what data is send to the chips) Took me less than an hour to analyse the work data control necessary for an S19 chip.
Of course someone else spent many hours connecting up all the hardware to dump and format the data so I could do it,
but if you're gonna say it's that hard without trying, then I'd worry about anyone using anything you built.
While 'we' do already have the info to do a 3rd party miner with the chip, unfortunately it's not a priority at the moment
I've got a diy logger, but no miner.. The hardware side is not a big problem though.
I've done my part in dissecting protocols and the underlying meaning of the data that goes over a unknown bus by analyzing the communication of the meade autostar system and constructed a meade compatible servo and stepper motor driver for astro mounts and I'm sure I could do likewise with x19(+) miners, but without a miner??
I do find it strange that info on X19(+) miners isn't available years after the release of the miners.
On my standalone BM1397 miner; the revised revision
pcb's have arrived and I've built one prototype. Regarding the cost (if you desperately want to know), the bom is something like this (missing the usb connector and optional DG301 screw terminal):Code:
Part Value Device Package Description MF MPN OC_FARNELL OC_NEWARK PROD_ID
C1,C2,C3,C4,C6,C12,C13,C14,C15,C20,C35,[C37],C38 4.7uF/16V C-EUC0402 C0402 CAPACITOR, European symbol
C5 56pF C-EUC0402 C0402 CAPACITOR, European symbol
C7,C10,C11,C21,C24,C36,C31,C34 100nF C-EUC0402 C0402 CAPACITOR, European symbol
C8,C9,C18,C26 22uF/25V C-EUC0805 C0805 CAPACITOR, European symbol
C16,C17,C22,C23 47uF/6.3V C-EUC0805 C0805 CAPACITOR, European symbol
D1 WS2812 WS2812_5050 WS2812-5X5-4PIN Addressable RGB LED - 1 Wire DIO-12503
ESP32C3-MINI-1 ESP32-C3-MINI-1 ESP32C3MINI ESP32C3MINI
L$2 3.3uH NR201610 NR201610
L4 1uh R-EU_R0402 R0402 RESISTOR, European symbol
R1 49.9k R-EU_R0402 R0402 RESISTOR, European symbol
R2,R4,R10 2k2 R-EU_R0402 R0402 RESISTOR, European symbol
R3,R5 1k5 R-EU_R0402 R0402 RESISTOR, European symbol
R6,R7,R8,R29,R36,R41 1k R-EU_R0402 R0402 RESISTOR, European symbol
R9 82k R-EU_R0402 R0402 RESISTOR, European symbol
R11 20R R-EU_R0402 R0402 RESISTOR, European symbol
R12,R17,R40,R31 4k7 R-EU_R0402 R0402 RESISTOR, European symbol
R13,R25,R26 15k R-EU_R0402 R0402 RESISTOR, European symbol
R14 22R R-EU_R0402 R0402 RESISTOR, European symbol
R16,R22 5k1 R-EU_R0402 R0402 RESISTOR, European symbol
R18 30k R-EU_R0402 R0402 RESISTOR, European symbol
R34 33k R-EU_R0603 R0603 RESISTOR, European symbol
R35 22k R-EU_R0402 R0402 RESISTOR, European symbol
R37 ntc 33k B3950 R-EU_R0402 R0402 RESISTOR, European symbol
T1 2N3904 2N3904 SOT23 NPN TRANSISTOR
U$1 BM1397-1 BM1397AG BM1391
U$2 TPS56C2150Z6-7 TPS56C2150Z6-7 VQFN-HR
U$3 0.68uH L10040 L10040
U$4 XC6206P18 XC6206P SOT23
U$7 SY8113A SY8113A SOT23L-6
U$14 PT8211S PT8211 SO-8
U$22 25MHz OSC3225 3225 Active oscillator 25MHz 3225 1.8V
Most parts are available at jlcpcb (except the bm1397ag) but as good as all parts are extended parts (meaning $3,- per part, ~$100,- per batch of upto 30pcs on top of the part prices).C1,C2,C3,C4,C6,C12,C13,C14,C15,C20,C35,[C37],C38 4.7uF/16V C-EUC0402 C0402 CAPACITOR, European symbol
C5 56pF C-EUC0402 C0402 CAPACITOR, European symbol
C7,C10,C11,C21,C24,C36,C31,C34 100nF C-EUC0402 C0402 CAPACITOR, European symbol
C8,C9,C18,C26 22uF/25V C-EUC0805 C0805 CAPACITOR, European symbol
C16,C17,C22,C23 47uF/6.3V C-EUC0805 C0805 CAPACITOR, European symbol
D1 WS2812 WS2812_5050 WS2812-5X5-4PIN Addressable RGB LED - 1 Wire DIO-12503
ESP32C3-MINI-1 ESP32-C3-MINI-1 ESP32C3MINI ESP32C3MINI
L$2 3.3uH NR201610 NR201610
L4 1uh R-EU_R0402 R0402 RESISTOR, European symbol
R1 49.9k R-EU_R0402 R0402 RESISTOR, European symbol
R2,R4,R10 2k2 R-EU_R0402 R0402 RESISTOR, European symbol
R3,R5 1k5 R-EU_R0402 R0402 RESISTOR, European symbol
R6,R7,R8,R29,R36,R41 1k R-EU_R0402 R0402 RESISTOR, European symbol
R9 82k R-EU_R0402 R0402 RESISTOR, European symbol
R11 20R R-EU_R0402 R0402 RESISTOR, European symbol
R12,R17,R40,R31 4k7 R-EU_R0402 R0402 RESISTOR, European symbol
R13,R25,R26 15k R-EU_R0402 R0402 RESISTOR, European symbol
R14 22R R-EU_R0402 R0402 RESISTOR, European symbol
R16,R22 5k1 R-EU_R0402 R0402 RESISTOR, European symbol
R18 30k R-EU_R0402 R0402 RESISTOR, European symbol
R34 33k R-EU_R0603 R0603 RESISTOR, European symbol
R35 22k R-EU_R0402 R0402 RESISTOR, European symbol
R37 ntc 33k B3950 R-EU_R0402 R0402 RESISTOR, European symbol
T1 2N3904 2N3904 SOT23 NPN TRANSISTOR
U$1 BM1397-1 BM1397AG BM1391
U$2 TPS56C2150Z6-7 TPS56C2150Z6-7 VQFN-HR
U$3 0.68uH L10040 L10040
U$4 XC6206P18 XC6206P SOT23
U$7 SY8113A SY8113A SOT23L-6
U$14 PT8211S PT8211 SO-8
U$22 25MHz OSC3225 3225 Active oscillator 25MHz 3225 1.8V
Efficiency is at 12.5W @ 300GHs when fed with 9V (according to my crappy usb power meter), live stats still on https://solo.ckpool.org/users/1KgwWwBh7qGtcWJ9ZRNTUbVCR1L2qYkzcy (workername": "1KgwWwBh7qGtcWJ9ZRNTUbVCR1L2qYkzcy.test1397_12B")
The target user of this little miner isn't looking for 100W+ miners, they can buy one new from antminer. Furthermore 22Ghs/W is in the (distant) future because there is little to no information on the newer chips making 3rd party miners impossible. As I said in the opening post; these are not meant to be run on a normal pool, but can be used to solo mine (with a chance of ~1:25000 of finding a block per year) giving a better chance of a substantial prize than a lottery ticket. And you will learn a few things running such a small miner, such as what big numbers really mean, how pools work, how to run a miner at peak efficiency, how to cool electronics etc.
Re: The bitaxeUltra: Open source Bitcoin miner based on the BM1366 ASIC
Let me start with 
I'm watching this for sure! I've got a few remarks after looking at the schematics. I presume you've got the bm1366's connections from tracing the signals on a hash board and not from an 'official' repair guide? There are a few things that stand out to me and might be worth looking in to;
- the mode_0(in) and mode_1 signals are connected together.
&&
- the decoupling caps c4 & c16 are connected to to these pins
To me it seems as both pins are actually ground (vss). You can check for connection of these pins with the big ground pad to see if that is correct.
- the mode_0 pin is left floating for mode0
Antminer has previously defined mode0 as mode_0 pin connected to ground.
Changing the description of these pins and of the mode does not change the functionality of anything but seems more correct to me (if the 2 connected pins are actually vss).
Did you find a way to log the communication with the hash boards or are you going the software disassembly route first?
I'm watching this for sure! I've got a few remarks after looking at the schematics. I presume you've got the bm1366's connections from tracing the signals on a hash board and not from an 'official' repair guide? There are a few things that stand out to me and might be worth looking in to;
- the mode_0(in) and mode_1 signals are connected together.
&&
- the decoupling caps c4 & c16 are connected to to these pins
To me it seems as both pins are actually ground (vss). You can check for connection of these pins with the big ground pad to see if that is correct.
- the mode_0 pin is left floating for mode0
Antminer has previously defined mode0 as mode_0 pin connected to ground.
Changing the description of these pins and of the mode does not change the functionality of anything but seems more correct to me (if the 2 connected pins are actually vss).
Did you find a way to log the communication with the hash boards or are you going the software disassembly route first?
⭐ Merited by vapourminer (1)
hey skot, I need the pinouts and possibly the datasheets for BM1387 and also the register map, would you be able to help?
The closest thing to a register map I found is thisCode:
package axi_bm13xx_pkg;
// ---------------------------------------------------------------------------------------------
// clock parameter
time CLK_PERIOD = 20ns;
// ---------------------------------------------------------------------------------------------
// Definition of IP core AXI interface
// ---------------------------------------------------------------------------------------------
// IP Core Version Register, read-only
parameter VERSION = 32'h0000;
// Build ID Register, read-only
parameter BUILD_ID = 32'h0004;
// Control Register, read/write
parameter CTRL_REG = 32'h0008;
// Status Register - reserved, read-only
parameter STAT_REG = 32'h000C;
// Baudrate Divisor Register, read/write
parameter BAUD_REG = 32'h0010;
// Work Time Delay Register, read/write
parameter WORK_TIME = 32'h0014;
// Error Counter Register, read-only
parameter ERR_COUNTER = 32'h0018;
// Command Receive Interface FIFO, read-only
parameter CMD_RX_FIFO = 32'h1000;
// Command Transmit Interface FIFO, write-only
parameter CMD_TX_FIFO = 32'h1004;
// Command Control Register, read/write
parameter CMD_CTRL_REG = 32'h1008;
// Command Status Register, read-only
parameter CMD_STAT_REG = 32'h100C;
// Work Receive Interface FIFO, read-only
parameter WORK_RX_FIFO = 32'h2000;
// Work Receive Control Register, read/write
parameter WORK_RX_CTRL_REG = 32'h2008;
// Work Receive Status Register, read-only
parameter WORK_RX_STAT_REG = 32'h200C;
// Work Transmit Interface FIFO, write-only
parameter WORK_TX_FIFO = 32'h3004;
// Work Transmit Control Register, read/write
parameter WORK_TX_CTRL_REG = 32'h3008;
// Work Transmit Status Register, read-only
parameter WORK_TX_STAT_REG = 32'h300C;
// Work Transmit IRQ Threshold, read/write
parameter WORK_TX_IRQ_THR = 32'h3010;
// Work Transmit Last Work ID, read-only
parameter WORK_TX_LAST_ID = 32'h3014;
// ---------------------------------------------------------------------------------------------
// Control Registers
// ---------------------------------------------------------------------------------------------
// Enable support for chips BM1391, BM1397
parameter CTRL_BM139X = 32'h10;
// Enable, read/write
parameter CTRL_ENABLE = 32'h8;
// Number of midstates per work, encoded as log2 of values: 1, 2, 4, read/write
parameter CTRL_MIDSTATE_1 = 32'h0;
parameter CTRL_MIDSTATE_2 = 32'h2;
parameter CTRL_MIDSTATE_4 = 32'h4;
// Clear error counter, write-only
parameter CTRL_ERR_CNT_CLEAR = 32'h1;
// Enable interrupt, read/write
parameter CTRL_IRQ_EN = 32'h4;
// Reset/clear Transmit FIFO, write-only
parameter CTRL_RST_TX_FIFO = 32'h2;
// Reset/clear Receive FIFO, write-only
parameter CTRL_RST_RX_FIFO = 32'h1;
// ---------------------------------------------------------------------------------------------
// Status Registers - read-only
// ---------------------------------------------------------------------------------------------
// Interrupt pending for Work Receive FIFO
parameter STAT_IRQ_PEND = 32'h10;
// Work Interface Transmit FIFO Full
parameter STAT_TX_FULL = 32'h08;
// Work Interface Transmit FIFO Empty
parameter STAT_TX_EMPTY = 32'h04;
// Work Interface Receive FIFO Full
parameter STAT_RX_FULL = 32'h02;
// Work Interface Receive FIFO Empty
parameter STAT_RX_EMPTY = 32'h01;
endpackage : axi_bm13xx_pkg
// ---------------------------------------------------------------------------------------------
// clock parameter
time CLK_PERIOD = 20ns;
// ---------------------------------------------------------------------------------------------
// Definition of IP core AXI interface
// ---------------------------------------------------------------------------------------------
// IP Core Version Register, read-only
parameter VERSION = 32'h0000;
// Build ID Register, read-only
parameter BUILD_ID = 32'h0004;
// Control Register, read/write
parameter CTRL_REG = 32'h0008;
// Status Register - reserved, read-only
parameter STAT_REG = 32'h000C;
// Baudrate Divisor Register, read/write
parameter BAUD_REG = 32'h0010;
// Work Time Delay Register, read/write
parameter WORK_TIME = 32'h0014;
// Error Counter Register, read-only
parameter ERR_COUNTER = 32'h0018;
// Command Receive Interface FIFO, read-only
parameter CMD_RX_FIFO = 32'h1000;
// Command Transmit Interface FIFO, write-only
parameter CMD_TX_FIFO = 32'h1004;
// Command Control Register, read/write
parameter CMD_CTRL_REG = 32'h1008;
// Command Status Register, read-only
parameter CMD_STAT_REG = 32'h100C;
// Work Receive Interface FIFO, read-only
parameter WORK_RX_FIFO = 32'h2000;
// Work Receive Control Register, read/write
parameter WORK_RX_CTRL_REG = 32'h2008;
// Work Receive Status Register, read-only
parameter WORK_RX_STAT_REG = 32'h200C;
// Work Transmit Interface FIFO, write-only
parameter WORK_TX_FIFO = 32'h3004;
// Work Transmit Control Register, read/write
parameter WORK_TX_CTRL_REG = 32'h3008;
// Work Transmit Status Register, read-only
parameter WORK_TX_STAT_REG = 32'h300C;
// Work Transmit IRQ Threshold, read/write
parameter WORK_TX_IRQ_THR = 32'h3010;
// Work Transmit Last Work ID, read-only
parameter WORK_TX_LAST_ID = 32'h3014;
// ---------------------------------------------------------------------------------------------
// Control Registers
// ---------------------------------------------------------------------------------------------
// Enable support for chips BM1391, BM1397
parameter CTRL_BM139X = 32'h10;
// Enable, read/write
parameter CTRL_ENABLE = 32'h8;
// Number of midstates per work, encoded as log2 of values: 1, 2, 4, read/write
parameter CTRL_MIDSTATE_1 = 32'h0;
parameter CTRL_MIDSTATE_2 = 32'h2;
parameter CTRL_MIDSTATE_4 = 32'h4;
// Clear error counter, write-only
parameter CTRL_ERR_CNT_CLEAR = 32'h1;
// Enable interrupt, read/write
parameter CTRL_IRQ_EN = 32'h4;
// Reset/clear Transmit FIFO, write-only
parameter CTRL_RST_TX_FIFO = 32'h2;
// Reset/clear Receive FIFO, write-only
parameter CTRL_RST_RX_FIFO = 32'h1;
// ---------------------------------------------------------------------------------------------
// Status Registers - read-only
// ---------------------------------------------------------------------------------------------
// Interrupt pending for Work Receive FIFO
parameter STAT_IRQ_PEND = 32'h10;
// Work Interface Transmit FIFO Full
parameter STAT_TX_FULL = 32'h08;
// Work Interface Transmit FIFO Empty
parameter STAT_TX_EMPTY = 32'h04;
// Work Interface Receive FIFO Full
parameter STAT_RX_FULL = 32'h02;
// Work Interface Receive FIFO Empty
parameter STAT_RX_EMPTY = 32'h01;
endpackage : axi_bm13xx_pkg
⭐ Merited by n0nce (1)
Just to follow up on this; I have noticed a single S19XP hashboard with a chain of 110 ASICs (BM1366), running at 46 TH/s sends out new work to the whole chain every 2.14s
if it were just rolling nonce, the chain would need new work every 93us
Its a shame there is so little info on the newer chips.if it were just rolling nonce, the chain would need new work every 93us
On a happier note; my redesigned version can be pushed to 350GHs+, and on a sad note; the 3.3V regulator from Mouser is either fake or junk as it blows instantly when fed with 12V (also blew up the esp), so I will have to do another version yet again with another regulator which will again take a month to produce/test.
..
Alas that code doesn't consider the actual restrictions in bitcoin.
He has no idea about it.
I am not going to risc it and limit ntime rolling to a safe 60s, this should workAlas that code doesn't consider the actual restrictions in bitcoin.
He has no idea about it.
Quote
/*
* Create block header for new job by incrementing ntime and/or xnonce2,
* calls Header_construct to create a new binary block header.
*/
void Header_nextjob()
{
// m_ntimeBCKUP contains the ntime value received from pool
// m_Tntime contains the time (in ms) when work was received from pool
if(ROLLNTIME && (m_RollednTime<(MAX_NTIME_ROLL+(millis()-m_Tntime))/1000))
{
inc_4bin(m_ntime); // increment nTime
m_RollednTime++;
Header_construct(0); // contruct new block header, don't calculate new merkle
}
else
{
inc_nbin(m_xnonce2,m_xnonce2sz);
memcpy(m_ntime,m_ntimeBCKUP,4); // restore ntime to unrolled value
m_RollednTime = 0;
Header_construct(1); // construct new block header, calculate new merkle
}
}
where MAX_NTIME_ROLL = 60* Create block header for new job by incrementing ntime and/or xnonce2,
* calls Header_construct to create a new binary block header.
*/
void Header_nextjob()
{
// m_ntimeBCKUP contains the ntime value received from pool
// m_Tntime contains the time (in ms) when work was received from pool
if(ROLLNTIME && (m_RollednTime<(MAX_NTIME_ROLL+(millis()-m_Tntime))/1000))
{
inc_4bin(m_ntime); // increment nTime
m_RollednTime++;
Header_construct(0); // contruct new block header, don't calculate new merkle
}
else
{
inc_nbin(m_xnonce2,m_xnonce2sz);
memcpy(m_ntime,m_ntimeBCKUP,4); // restore ntime to unrolled value
m_RollednTime = 0;
Header_construct(1); // construct new block header, calculate new merkle
}
}
Thanks.
Nearly every stratum pool I have seen supports the version-rolling extension. that adds a version_bits field to mining.submit. afaik It's necessary to support ASICboost.
You learn something everyday. I've not seen any reference to this extension.Quote
Where does 60x come from? every 30s is pretty leisurely compared to every 8ms @ 500 GH/s with nonce rolling alone!
I don't know where I've read that you may only increase ntime, and only upto 60 seconds. Reading ck's pool source I findQuote
/* Ntime cannot be less, but allow forward ntime rolling up to max */
if (ntime32 < wb->ntime32 || ntime32 > wb->ntime32 + 7000) {
err = SE_NTIME_INVALID;
So at least ckpool allows upto 7000x! No more xnonce2 rollover needed for small miners if (ntime32 < wb->ntime32 || ntime32 > wb->ntime32 + 7000) {
err = SE_NTIME_INVALID;
Quote
120 TH/s over 3 hashboards = 40 TH/s each, which means each hashboard can cover the 32 bit nonce space in 0.1ms. The newer ASICs have more midstates too, so that means bigger job packet. No way serial can keep up. It makes sense that they would include some sort of work generation on-chip. I'm really curious which field they are rolling.
Exactly.Whoa! This is blowing mind! Is the BM1398 (and BM1362) version rolling on the chip?? I would love to learn more about this.
Or maybe they are ntime rolling? I guess that’s a lot easier.
Version rolling is not possible with most (stratum V1) pools; the ticket send back to the pool does not include nversion. ntime is no problem though, but you 'only' gain 60x with that, so you will only have to send work to a single asic @250GHs once for every work from the pool, or even @500GHs on ck's pool (as the work time is now reduced from 60s to 30s). Some sort of block generation will be unavoidable sooner or later unless they do something with the serial interface to make it fast enough (a normal T17 needs a ~1.5Mbaud connection between the asics, to a S19j @120GHs would need roughly 3 times that speed without block generation).Or maybe they are ntime rolling? I guess that’s a lot easier.
Yes indeed the 'ticket mask' decides on nonces returned, and yes you still have to send work every few ms for a number of BM1397.
Alas I'm not sure what this overpowered computer is that you seem to think you need.
For a single BM1397 you can run about a dozen on tiny RPi power
That's about the block generation on the controller, and that's not hard to do even on tiny hardware (to be more specific regarding the esp32-c3; its a single core that also has to do the wireless comms, and the time needed for that depends on the link quality and so does the jitter in block generation timing).Alas I'm not sure what this overpowered computer is that you seem to think you need.
For a single BM1397 you can run about a dozen on tiny RPi power
"irrelevant" is badly chosen. I mean it is unavoidable to always have to send work updates, whereas tickets posted by the miner can be avoided by choosing a high difficulty.
I'm no pool operator (obviously), but keeping connections up will use up some memory and every client connected increases the latency. As I don't know the specifics I won't go into that, like I said, maybe CK can answer that.
I'll practice with the 'quote' button more so I'll only post a single replies to a topic instead of a reply to every post I quoted.
I'm no pool operator (obviously), but keeping connections up will use up some memory and every client connected increases the latency. As I don't know the specifics I won't go into that, like I said, maybe CK can answer that.
I'll practice with the 'quote' button more so I'll only post a single replies to a topic instead of a reply to every post I quoted.
(*) I'm not sure if any (solo) pool will support low hash rate miners in the future. Pool operators have to pay for their hardware and connection, and a low hash rate miner costs them as much as a complete mining farm. Maybe CK can answer that.
I think 0.2th - 0.25th is and will be for a good period of time enough hashrate to reasonably connect to any mining pool, it's completely fine if I get a valid share every 5 mins instead of every 5 seconds, the pool manages its resources through share difficulty and the hashrate of the device is irrelevant to them, they maintain certain traffic between their server and your miner/proxy by raising/lowering the difficulty.
Now the real question is, what is the price tag? I know you said you don't know, for you to get answers you need to find the answer to that question first, i might be interested in buying a few if it was $50, maybe buy 1-2 if it was $100, ditch the idea altogether if it was $200, so ya, sadly, it all boils down to the price.
The few bytes that get send back from the miner are irrelevant (also I've limited the max. tickets in my software to 3 per minute, but if you compile from source you could remove that limit).
Just think what 1000 of these miners will do for damage, or 10000?
I'm thinking of also creating a simple proxy (also on an ESP) so the pool would only have to supply work to one connection instead of having to waste resources on multiple miners on the same IP address.
The distinction is that the ESP32 doesn't run Linux. Because of that it can be significantly lower performance, and cheaper. All the while still being a very decent miner for ~6 ASICs
IMO BM1397 is still in the sweet spot of price, performance and efficiency (for people who aren't Bitmain). For example the BM1397 has a higher hashrate per chip and is cheaper in small-ish quantities than the BM1398 (S19) and BM1362 (S19J Pro)
I guess the esp's are more than fast enough to handle several asics. I will do some profiling so see what the actual number is.IMO BM1397 is still in the sweet spot of price, performance and efficiency (for people who aren't Bitmain). For example the BM1397 has a higher hashrate per chip and is cheaper in small-ish quantities than the BM1398 (S19) and BM1362 (S19J Pro)
I think sadly the BM1397 is the last asic suitable for these kind of miners. If you do the math you will find that newer asics need 20A or even 40A to run, and those kind of currents are not easily managed on 2-layer pcb's (or even 4-layers, just look at the current shunts plastered all over antminer hash boards).
In my opinion, the real advantage would be to produce ready-to-sell PCBs and offer DIY kits if you want to sell cheaply, but that would limit the customer base even more.
My goal would be to bring the pcb to market and let the end user fiddle with the cooling. Cooling will not be hard as the asic is the sole component on the side of the pcb it is mounted on, so different size heatsinks will work. But a plug and play version would be possible too.Welcome back on the forum OP!
..
I'd even like to be a reseller in Europe for you if you're interested, if after I've been able to test them everything's OK, I'd be sincerely interested.
I'm currently in the process of learning how to make Bitaxe myself, a DIY sha256 ASIC based on BM1397 created by Skot (who replied to you above) that reminds me a lot of what you're describing. Feel free to check out this Github if you're interested: https://github.com/skot/bitaxe
Don't hesitate to contact me privately if you'd like to chat, and I wish you all the best!
Its too early for resellers, first comes the manufacturing, and I've sniffed enough leaded solder and flux in my life to even attempt doing it myself ..
I'd even like to be a reseller in Europe for you if you're interested, if after I've been able to test them everything's OK, I'd be sincerely interested.
I'm currently in the process of learning how to make Bitaxe myself, a DIY sha256 ASIC based on BM1397 created by Skot (who replied to you above) that reminds me a lot of what you're describing. Feel free to check out this Github if you're interested: https://github.com/skot/bitaxe
Don't hesitate to contact me privately if you'd like to chat, and I wish you all the best!
Bitaxe is cool, I wish Skott all the best. He started his project roughly at the same time as I did, but I only discovered it 6 month ago (I was too busy developing things to search github, although I did search github before I started working on it). His hardware should be easy to implement in my miner software, all that is needed is modifying the routines to use his dac.