Hi, I am writing a program which reads from a data acquisition chassis connected to a radar via USB. The interface is a Cypress FX2 and I am communicating via libusb.
The program starts a thread which sits in a loop doing nothing but libusb_handle_events_timeout() which in turn runs a callback if a transfer is complete. Each transfer is in a struct which has a mutex and a 'done' flag (the former protects the later) which is set when the callback is run by libusb. The main thread sits in a loop waiting for the next transfer to be done and when it is copying data out to be further processed and then written out to disk and/or another process for some further mangling. After each USB transfer is done with (ie the main thread has passed it all out for further processing) the main thread re-submits it to libusb. I only have about 10 milliseconds of buffering (96kbyte FIFO, 8Mbyte/sec) in the hardware, however I have about 128Mb of USB requests queued up to libusb. hps@ informed me that libusb will only queue 16kbyte (2msec) in the kernel at one time although I have increased this. I hooked up a logic analyser and I can see most of the time it's fairly regularly transferring 16k of data every 2msec. If I load up the disk by, eg, tar -cf /dev/null /local0 I find it drops out and I can see gaps in the transfers until eventually the FIFO fills up and it stops. I am wondering if this is a scheduler problem (or I am expecting too much :) in that it is not running my libusb thread reliably under load. The other possibility is that it is a USB issue, although I am looking at using isochronous transfers instead of bulk. I just noticed that the USB controller and ATA controller share an IRQ, but I wouldn't expect that to cause a problem.. This is running on FreeBSD 8.1-STABLE, Core 2 Duo with ICH9 chipset. Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
