Date: Wed, 7 Jul 2004 11:13:12 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@freebsd.org> Subject: Re: speeding up ugen by an order of magnitude. Message-ID: <20040707091311.GE12877@cicely12.cicely.de> In-Reply-To: <Pine.BSF.4.21.0407061624030.64529-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0407061624030.64529-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 06, 2004 at 04:32:28PM -0700, Julian Elischer wrote: > > So, we had a device that we access through ugen. > > the manufacturer said we should get the transaction in 3 seconds > and wiindows and linux did, but FreeBSD got it in 15 seconds. > I suspect since the code is the same, NetBSD would get the same result.. > > lokking at it I noticed that ugen does everything in 1K bits, > which is ok for USB1, but a bit silly for USB2. Mmm - 128k is very big - consider that you may have hundrets of ugen bulk pipes open - all with outstanding reads. This would eat up kernel memory quite fast. The problem is lost bus time between finishing an xfer and issuing the next one - consider that part of this lost time is OS dependend latency and in fact might be limited to FreeBSD. What about those options: - limit the allocated memory to the user request so we don't take the whole 128k if not reuired. - Do interleaving with 2 or more xfers if the read request is known to take more xfers. Naturally the situation with bulk writes is the same. -- 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?20040707091311.GE12877>