Date: Thu, 8 Jul 2004 10:46:51 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Julian Elischer <julian@elischer.org> Cc: current@FreeBSD.org Subject: Re: speeding up ugen by an order of magnitude. Message-ID: <20040708084650.GW12877@cicely12.cicely.de> In-Reply-To: <Pine.BSF.4.21.0407080108010.66234-100000@InterJet.elischer.org> References: <20040707.232916.126914893.imp@bsdimp.com> <Pine.BSF.4.21.0407080108010.66234-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 08, 2004 at 01:16:24AM -0700, Julian Elischer wrote: > > > On Wed, 7 Jul 2004, M. Warner Losh wrote: > > > In message: <Pine.BSF.4.21.0407071137440.80217-100000@InterJet.elischer.org> > > Julian Elischer <julian@elischer.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040708084650.GW12877>