From owner-freebsd-current@FreeBSD.ORG Thu Jul 8 08:16:31 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 5012916A4CE for ; Thu, 8 Jul 2004 08:16:31 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D8843D48 for ; Thu, 8 Jul 2004 08:16:31 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004070808162801600o3dmhe>; Thu, 8 Jul 2004 08:16:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA89759; Thu, 8 Jul 2004 01:16:25 -0700 (PDT) Date: Thu, 8 Jul 2004 01:16:24 -0700 (PDT) From: Julian Elischer To: "M. Warner Losh" In-Reply-To: <20040707.232916.126914893.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: phk@phk.freebsd.dk cc: mycroft@netbsd.org cc: ticso@cicely.de 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 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:16:31 -0000 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 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 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 :-) > > Warner >