Date: Fri, 18 Feb 2011 16:08:15 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: jhb@freebsd.org, freebsd-usb@freebsd.org Subject: Re: libusb performance on 8.1 Message-ID: <201102181608.15368.hselasky@c2i.net> In-Reply-To: <FF467587-6B4C-4F46-9B8B-C5041E4B224E@gsoft.com.au> References: <9CF6C32F-E230-446B-94FC-C57F0F02B0E4@gsoft.com.au> <0F80A010-B97C-4D05-B604-5EF4B07EF248@gsoft.com.au> <FF467587-6B4C-4F46-9B8B-C5041E4B224E@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102181608.15368.hselasky>