From owner-freebsd-current@FreeBSD.ORG Wed Jul 7 18:54:26 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 DD5BD16A4DB for ; Wed, 7 Jul 2004 18:54:26 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B37E43D49 for ; Wed, 7 Jul 2004 18:54:26 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i67Irc7n068892; Wed, 7 Jul 2004 14:53:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i67Irc0D068889; Wed, 7 Jul 2004 14:53:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 7 Jul 2004 14:53:38 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: mycroft@netbsd.org cc: ticso@cicely.de cc: FreeBSD current users 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: Wed, 07 Jul 2004 18:54:27 -0000 On Wed, 7 Jul 2004, Julian Elischer wrote: > Yes that's why I brought it up here. That was only a "proof-of-concept" > that showed that teh slowdown was coming from the fact that the ugen was > only pushing one KB of data per frame (1mSec) interrupt. (it was pinned > at 1MB/sec) The correct answer may be to do what pould-henning > suggested and use teh physio facility to do this. I considerred that > originally but there is overhead in that too, and it is also possible > that the NetBSD and FreeBSD physio facilities have diverged enough to > make this non trivial as far as keeping diffs to a minimum. (It is after > all NetBSD code). You might want to take a look at the ZERO_COPY socket send code, as well as the sendfile() code... FYI, I'm in the process of reformulating some of the zero copy send code on the advice of Alan Cox to make it less strict about alignment, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > It would be possibel to modulate teh malloc per xfer by only malloccing > a buffer large enough for the transfer, but the malloc per transfer > seems a lot of overhead. Alternatively it may be possible to malloc once > for every endpoint on teh client device, but I'm not clear on whether it > is possible to have multiple outstanding requests per endpoint. If so > then how many buffers DO we malloc, and how big? What if there are a lot > of endpoints? > > > > > > 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. > > No, the lost time is I believe due to something in the way that the ehci > driver is setting things up. I believe from empirical evidence that > we are getting one transfer per frame (8 uframes). I don't believe OS > response time is a key factor. > > > > > > What about those options: > > - limit the allocated memory to the user request so we don't take the > > whole 128k if not reuired. > > this requires a separate malloc per xfer. it;s a valid option but > is it acceptable? > > > > - Do interleaving with 2 or more xfers if the read request is known to > > take more xfers. > > You still need to malloc enough data for all outstanding data. > better to do it with ONE request than multiple.. > > > > > > Naturally the situation with bulk writes is the same. > > yes. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >