Re: [Libusb-devel] is libusb fast enough for my device

[Alan S. <st...@ro...>]

On Sun, 17 Aug 2008, jeffp wrote:

> Hi,
> 
> I have posted about this before but am still stuck and unable to make
> progress. I do not want to go to my client and say I cannot provide a Linux
> USB interface for his device that works at full speed.
> 
> I am running libusb 0.1 under SuseLinux 10.2 and have an application that
> uses libusb to talk to my clients analog to digital converter to collect the
> converted samples over the usb interface.
> 
> You can specify the speed which samples can be taken from 1/sec up to 500K /
> sec.
> 
> I open the interface and claim the device and then in a loop just call bulk
> read passing in a very large buffer (larger than the number of samples i
> expect to get), and requesting a very large number of bytes to be read. For
> example if I want to collect 500K samples, I use a 2Mb buffer and specificy
> 500000 as the number of bytes to read.

I hope that's not literally the case.  2 Mb = 2 megabits = 256 
kilobytes, so you would be overrunning the buffer by a large amount.

Perhaps you meant that the buffer size was 2 MB = 2 megabytes.  Why use 
such a large buffer if you're never going to fill more than a quarter 
of it?

How large is each sample?  One byte?

> What I am seeing is that beyond a certain speed (seems to be around 100K
> samples/sec)
> the bulk_read cannot empty the FIFO in the USB part (EASY-USB,FX2LP) fast
> enough. Data arrives at the FIFO from the device faster than it can be read
> out by bulk read. I think what may be happening is that when the FIFO
> overflows the data is dropped on the floor, and the bulk_read only reads
> what has not overflowed, which is not equal to the requested amount so it
> times out waiting for the data which has probably overflowed. I see evidence
> of this when using a sniffer because I see the data being returned and then
> before all the data is returned the IN packets result in NAKs from the
> device meaning it has nothing more to send. So I think the missing data is
> what dropped on the floor at the FIFO. 

It would help if you could describe the protocol used by the device 
when sending its data.  Does it simply accumulate enough samples to 
fill up a maximum-sized packet and then transmit the packet?

You may find that the limits of libusb-0.1 can be overcome by moving to 
libusb-1.0 or by using Linux's native usbfs interface.

> The faster I set the sample rate, the worse the problem becomes.
> 
> I thought that libusb and the host controller could handle the high speed
> usb at full rate and my application is well below that. Max of 500K
> Megabytes / sec which is about 4Megabits per second.

Try again.  You probably mean 500 KB/s, not 500 K MB/s.  Note that the
maximum theoretical transfer rate for bulk data at full speed is about
1187 KB/s -- and that's under ideal conditions which may not apply to
you.  So while you're not pushing the limits, you aren't too far off 
either.

> Again my application is
> doing nothing other than the bulk read in a loop; no other processing is
> performed.
> 
> I am not sure, but I think the bulk-endpoint in the part is 512bytes.

Is that supposed to be the size of the FIFO or the maximum packet size?  
Note that the maximum packet size for a bulk endpoint running at full
speed is not allowed to be more than 64 bytes.

> As a final note, the vendor has a Windows usb driver that can accept the
> samples at the full rate.
> 
> Tim gave me some useful insight on this last week but I am still not able to
> get it to work.
> Does anyone have any ideas of what may be happening and more importantly
> what I may try to fix it ?

There is a definite inefficiency in waiting for one transfer to
complete before submitting the next transfer.  Ideally you should
submit a reasonably large number of fairly small read requests, and
whenever a request completes you should submit another one, thereby
maintaining a queue of in-progress requests that never runs dry until
you're ready to stop.  Unfortunately this means using asynchronous I/O,
which isn't possible with libusb-0.1.  That's why I recommended using a
different API.

However the exact details will depend on the protocol used by the
device.

Alan Stern