From: Tim R. <ti...@pr...> - 2008-08-18 18:07:43
|
jeffp wrote: > ... > 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. > > 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. > > 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. Again my application is > doing nothing other than the bulk read in a loop; no other processing is > performed. > Even with a large buffer, you still run into a huge latency issue between buffers. With a large buffer, you will be able to suck up packets continuously until the buffer is filled. Once the buffer fills, the kernel has to send the completed request back up to libusb, who notifies you. You do whatever you need to do, then resubmit the empty buffer back to libusb, who sends it to the kernel driver. During that long interval, you have no requests queued up, so the host controller driver cannot schedule you into any of the frames. At a 500kB/s continuous rate, and assuming you have configured the endpoint for the maximum size (4k), the FX2's buffer is going to fill in 8ms. How long does it take you to turn your buffer around? Really, the only way to handle continuous data streaming is to use have multiple requests outstanding. That way, when one request completes, you have another one waiting in the wings, and scheduling can continue without interruption. However, that requires asynchronous processing, which libusb 0.1 cannot do. Time to look at libusb 1.0, maybe... > I am not sure, but I think the bulk-endpoint in the part is 512bytes. > If it is a high-speed (USB 2) device, then that is the required size for a bulk pipe. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |