On Mon, Jul 30, 2012 at 1:51 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 30 Jul 2012, Alexey Filin wrote: > >> On Thu, Jul 26, 2012 at 7:47 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > You can do this only by hacking up a special driver of your own. >> > Since transfer completions would not be reported by IRQs in time, you >> > would have to poll for transfer completions at microsecond intervals. >> > This would present a rather large overhead for the computer, but it >> > might work. >> > >> >> for example in such a way: >> >> there are 2 bulk endpoints in USB device, OUT and IN: >> >> OUT buffer format: | <ADDR> | <WRITE DATA> | <cycle type> | >> IN buffer format: | <READ DATA> | <completion bit> | >> >> Read cycle (read data by ADDR): >> >> 1. USB host sets OUT buffer to: | <ADDR> | <ignored> | 0 | >> 2. USB host clears <completion bit> in IN buffer: | <ignored> | 0 | >> 3. USB host submits URBs for OUT and IN endpoints >> 5. USB device gets <cycle type>, reads data by ADDR, puts data into IN >> endpoint and sets <completion bit> >> 6. while not <completion bit> set and not timeout triggered >> USB host reads IN buffer >> 7. USB host finishes cycle and returns data from IN buffer: | <READ DATA> | 1 | >> >> >> Write cycle (write data by ADDR): >> >> 1. USB host sets OUT buffer to: | <ADDR> | <WRITE DATA> | 1 | >> 2. USB host clears <completion bit> in IN buffer: | <ignored> | 0 | >> 3. USB host submits URBs for OUT and IN endpoints >> 5. USB device gets <cycle type>, gets data from OUT endpoint and sets >> <completion bit> >> 6. while not <completion bit> set and not timeout triggered >> USB host reads IN buffer >> 7. USB host finishes cycle, IN buffer: | <ignored> | 1 | >> >> URB completions are ignored, cycles are atomic (with a mutex), we get >> latency ~1 us > > Your <completion bit> mutex isn't needed, because the USB host hardware > provides one of its own. > >> can the same URB be submitted some times before completion? >> if not, can different URBs be submitted with the same buffer before completion? >> >> should it work? > > Yes, something like it might work, I think. But you probably wouldn't > want to use URBs for this; they have too much overhead. You'd need a > more direct interface to the host controller driver. really, too much, about 7 us on my pc (Core2 Duo CPU E7500 2.93GHz) a direct access to EHCI controller should be used > > The EHCI spec doesn't put any strict time limit on how long the host > controller can wait before writing back the completion information to a > transfer descriptor. If the hardware waits more than 1 us, your scheme > is doomed. it works on Intel Corporation N10/ICH 7 Family USB2 EHCI Controller I measured times for 4-byte IN transfer: fill+submit time 7 us (average) +- 1.5 us transaction time 3.7 us (average) +- 0.5 us (without tails) completion time 20-150 us (flat), as expected for microframe boundary not synched with transfer getnstimeofday overhead 60 ns (used to measure times) transaction time increases up to 20 us for 1% of 10000 transfers histograms in png are attached to the email. so 4 us latency is achievable Regards, Alexey. > > Alan Stern >
Attachment:
getnstimeofday_lin.png
Description: PNG image
Attachment:
getnstimeofday_log.png
Description: PNG image
Attachment:
times_lin.png
Description: PNG image
Attachment:
times_log.png
Description: PNG image
