From owner-freebsd-usb@FreeBSD.ORG Tue Feb 3 18:40:16 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A7311065676 for ; Tue, 3 Feb 2009 18:40:16 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 38E988FC17 for ; Tue, 3 Feb 2009 18:40:16 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 62B7FFF9B; Wed, 4 Feb 2009 07:40:15 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ2wOwkTnkbD; Wed, 4 Feb 2009 07:40:11 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 4 Feb 2009 07:40:11 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 583801142E; Wed, 4 Feb 2009 07:40:11 +1300 (NZDT) Date: Tue, 3 Feb 2009 10:40:11 -0800 From: Andrew Thompson To: Hans Petter Selasky Message-ID: <20090203184011.GA64941@citylink.fud.org.nz> References: <200902012001.06914.hselasky@c2i.net> <200902012031.56899.hselasky@c2i.net> <20090201.130051.-2130550806.imp@bsdimp.com> <200902012140.04180.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902012140.04180.hselasky@c2i.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-usb@freebsd.org Subject: Re: USB2 patches X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 18:40:17 -0000 On Sun, Feb 01, 2009 at 09:40:01PM +0100, Hans Petter Selasky wrote: > Hi Warner, > The example is not the best. Let's pick another example: > > Assume you have a 3g modem and we are doing software flow control. Regularly > modem status bits are transferred between host and device. Now, lets assume > that the modem application has only got one thread. What will happen if > transferring the RTS/CTS status bits to the modem is synchronous? Immediate > data-loss! Especially at higher data rates. > > Let me elaborate: Assume it takes 3ms to handle a control request to program > the DTR/RTS/CTS, because the device is slow. Then you have a 1024 byte buffer > on a BULK endpoint which needs to be handled every 1ms. If DTR/RTS and CTS > are not done async, you severely degrade the overall performance of the > system, don't you agree about that, if every time you update the modem status > have to wait 3ms, having to skip Rx'ed data? As Warner suggested, you would only drain if the previous DTR/RTS/etc command is still in flight so there is actually no delay. Say DTR is queued to turn on, its correct to drain this before allowing a subsequent command to turn it off. To queue this and have a thread execute a series of on/off/on/off in one go later isnt right IMHO. Andrew