Date: Fri, 28 Jan 2011 08:58:05 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: freebsd-usb@freebsd.org Subject: Re: libusb performance on 8.1 Message-ID: <201101280858.05077.hselasky@c2i.net> In-Reply-To: <6AD22899-0B00-483D-A01E-786029A82C9F@gsoft.com.au> References: <9CF6C32F-E230-446B-94FC-C57F0F02B0E4@gsoft.com.au> <201101221433.23194.hselasky@c2i.net> <6AD22899-0B00-483D-A01E-786029A82C9F@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 28 January 2011 02:44:43 Daniel O'Connor wrote: > On 23/01/2011, at 24:03, Hans Petter Selasky wrote: > > You need to change the way you buffer the data. FreeBSD does not queue > > more than 2 URB's at any time, and the turnaround time varies from 1ms > > to 125us due to hardware IRQ restrictions. Linux queues up all it can > > get, which leads to other kind of problems. The current internal buffer > > limit is 16Kbyte 8000 times per second which gives a MAX of 128 > > MByte/second. > > How difficult would it be to increase this? Hi, For this kind of applications ISOCHRONOUS transfers should be used. Then you can have a double buffer guard in the range 1-56ms, regardless of the buffer size the hardware uses. You could also try an XHCI controller, because the BULK buffering is done differently there. > I obviously don't need any more > throughput, however my application is very sensitive to latency, as I am > reading out of a fairly small FIFO and if it fills up my entire run has to > be aborted. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101280858.05077.hselasky>