Date: Tue, 3 Feb 2009 10:40:11 -0800 From: Andrew Thompson <thompsa@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB2 patches Message-ID: <20090203184011.GA64941@citylink.fud.org.nz> In-Reply-To: <200902012140.04180.hselasky@c2i.net> References: <200902012001.06914.hselasky@c2i.net> <200902012031.56899.hselasky@c2i.net> <20090201.130051.-2130550806.imp@bsdimp.com> <200902012140.04180.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090203184011.GA64941>