Re: mac performance, unsuspending
Nathan Hjelm <hjelmn <at> me.com>
2012-08-26 03:53:16 GMT
Reply inline.
On Aug 25, 2012, at 7:24 AM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:
> On Tue, Aug 7, 2012 at 3:56 AM, Amir Hirsch <amir <at> zigfu.com> wrote:
>> I did a bit of digging to figure out why OpenNI device enumeration was slow
>> on Mac while Kinect hacking. I measured the timing of different calls in
>> libusb. some logs and a description are in my post to the OpenNI dev list:
>>
>> https://groups.google.com/forum/?fromgroups#!topic/openni-dev/Wqrtj09BkhY
>>
>>
>> OpenNI does device enumeration in a way that makes multiple requests to get
>> the device list, once per sensor type and twice if it finds a sensor. this
>> needs to be fixed in OpenNI, but the main slowness in libusb is that
>> darwin_cache_device_descriptor calls USB Device Suspend and this call is
>> expensive and takes about 100ms per call and it was being re-tried several
>> times between sleeping for 30ms.
>>
>> #######USBDeviceSuspend 312454000
>> #######USBDeviceSuspend end 415979000
>>
>> I was able to greatly speed up my kinect hacking experience by modifying the
>> function darwin_cache_device_descriptor, setting retries = 0 and
>> try_unsuspend = 0 and commenting out the call to usleep.
>>
>> some talk on this list last year indicated that this might be associated
>> with why I would sometimes lose my keyboard and trackpad when hacking with
>> Kinect on Mac too:
>> http://libusb.6.n5.nabble.com/OSX-critical-bug-td4576409.html
>>
>> I am going to distribute a fork in our kinect osx installer which ignores
>> enumeration errors, and modify our openni distribution to use it. Is there a
>> better solution in general?
>
> Yes I agree that it is good to fix this issue. In my Mac Mini (Mac OS X
> Lion 10.7.4), the Apple bluetooth controller will get suspended and then
> there will be debug log like this (for libusbx, the fork of libusb at
> libusbx.org,
> but it is similar for libusb-1.0)
I will not put any fixes into libusbx. I don't like the direction that project is taking (HID support == bad
idea) or the fragmentation having a second projects creates.
> [ 0.197248] [00000e07] libusbx: debug [process_new_device] found
> device with address 5 port = 3 parent = 0x102e0a998 at 0x7fdd08e01130
> [ 0.198148] [00000e07] libusbx: debug [process_new_device] allocating
> new device for location 0xfa113000
> [ 0.198454] [00000e07] libusbx: debug [darwin_cache_device_descriptor]
> kernel responded with code: 0xe000404f. sleeping for 30 ms before
> trying again
> [ 0.229673] [00000e07] libusbx: debug [darwin_cache_device_descriptor]
> kernel responded with code: 0xe00002ed. sleeping for 30 ms before
> trying again
> [ 0.261248] [00000e07] libusbx: debug [darwin_cache_device_descriptor]
> kernel responded with code: 0xe000404f. sleeping for 30 ms before
> trying again
> [ 0.292716] [00000e07] libusbx: debug [darwin_cache_device_descriptor]
> kernel responded with code: 0xe00002ed. sleeping for 30 ms before
> trying again
> [ 0.324141] [00000e07] libusbx: debug [darwin_cache_device_descriptor]
> kernel responded with code: 0xe000404f. sleeping for 30 ms before
> trying again
> [ 0.355759] [00000e07] libusbx: debug [darwin_cache_device_descriptor]
> kernel responded with code: 0xe00002ed. sleeping for 30 ms before
> trying again
> [ 0.386888] [00000e07] libusbx: warning
> [darwin_cache_device_descriptor] could not retrieve device descriptor
> 05ac:8281: device not responding. skipping device
> [ 0.387024] [00000e07] libusbx: debug [libusb_unref_device] destroy device 0.0
>
I added the retry code to enumerate buggy devices. This code is similar to code within the generic usb device
driver (see IOUSBFamily). I can't say I loose sleep over something on the order of 100 ms (or even 500ms)
when it comes to usb enumeration. In the future that code will not be called very often (when hotplug
support is in-- we should probably get on that sooner rather than later). I will agree that I made it a little
too aggressive. Might back it off to retrying once or twice to speed things up in the meantime.
> But I am not so sure if your two fixes are desirable or not.
I don't think they are. The unsuspend code allows libusb to enumerate more devices and some developers
might be taking advantage of this. Also, as I mentioned before if the unsuspend code was the problem USB
Prober would cause the mouse and keyboard to drop as well.
> Maybe the better fix is what suggested by Nathan in the above libusb-devel
> thread.
>
> "On Lion, I have noticed when probe suspended devices is selected the
> trackpad and keyboard can become unresponsive for several seconds.
> I hadn't seen this behavior before with USB Prober (and never seen it with
> libusb). I might be able to reproduce the problem and find an appropriate
> workaround (like not un-suspending certain classes of devices with
> vendor ID 0x05ac -- Apple)."
Let me see if I can get this into the next version. Its getting about time for a 1.0.10!
-Nathan
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Segher
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. 
RSS Feed