On Thu, Jul 26, 2012 at 7:59 PM, Hans Petter Selasky <hselasky@xxxxxxx> wrote: > On Thursday 26 July 2012 17:47:11 Alan Stern wrote: >> To get maximum throughput you should submit multiple URBs originally, >> and then submit a new URB whenever an URB completes. I recommand using >> a pipeline depth of 10-20 ms. For bulk transfers at high speed, that >> comes out to between 500 KB and 1 MB of concurrent URB data. > > Some EHCI hardware will scan for new QH's and TD's when you set the EHCI > doorbell bit. This bit is only supposed to be used when you remove QH's/TD's > from the ASYNC schedule, but can also be abused when entering QH's/TD's into > the schedule. So USB is not a "classic" bus and not universal, it is a network with non-constant delay. Are there USB controllers with the "synchronous transfers" reported not on microframe boundary, so we can get response less 125 us? Is there any USB2.0 spec extension declaring "synchronous transfers"? USB is a good choice for some bus adapters, it is used widely, cheap, simple. For 2-byte read/write we could use either two bulk IN/OUT endpoints (131 * 8kHz ~ 1 MHz) or one control endpoint (table 5-3, 42 * 8 kHz = 336 kHz). Ethernet is overkill for the task even if it could provide 1 us delay. Is it possible for USB Implementers Forum to add extension for "synchronous transfers" to be handled asynchronously with microframe boundaries? Existing bus adapters use frequently closed proprietary protocols for pc-adapter link, e.g. CAEN CONET for PCI(e)-VME (I talk about remote adapters to access with a link, not bridges)... > > How this works for your EHCI controller, depends on the actual hardware > implementation. > > --HPS -- 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
