From owner-freebsd-current@FreeBSD.ORG Thu Jul 8 09:32:41 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 D652D16A4CE for ; Thu, 8 Jul 2004 09:32:41 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12DC543D2F for ; Thu, 8 Jul 2004 09:32:41 +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) i689WUaI022508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 8 Jul 2004 11:32: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 i689VkUi014525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2004 11:31:47 +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 i689Vksq027545; Thu, 8 Jul 2004 11:31:46 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i689VkYi027544; Thu, 8 Jul 2004 11:31:46 +0200 (CEST) (envelope-from ticso) Date: Thu, 8 Jul 2004 11:31:46 +0200 From: Bernd Walter To: Julian Elischer Message-ID: <20040708093145.GX12877@cicely12.cicely.de> References: <20040707.232916.126914893.imp@bsdimp.com> <20040708084650.GW12877@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040708084650.GW12877@cicely12.cicely.de> 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.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cicely12.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 09:32:42 -0000 On Thu, Jul 08, 2004 at 10:46:51AM +0200, Bernd Walter wrote: > On Thu, Jul 08, 2004 at 01:16:24AM -0700, Julian Elischer wrote: > > On Wed, 7 Jul 2004, M. Warner Losh wrote: > 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? OK - It looks like you are absolutely right. It seems that the controller sweeps trough the request queues on a per frame basis - we can only get per frame what we have set. What we havn't set at that time won't make it onto the bus until the next frame. Not surprising after rethinking, because the priority calculation is done on a per frame base. If we just have a single 1k xfer then 1k is all we can ever get per ms. If we have two 8k xfers or a single 16k xfer then that's what we can get per ms at maximum. I havn't calculated the maximum size per frame yet, but if it's 60k then we really have to push xfers for 60k into the pipe in parallel and we are required to have setup the next xfers in time for the next frame. Say you are doing 128k and you get 60k per frame. Then you get 60k in the first ms, 60k in the second and only 8k in the third - then you setup the next one and get 60k again. If the bus is loaded with other requests then the splitting is different. Interleaving two 64k requests would get us 4k of the first request and 56k of the second request during the second ms. Well - that theoretical so far... Can we do interleaving with physio? -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de