On Tue, Jul 31, 2012 at 1:08 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 30 Jul 2012, Alexey Filin wrote: > >> > 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) > > How did you measure the transaction time? Using a bus analyzer? Unfortunately I don't have one. Temporary licence for WaveRunner 6Zi is over. If you can recommend specialised USB bus analyzer for usage with Linux I would be thank you. I call getnstimeofday in such a way: memset buffer to zero clear t0, t1, t2, t3 getnstimeofday( &t0 ) fill+submit getnstimeofday( &t1 ) while buffer is empty, test it getnstimeofday( &t2 ) completion handler: getnstimeofday( &t3 ) So (brackets because we should take into account seconds and nanoseconds): submission time = [t1] - [t0] transaction time = [t2] - [t1] completion time = [t3] - [t1] Of course estimate of transaction and completion time is less than real, I hope error is small. usb device sends 4 non-zero bytes. > >> 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 Not 1 percent, some percents. May be long transfers are executed during "bus service intervals" (listen for new devices, time reserved for interrupt transfers, don't know). I noted: transfer time is usually less 1 us just after reset of USB device, don't know why. >> >> histograms in png are attached to the email. >> >> so 4 us latency is achievable > > For one transaction. If each external read/write operation requires > two USB transactions then the latency will be higher. But maybe you > could change the implementation: Map an external bus read to a USB IN > transfer and an external bus write to a USB OUT transfer. Address to read/write by is required always to be sent to device. In any case I will discuss the results with our hw designers. The way is enough risky but latencies are not guaranteed for any bus. Regards, Alexey. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
