Hans
 
Sorry for the delay I ran the test you requested on my linux PC (has an I7 processor, changed the name of the test executable to lTestUsb):
 
All 8 USB devices sending 506 bytes at 120Hz running on my linux PC only takes about 6% (Alex indicated the multiple cores is why idle is at 99.7% so an application could possibly take 800%, he did not know why the PPD top would not match between the idle time and task percentage since it’s a single core):
 
top - 12:04:41 up 1 day,  1:11,  1 user,  load average: 0.15, 0.11, 0.06
Tasks: 270 total,   1 running, 268 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.2%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  15981328k total,  3359904k used, 12621424k free,   294984k buffers
Swap: 15625212k total,        0k used, 15625212k free,  1894464k cached
 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                  
17401 root      RT   0 11576  796  660 S    6  0.0   0:11.61 lTestUsb                                                                                                                                 
 
We tried turning on CONFIG_USB_EHCI_TT_NEWSCHED in version 2.6 cross compiled for the IMX535 but that didn’t help (same 100% utilization with only 4 devices):
 
Linux 192.168.252.99 2.6.35.3.rev3 #1 PREEMPT Fri Jun 28 12:30:21 CDT 2013 armv7l GNU/Linux
 
zcat /proc/config.gz  | grep TT
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
 
top - 23:25:38 up 6 min,  2 users,  load average: 2.46, 0.76, 0.28
Tasks:  55 total,   3 running,  52 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0%us, 95.1%sy,  0.0%ni,  3.3%id,  0.3%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:    511392k total,    41956k used,   469436k free,        0k buffers
Swap:        0k total,        0k used,        0k free,    12716k cached
 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                           
1490 root      RT   0 10408  780  652 R 94.7  0.2   0:21.09 testUsb                           
 
We even tried version 3.1 (since we have to crosscompile so its not easy for us to try new versions) but that didn’t help either:
 
Linux 192.168.252.99 3.1.1+ #127 PREEMPT Fri Feb 8 09:33:41 PST 2013 armv7l GNU/Linux
          
zcat /proc/config.gz  | grep TT
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
 
top - 23:35:56 up 4 min,  2 users,  load average: 2.44, 0.60, 0.21
Tasks:  48 total,   5 running,  43 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.0%us, 98.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    441348k total,    22140k used,   419208k free,        0k buffers
Swap:        0k total,        0k used,        0k free,     8916k cached
 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                           
  994 root      RT   0 10412  780  652 R 99.9  0.2   0:22.07 testUsb                           
 
I can remove two of the 4 devices and the CPU utilization returns to normal:
Removing 2 USB devices after CPU is at 100% with 4 causes the CPU load to return to normal with testUsb only utilizing between 1.6% and 5% of the CPU.
 
So I don’t understand why CPU utilization pegs on the IMX535 with only 4 devices?
 
Roger
 
 
-----Original Message-----
From: Hans de Goede [mailto:hdegoede@redhat.com]
Sent: Thursday, June 27, 2013 8:29 AM
To: Doak, Roger (GE Healthcare)
Cc: libusb-devel@lists.sourceforge.net
Subject: Re: [libusb] libusb task utilization
 
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:hdegoede@redhat.com]
> Sent: Wednesday, June 26, 2013 10:05 AM
> To: Doak, Roger (GE Healthcare)
> Cc: libusb-devel@lists.sourceforge.net
> 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