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.
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
Oh you can save $5 - wow what a fucking stupid design.