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
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
