Quote from: rapsacw on November 03, 2024, 09:41:08 PM

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

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.