Now ... 0.3ms is too small IMO - doubling to have one job pending - 0.6ms is also too small IMO (the BFL queue design says 20 work items)
So if your queue only allows one work item waiting in it then the code still has to hit a target, that it is going to (sometimes/often?) be late for, due to USB and OS constraints
Thanks for an informative post.
I'm wondering why even use Linux to control chips via SPI? What is the point? I haven't worked on ARM recently, but I did on Xilinx and Microblaze. Going standalone for SPI and I2C access was a
major win in terms of power usage, I didn't even bother to measure speed: it was much faster, but not critical in what I did. Only lwIP is somewhat harder to use than the network interface through sockets.
Did Linux SPI driver had any recent major improvements?
I wonder what bitfury has to say about it, or will he just shut up and smile to avoid disclosing some other, much better, solution to the competition.
As I said - I'm a software guy, so I look at it from a software POV
No doubt if you did implement it in hardware/firmware it wouldn't be an issue - but then you'd still need some software interface or I'd expect you'd be spending a long time working on it to write a full miner in firmware+hardware
Just having the miner as thin client to a Stratum pool may be an interesting possibility.
Using something other than USB? I'm not sure I've not dealt with it from that angle.
If it was connected via USB ...
The software issue is simply that you cannot guarantee to always have a constant small time frame that small over a USB bus with USB1.1 or USB2.0 using Bulk/Interrupt transfers - maybe possible with Isochronous or with USB3.0 but I'm not sure since I've not dealt with anything USB3.0 yet or any USB2.0 device with an Isochronous end point.
The right size queue removes that issue almost completely anyway.
I've got a lot of timing logging in cgminer with the USB code that clearly shows with some of the current FPGA hardware (BFL and MMQ) single Bulk transactions are always (USB1.1) or often (USB2.0) above those time frames.
Throw away the design/USB chips they used in the past and yes suddenly this may all be a non-issue.
Until I actually get my hands on any of the ASIC hardware, I can of course only speculate.