Menu
▾
▴
Re: [libusb] libusb task utilization
|
From: Hans de G. <hde...@re...> - 2013-06-27 13:29:15
|
Hi, On 06/27/2013 02:48 PM, Doak, Roger (GE Healthcare) wrote: > Hans > We are using the controller 2 on the IMX535 Freescale chip which should be full featured. Also the I believe the kernel thread would have indicated high utilization if it were the driver: > Mem: 45408K used, 466276K free, 0K shrd, 0K buff, 29740K cached > CPU: 0.7% usr 97.2% sys 0.0% nic 1.9% idle 0.0% io 0.0% irq 0.0% sirq Notice 97.2% sys, so it is the driver taking all the time, not libusb (which is taking some part of the 0.7% usr). But indeed the mx53 does seem to has an ehci controller. So I guess the regular ehci-sched.c code is having trouble scheduling the large (ish) amounts of transfers you're submitting. It would still be interesting to run the same tests on a pc, to see if this causes a significant (or at least measurable load there too. Regards, Hans > Load average: 3.33 3.91 2.63 4/52 1819 > PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND > 1810 1350 root R 10404 2.0 0 94.0 ./testUsb > 1089 2 root SW 0 0.0 0 1.3 [w1_bus_master1] > 1261 1 root S 2464 0.4 0 0.9 klogd > 1345 1 root R 2464 0.4 0 0.4 klogd > 1343 1 root S 2464 0.4 0 0.4 syslogd -S -m 0 -b 2 -l 8 -s 10000 > 1752 1749 root R 2828 0.5 0 0.2 top -d5 > 1258 1 root S 2464 0.4 0 0.2 syslogd -S -m 0 -b 10 -l 5 > 264 2 root SW 0 0.0 0 0.2 [rpciod/0] > 1747 1337 root S 7032 1.3 0 0.0 sshd: root@pts/0 > 1337 1 root S 4472 0.8 0 0.0 /usr/sbin/sshd > 1350 1 root S 2828 0.5 0 0.0 -sh > 1749 1747 root S 2828 0.5 0 0.0 -sh > 1347 1 root S 2468 0.4 0 0.0 /sbin/getty -L tty0 115200 vt100 > 1231 1 root S < 1956 0.3 0 0.0 /sbin/udevd --daemon > 1 0 root S 1892 0.3 0 0.0 init [5] > 5 2 root SW 0 0.0 0 0.0 [events/0] > 215 2 root SW 0 0.0 0 0.0 [khubd] > 186 2 root SW 0 0.0 0 0.0 [sync_supers] > 188 2 root SW 0 0.0 0 0.0 [bdi-default] > 242 2 root SW 0 0.0 0 0.0 [kmmcd] > 345 2 root SW 0 0.0 0 0.0 [nfsiod] > 6 2 root SW 0 0.0 0 0.0 [khelper] > 3 2 root SW 0 0.0 0 0.0 [ksoftirqd/0] > 2 0 root SW 0 0.0 0 0.0 [kthreadd] > 4 2 root SW 0 0.0 0 0.0 [watchdog/0] > 9 2 root SW 0 0.0 0 0.0 [async/mgr] > 10 2 root SW 0 0.0 0 0.0 [pm] > 84 2 root SW 0 0.0 0 0.0 [usb_wakeup thre] > 85 2 root SW 0 0.0 0 0.0 [usb_wakeup thre] > 86 2 root SW 0 0.0 0 0.0 [usb_wakeup thre] > 190 2 root SW 0 0.0 0 0.0 [kblockd/0] > 200 2 root SW 0 0.0 0 0.0 [mxc_spi.0] > 203 2 root SW 0 0.0 0 0.0 [mxc_spi.1] > 209 2 root SW 0 0.0 0 0.0 [otg_switch/0] > 218 2 root SW 0 0.0 0 0.0 [kseriod] > 284 2 root SW 0 0.0 0 0.0 [khungtaskd] > 285 2 root SW 0 0.0 0 0.0 [kswapd0] > 333 2 root SW 0 0.0 0 0.0 [aio/0] > 353 2 root SW 0 0.0 0 0.0 [crypto/0] > 968 2 root SW 0 0.0 0 0.0 [kapmd] > 1059 2 root SW 0 0.0 0 0.0 [irq/292-atmel_m] > 1100 2 root SW 0 0.0 0 0.0 [kondemand/0] > 1101 2 root SW 0 0.0 0 0.0 [kconservative/0] > 1104 2 root SW 0 0.0 0 0.0 [vpu_wq/0] > 1113 2 root SW 0 0.0 0 0.0 [esdhc_wq/0] > 1116 2 root SW 0 0.0 0 0.0 [esdhc_wq/0] > 1118 2 root SW 0 0.0 0 0.0 [esdhc_wq/0] > 1127 2 root SW 0 0.0 0 0.0 [usbhid_resumer] > 1134 2 root SW 0 0.0 0 0.0 [mmcqd] > 1178 2 root SW 0 0.0 0 0.0 [mmcqd] > 1785 2 root SW 0 0.0 0 0.0 [flush-0:13] > To isolate the failure I developed an application that strictly communicates with the 4 external USB devices (attached). As you can see above the application utilization is pegged. Oddly immediately re-submitting the transfer (see dumpTransfer function) seems to make the problem worse not better? > Roger > -----Original Message----- > From: Hans de Goede [mailto:hde...@re...] > Sent: Wednesday, June 26, 2013 10:05 AM > To: Doak, Roger (GE Healthcare) > Cc: lib...@li... > Subject: Re: [libusb] libusb task utilization > Hi, > On 06/26/2013 04:23 PM, Doak, Roger (GE Healthcare) wrote: >> Libusb developers, >> >> We are using Libusb 1.0.9 on a Linux platform. Our host is using >> Asynchronous device I/O and interrupt transfer. We have a dedicated high priority task that calls libusb handle events. When a device is connected eight 64 byte buffers are submitted to ensure the library always has a buffer to write incoming data into. The host can have up to 8 USB devices connected. We wanted to ensure we had enough CPU to handle all 8 simultaneously so we programed the USB devices to send 506 bytes at 120Hz (these will be segmented into seven 64 byte packets and one 58 byte packet). For the first two devices connected the libusb task only used an additional 2% CPU each. However the utilization jumped when the 3^rd device was connected to 30% but then settled back down. When the 4^th device was connected the utilization pegged at near 100% and stayed there. To ensure the utilization was strictly due to the > libusb library the data is being dumped and the transfer buffer immediately resubmitted but that didn’t help. Decreasing the transfer rate to 60Hz allowed the 4 devices to work but what is causing libusb to consume so much CPU? > I think the answer to that probably is the kernel hcd driver, as you submit more packets scheduling (managing the usb bandwidth) becomes more complicated. > Also if your Linux platform is a non intel embedded system, your hcd may be of "varying" quality. In general there are 2 types of hcd-s in embedded > chips: 1) ohci/uhci/ehci, these are fine 2) other "creative" designs, often otg capabe, these suck. > If you are indeed on a non Intel platform, it would be good to try and reproduce things on an intel machine. Since that is more powerfull hardware, you will likely see less cpu usage but you should also see a more linear growth of the usage as you add devices. > If you have multiple usb busses it will likely help greatly if you try to plug the devices into ports which belong to different busses. > Regards, > Hans |
