From owner-freebsd-current@FreeBSD.ORG Thu Jul 8 08:47:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EFEF16A4CE for ; Thu, 8 Jul 2004 08:47:49 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE75C43D4C for ; Thu, 8 Jul 2004 08:47:48 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i688lVaI021292 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 8 Jul 2004 10:47:33 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i688ktUi014242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2004 10:46:55 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i688ksgw027386; Thu, 8 Jul 2004 10:46:54 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i688kpG6027385; Thu, 8 Jul 2004 10:46:51 +0200 (CEST) (envelope-from ticso) Date: Thu, 8 Jul 2004 10:46:51 +0200 From: Bernd Walter To: Julian Elischer Message-ID: <20040708084650.GW12877@cicely12.cicely.de> References: <20040707.232916.126914893.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: phk@phk.freebsd.dk cc: mycroft@netbsd.org cc: ticso@cicely.de cc: "M. Warner Losh" cc: current@FreeBSD.org Subject: Re: speeding up ugen by an order of magnitude. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2004 08:47:49 -0000 On Thu, Jul 08, 2004 at 01:16:24AM -0700, Julian Elischer wrote: > > > On Wed, 7 Jul 2004, M. Warner Losh wrote: > > > In message: > > Julian Elischer writes: > > : > Nevertheless I see ugen more as a quick and dirty way to test drive a > > : > device from userland with all it's great debugging capabilities before > > : > writing a specific kernel driver. > > : > The requirement that ugen has to be generic is often bad for > > : > performance sensitive applications. > > : > > : Ugen is used in production all over the place where people have to used > > : devices there is no specific support for, and where there is no > > : kernel expertise. > > > > usb drivers are very easy to write. I think that making it easier to > > write those drivers is going to be better for the project in the long > > run. > > > > ugen is supposed to be general. If we can make it faster w/o > > sacrificying this generalness, that's OK. But if we can't, then you > > gotta do stuff in the kernel. That's always been the case (and why we > > don't have userland tcp, for example). Some things have to be in the > > kernel to be fast. > > I don't think this has to sacrifice generalness.. > > Matt Dillon just made a simple patch for this on Dfly and I'm looking at > back-porting it. there is nothing in ugen that shouldn't let it take > data from a bulk USB2 device at a good speed except that it doesn't ask There are technical limits - such as that we can't support select and prereads without breaking generalness for bulk endpoints. > for the data that fast.. it is possible that there is a problem in the > ehci driver too, but I haven't got my mind around that driver quite > fully enough yet to say for sure.. it looks like it doesn't allow more > than one transfer per msec frame from the ugen device. solving this Possibly a side effect because we have to disconnect the pipe queue to modify it, but I still think its the time we need to take the completed xfer and setting up the next one. > would allow the use of smaller buffers. I don;t think it's a problem > woth overhead and small transfers, but rather that ugen is asking for > only 1 x 1KB transaction per mSec when USB2 is capable of delivering > 60KB/mSec. I think increasing the buffer size means still asking for one > transaction per mSec, but it's a bigger transaction :-) What interrupt rate do you see from the host controller? -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de