On Wed, Jan 04, 2006 at 03:55:08PM -0500, Edwin Olson wrote: > > >Ick, that's some small chunks :( > > > > I saw another thread which seems to describe another possibility (and > suggesting that visor has fixed it): > > http://www.mail-archive.com/[email protected]/msg38382.html > > The suggestion being that maybe I'm writing faster than my USB device > can handle, and that there's a backlog of URBs. It's entirely likely > that my device can't suck in more than about 15-20KB/s anyway. (Are > there any cpu usage implications in having a large number of outstanding > URBs, i.e., like an O(n) "look for the URB we just finished"?)
Outstanding ones? No, that should be fine. > To test this, I added a periodic command to my device which causes a > response; I then block until I receive this response. (so: <stream a > bit><request><wait for response><stream a bit><request><wait for > response>...) The CPU usage is much lower, around 20% (still rather > absurdly high for ~15KB/s) and the computer doesn't seem to lock up. > Throughput was about the same as I'd gotten with much higher CPU usage. > This is evidence that I'm DoS'ing the computer, as suggested by the > other thread and the visor code. > > It looks like visor_write() method is just returning 0 if too many URBs > are outstanding. Does this get translated into a userland write() > blocking, or would userland write() return 0? I might be rework ftdi_sio > to do the visor's URB limiting, too. Yes, userland write will return 0 too. The problem is that you are just probably overrunning the device. You are sending too many 32 byte packets to the driver, faster than the device can receive them. As your test shows, if you wait a bit, everything seems to work much better. > >The problem is you only sending 32 bytes at a time. (SNIP) > > > >I would suggest testing this out wih a small test applicate that sends > >larger ammounts of data through the device. > > > > > I will test this, just to be sure. Isn't the maximum packet size on USB > 64B anyway? If so, doesn't that mean that I can (at best) reduce the > number of URBs by half? Yes, the max packet size is determined by the endpoint size. But if you want to send more than that size, your data is sent over multiple USB transations to the device, which can be done very fast with very low CPU by the hardware on the host. If you try to make a packet the same size as a usb endpoint, you will generate an interrupt for every one of those packets, and have to submit a new one at that time, all taking up more time that the bus is idle. Hope this helps, greg k-h ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
