Quote from: BkkCoins on May 31, 2013, 12:53:27 PM

Quote from: kano on May 31, 2013, 12:42:23 PM

An output queue also reduces the work required by the miner dramatically.

The BFL SC code we wrote has an independent thread that simply checks for results and times those checks to attempt to minimise the polling - this makes the process of getting results optimal in the extreme.

If we know the queue is 2 (or 4 or 8 ) in size then we know we only have to poll at most twice per expected result (or even less if the time per result is less than 100ms) to ensure work is getting returned and the queue isn't filling up
If, on the other hand, there is no queue, then we need to poll as required to avoid losing results and to keep synchronisation - and 'as required' can be good or bad depending on how the output works.

I currently have a result queue of 2 items. But when a result occurs I send it off via USB and the queue is mostly in case another result occurs before the first one has been accepted/cleared.

Is there no way with libusb to put a hook on received data so that when something arrives it can callback one of the driver functions? That would seem ideal to me as then you never have to poll - just write a handler for result data as it arrives.

I've coded a variant of the bflsc identify function for klondike. I haven't got back to do more yet. I added an I cmd in firmware to output an identity record with serial# and product code. I'm sure I can get more of the driver functions filled in over the next few days.

The BFL protocol works as a polling protocol (so yeah not the best, but because they have a 20 output queue it's not really a problem)

Of course we could write a very different driver that has a separate thread that simply waits for ALL results on a single end point and processes them based on the results type - and other thread(s) send out requests as needs and wait on replies from the results thread.
Probably even better that any of the current

I'm just not sure if that would work on the same endpoint pair sending the requests.
If there were multiple end point pairs (like the FTDI 0x8350) then that may be it?
I'm not sure until I try it.

At the moment there is no real MCU protocol that would suit that on any other device yet (but I haven't looked closely at the Avalon code so I'm not sure in detail how that handles replies, I just helped with the USB code and the new cgminer usb library) but if that works with a chip with only a single end point pair (or if not, use something like the FTDI 0x8350 with 4 endpoint pairs) then that may be even better.

But again I don't know coz I don't have any devices that use this, the Cairnsmore1 does use the FTDI 0x8350 on the recent boards, but I don't have one to test.