libusb performance on 8.1
Hans Petter Selasky
hselasky at c2i.net
Fri Feb 18 15:08:29 UTC 2011
On Friday 18 February 2011 15:40:07 Daniel O'Connor wrote:
> On 03/02/2011, at 17:26, Daniel O'Connor wrote:
> > BTW do you have a feel for the latency in bulk vs iso? I currently have
> > 5-10 msec of buffering in the hardware which I plan on increasing but
> > I'm not sure what a reasonable amount would be :)
> I increased this by a factor of 8 but I still get drop outs during disk
> I timed libusb_handle_events_timeout() with a timeout of 1 millisecond and
> it quite often exceeds this (by a significant amount) eg..
> Triggered at 1298039742
> 2011/02/18 14:35:27:ugsio_child: libusb took > 10msec - 32.44 ms
> 2011/02/18 14:35:27:ugsio_child: libusb took > 10msec - 27.19 ms
> 2011/02/18 14:35:27:ugsio_child: libusb took > 10msec - 25.27 ms
> 2011/02/18 14:35:27:ugsio_child: libusb took > 10msec - 21.83 ms
> 2011/02/18 14:35:36:ugsio_child: libusb took > 10msec - 48.23 ms
> Error during acquisition - ERROR:305 UGSIO aborted transfer: stalled
> (still using bulk transfers for now)
Which harddisk driver are you using? ATA?
My guess would be that taskqueues() in the HDD drivers are using swi-queues,
instead of ordinary lower-priority queues. For example in sys/dev/ata I found:
TASK_INIT(&request->task, 0, ata_completed, request);
ATA_DEBUG_RQ(request, "finish taskqueue_swi");
Which should perhaps just be "taskqueue_thread" instead of "taskqueue_swi".
I've noticed during USB debugging that if certain non-DATA-xfer SCSI commands
take time to complete, the whole system is waiting apparently, at least X11.
This might indicate that synchronous code is being run from interrupt context.
More information about the freebsd-usb