From owner-freebsd-usb@FreeBSD.ORG Fri Jan 28 01:45:01 2011 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847A71065672 for ; Fri, 28 Jan 2011 01:45:01 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A26018FC1D for ; Fri, 28 Jan 2011 01:45:00 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p0S1ihe4094926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jan 2011 12:14:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <201101221433.23194.hselasky@c2i.net> Date: Fri, 28 Jan 2011 12:14:43 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <6AD22899-0B00-483D-A01E-786029A82C9F@gsoft.com.au> References: <9CF6C32F-E230-446B-94FC-C57F0F02B0E4@gsoft.com.au> <201101221433.23194.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1082) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-usb@freebsd.org Subject: Re: libusb performance on 8.1 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 01:45:01 -0000 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=20 > than 2 URB's at any time, and the turnaround time varies from 1ms to = 125us due=20 > to hardware IRQ restrictions. Linux queues up all it can get, which = leads to=20 > other kind of problems. The current internal buffer limit is 16Kbyte = 8000=20 > times per second which gives a MAX of 128 MByte/second. How difficult would it be to increase this? 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. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C