Re: usb scheduler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux