Content-Type: multipart/alternative; boundary="_000_BF2DC2C01D5C1D4EBD5C642E240034B0027599ALPURAPA22e2kadge_" --_000_BF2DC2C01D5C1D4EBD5C642E240034B0027599ALPURAPA22e2kadge_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 h= igh 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 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 1= 0000 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 vt1= 00 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 communicate= s with the 4 external USB devices (attached). As you can see above the app= lication utilization is pegged. Oddly immediately re-submitting the trans= fer (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 buf= fer to write incoming data into. The host can have up to 8 USB devices con= nected. We wanted to ensure we had enough CPU to handle all 8 simultaneous= ly so we programed the USB devices to send 506 bytes at 120Hz (these will b= e segmented into seven 64 byte packets and one 58 byte packet). For the fi= rst two devices connected the libusb task only used an additional 2% CPU ea= ch. However the utilization jumped when the 3^rd device was connected to 3= 0% but then settled back down. When the 4^th device was connected the util= ization pegged at near 100% and stayed there. To ensure the utilization wa= s strictly due to the libusb library the data is being dumped and the trans= fer buffer immediately resubmitted but that didn't help. Decreasing the tr= ansfer rate to 60Hz allowed the 4 devices to work but what is causing libus= b 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 complica= ted. 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 repr= oduce things on an intel machine. Since that is more powerfull hardware, yo= u will likely see less cpu usage but you should also see a more linear grow= th of the usage as you add devices. If you have multiple usb busses it will likely help greatly if you try to p= lug the devices into ports which belong to different busses. Regards, Hans --_000_BF2DC2C01D5C1D4EBD5C642E240034B0027599ALPURAPA22e2kadge_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hans
 
We are using the controller 2 on the IMX535 Freescale chip which shoul= d be full featured.  Also the I believe the kernel thread would have i= ndicated 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&= nbsp; 0.0% irq  0.0% sirq
= Load average: 3.33 3.91 2.63 4/52 1819
=   PID  PPID USER     STAT   VSZ %ME= M CPU %CPU COMMAND
= 1810  1350 root     R    10404 = ; 2.0   0 94.0 ./testUsb
= 1089     2 root     SW  &= nbsp;    0  0.0   0  1.3 [w1_bus_master1= ]
= 1261     1 root     S  &n= bsp;  2464  0.4   0  0.9 klogd
= 1345     1 root     R  &n= bsp;  2464  0.4   0  0.4 klogd
= 1343     1 root     S  &n= bsp;  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  &n= bsp;  2464  0.4   0  0.2 syslogd -S -m 0 -b 10 -l = 5
=  264     2 root     SW &n= bsp;     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  &n= bsp;  4472  0.8   0  0.0 /usr/sbin/sshd
= 1350     1 root     S  &n= bsp;  2828  0.5   0  0.0 -sh
= 1749  1747 root     S     2828=   0.5   0  0.0 -sh
= 1347     1 root     S  &n= bsp;  2468  0.4   0  0.0 /sbin/getty -L tty0 11520= 0 vt100
= 1231     1 root     S < &nb= sp; 1956  0.3   0  0.0 /sbin/udevd --daemon
=    1     0 root     = S     1892  0.3   0  0.0 init [5]&n= bsp;     
=    5     2 root     = SW       0  0.0   0  0.0 = [events/0]
= 215     2 root     SW  &= nbsp;    0  0.0   0  0.0 [khubd]<= /font>
= 186     2 root     SW  &= nbsp;    0  0.0   0  0.0 [sync_supers]
= 188     2 root     SW  &= nbsp;    0  0.0   0  0.0 [bdi-default]
= 242     2 root     SW  &= nbsp;    0  0.0   0  0.0 [kmmcd]<= /font>
= 345     2 root     SW  &= nbsp;    0  0.0   0  0.0 [nfsiod]=
=    6     2 root     SW&nb= sp;      0  0.0   0  0.0 [khel= per]
=    3     2 root     SW&nb= sp;      0  0.0   0  0.0 [ksof= tirqd/0]
=    2     0 root     SW&nb= sp;      0  0.0   0  0.0 [kthr= eadd]
=    4     2 root     SW&nb= sp;      0  0.0   0  0.0 [watc= hdog/0]
=    9     2 root     SW&nb= sp;      0  0.0   0  0.0 [asyn= c/mgr]
=   10     2 root     SW &n= bsp;     0  0.0   0  0.0 [pm]
=   84     2 root     SW &n= bsp;     0  0.0   0  0.0 [usb_wakeu= p thre]
=   85     2 root     SW &n= bsp;     0  0.0   0  0.0 [usb_wakeu= p thre]
=   86     2 root     SW &n= bsp;     0  0.0   0  0.0 [usb_wakeu= p thre]
= 190     2 root     SW  &= nbsp;    0  0.0   0  0.0 [kblockd/0]
= 200     2 root     SW  &= nbsp;    0  0.0   0  0.0 [mxc_spi.0]
= 203     2 root     SW  &= nbsp;    0  0.0   0  0.0 [mxc_spi.1]
= 209     2 root     SW  &= nbsp;    0  0.0   0  0.0 [otg_switch/0]<= /span>
= 218     2 root     SW  &= nbsp;    0  0.0   0  0.0 [kseriod]
= 284     2 root     SW  &= nbsp;    0  0.0   0  0.0 [khungtaskd]
= 285     2 root     SW  &= nbsp;    0  0.0   0  0.0 [kswapd0]
= 333     2 root     SW  &= nbsp;    0  0.0   0  0.0 [aio/0]<= /font>
= 353     2 root     SW  &= nbsp;    0  0.0   0  0.0 [crypto/0]
= 968     2 root     SW  &= nbsp;    0  0.0   0  0.0 [kapmd]<= /font>
= 1059     2 root     SW  &= nbsp;    0  0.0   0  0.0 [irq/292-atmel_= m]
= 1100     2 root     SW  &= nbsp;    0  0.0   0  0.0 [kondemand/0]
= 1101     2 root     SW  &= nbsp;    0  0.0   0  0.0 [kconservative/= 0]
= 1104     2 root     SW  &= nbsp;    0  0.0   0  0.0 [vpu_wq/0]
= 1113     2 root     SW  &= nbsp;    0  0.0   0  0.0 [esdhc_wq/0]
= 1116     2 root     SW  &= nbsp;    0  0.0   0  0.0 [esdhc_wq/0]
= 1118     2 root     SW  &= nbsp;    0  0.0   0  0.0 [esdhc_wq/0]
= 1127     2 root     SW  &= nbsp;    0  0.0   0  0.0 [usbhid_resumer= ]
= 1134     2 root     SW  &= nbsp;    0  0.0   0  0.0 [mmcqd]<= /font>
= 1178     2 root     SW  &= nbsp;    0  0.0   0  0.0 [mmcqd]<= /font>
= 1785     2 root     SW  &= nbsp;    0  0.0   0  0.0 [flush-0:13]
 
To isolate the failure I developed an application that strictly commun= icates with the 4 external USB devices (attached).  As you can see abo= ve 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 d= edicated high priority task that calls libusb handle events.  When a d= evice is connected eight 64 byte buffers are submitted to ensure the librar= y always has a buffer to write incoming data into.  The host can have up to 8 USB devices connected.  We wante= d to ensure we had enough CPU to handle all 8 simultaneously so we programe= d 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 wa= s 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 immedia= tely 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 s= ubmit more packets scheduling (managing the usb bandwidth) becomes more com= plicated.
 
Also if your Linux platform is a non intel embedded system, your hcd m= ay 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 hardwar= e, 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
 
--_000_BF2DC2C01D5C1D4EBD5C642E240034B0027599ALPURAPA22e2kadge_--