On Mon, 24 Dec 2012, Hans de Goede wrote: > Hi, > > On 12/21/2012 03:06 AM, Xiaofan Chen wrote: > > This may be of some interests to the list here, especially with > > regard to the Mac OS X HID backend. > > > > http://lists.apple.com/archives/usb/2011/Feb/msg00021.html > > "The IOUSBHIDDriver only has one interrupt read pending at a time. > > That means that at the best case, you will get a IN token on the bus > > every other millisecond, if your polling rate is 1ms." > > This is not true, unless Apple's hcd drivers suck, what will happen > (best case) is: > 1) HC starts a new USB frame (SOF) > 2) HC processes interrupt ep td > 3) interrupt td has request interrupt flag set, EHCI: raise interrupt > immediately > UHCI: raise interrupt when done processing for this frame > 4) Assume bus otherwise idle (best case) Both EHCI and UHCI raise interrupt > as soon as the interrupt packet is received, this is 100-200 usecs > later
Your 3) and 4) contradict each other. In any case, 4) is wrong and 3) is close to correct. EHCI raises interrupts at microframe boundaries (or less frequently if told to do so). > 5) OS HCD + device driver now have approx 800 usecs to: process interrupt, > pass > complete packet to device driver, have device driver process + resubmit > the URB, if they do this within say 700 usecs, then the td will be linked > into > the interrupt queue again before the HC processes the next frame. No, at least, not under UHCI. (Although I don't believe Apple uses UHCI components in their machines.) The window for submitting a new interrupt transfer in time for the next frame is very small, perhaps even 0. EHCI has more flexibility, but depending on how the driver is written, it may not be enough. > So although I agree using only one interrupt transfer is less then ideal, > under > non full bus load circumstances (for UHCI), a polling rate of 1 ms/sec should > be > quite feasible with a single transfer. Where as for EHCI it is almost > guaranteed, > now involving a a userspace based driver through libusb will make reaching > the 700 usecs more challenging I must admit ... > > Note that tests which I've done with bulk in transfers (for usb <-> serial > adapters) > show that it is feasible to reach 1 transfer / msec with an UHCI controller, > with > only a single bulk transfer, and this was in a virtualized environment, so > includes > emulation overhead. The the big limit here is that the UHCI controller only > checks > its schedule once every msec. For full-speed bulk and control, UHCI checks much more often that that. See the discussion of full-speed bandwidth reclamation in the spec. > The EHCI controller can do a lot better with its separate async and periodic > schedules > where it will scan the async schedule more often, I've seen transfer rates of > approx > 10 transfers / ms (single byte bulk reads) with the queue stopping (due to > short > reads) and needing to be restarted by the HCD after every transfer. > > Legenda: > HC = host controller > HCD = host controller driver > > Besides this most HID devices don't really need a 1 ms poll rate, ie the world > fastest typists type 200 words per minute *peak*, which is a 1000 chars / > minute, > so about 16 keys / second, which is blazingly fast, but still nowhere 500 > events > / second. On the other hand, it doesn't require much agility to move a mouse faster than 16 pixels/second. But I agree that HID devices do not need to e polled 1000 times per second, as a general rule. In fact, many HID devices run at low speed rather than full speed, and USB demands that low-speed devices may not have polling intervals less than 10 ms. Alan Stern ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
