libusb performance on 8.1

[Hans Petter Selasky]

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
> activity.
> 
> 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)

Hi,

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");
            taskqueue_enqueue(taskqueue_swi, &request->task);

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.


--HPS