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
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.

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.

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.

Regards,

Hans

------------------------------------------------------------------------------
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

Reply via email to