From owner-freebsd-usb@FreeBSD.ORG Tue Aug 30 21:10:13 2005 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8504E16A41F for ; Tue, 30 Aug 2005 21:10:13 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E110343D48 for ; Tue, 30 Aug 2005 21:10:12 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j7ULA4BS015189 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 30 Aug 2005 23:10:07 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j7UL9wKi097159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 23:09:59 +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 j7UL9wv8095477; Tue, 30 Aug 2005 23:09:58 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j7UL9waY095476; Tue, 30 Aug 2005 23:09:58 +0200 (CEST) (envelope-from ticso) Date: Tue, 30 Aug 2005 23:09:57 +0200 From: Bernd Walter To: Hans Petter Selasky Message-ID: <20050830210957.GS37930@cicely12.cicely.de> References: <200508202157.j7KLv1GF005017@asus.tddhome> <20050826112422.GY37930@cicely12.cicely.de> <200508301751.j7UHpCt8000858@asus.tddhome> <200508302100.12140.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200508302100.12140.hselasky@c2i.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: ticso@cicely.de, freebsd-usb@freebsd.org Subject: Re: Ucom/Uftdi Thru-put X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 21:10:13 -0000 On Tue, Aug 30, 2005 at 09:00:09PM +0200, Hans Petter Selasky wrote: > On Tuesday 30 August 2005 19:51, User Tomdean wrote: > > Sorry this is long, I have attached the code at the bottom. > > ucom_read.c is the FreeBSD code. UMP2_send.c is the AVR code. > > > > # kldload ucom > > # kldload uftdi > > power up UMP2 and AVR > > In dmesg, I see > > ucom0: FTDI USB HS Serial Converter, rev 1.10/2.00, addr 2 > > > > With a scope, on the USB_DATA+ line, I see groups of 3 uSec activity, > > every 1 mSec. Within the groups, I see 100 nSec pulses, or a 10 mBit > > rate. > > > > # ./ucom_read > > > > With a scope, on the USB_DATA+ line, I see activity every 1 mSec. > > But, the AVR has groups of activity every 2 mSEC! Just before the 52 > > uSec of activity caused by the AVR, I see a 3 uSec group of activity. > > So, the USB bus has its normal 3 uSec activity every 1 mSec overlayed > > by 52 uSec of AVR activity every 2 mSec. So, ucom_read only gets the > > USB bus every 2 msec. You at least see a start of frame every ms - the rest are packets. A new transmission can be inserted in the next frame and while return of the previous transmission you loose too much time to insert the next transmission within the next frame, so we miss one. The buffer below is just big enoug for a whole USB packets, but we could transmit multiple packets per USB-frame if the tty-Buffer already has enough data. There are some drawback when doing large transmissions, so we shouldn't do bigger transmissions than really required - ideally this would be configureable as well as the receive wait timeout that the FTDI devices have. > > > > The AVR send loop takes 0.9 to 1.1 uSec. These happen in bursts of 74 > > uSec every 2 mSec. The AVR waits for the UMP2 TX ready signal most of > > the time. > > > > >From looking at the USB_DATA+ line and the UMP2 *TXE signal, the *TXE > > > > signal is not true until the buffer is empty. The doc states 'If this > > signal is log.1, the buffer is full'. > > > > 10 mSec --+---------+---------+---------+--------- > > USB --1---------123-------1---------123------ > > *TXE ---------------4-------------------4----- > > > > > > 1 - 3 uSec USB activity from FreeBSD > > 2 - 10 uSec gap > > 3 - 52 uSec USB activity from the UMP2 > > 4 - 72 uSec activity on the *TXE line, high otherwise. > > > > The nominal return from the FreeBSD read is 62 bytes. The UMP2 has a > > FT8U245BM chip, which has a 384 byte transmit buffer. The buffer-size is a different story, because it can be emptied by the consumer while still receiving further packets. Even a buffer size of 124 bytes would be enough for a fast consumer. > > The output from ucom_read, > > > > Read 1000060 bytes in 32.242824 seconds in chuncks of 62 bytes > > > > This is a thruput of 31017 bytes/second. > > > > Does FreeBSD only request 64 bytes from the UMP2???? > > cat /sys/dev/usb/uftdi.c | more > > ... > > #define UFTDIIBUFSIZE 64 > ^^^ 64 bytes every 2 ms = 32000bytes/second > > Maybe you can increase this value, but I am not sure if the driver supports > it. I have patches to increase buffer sizes, but there is nothing you can do about the 2ms delay - that's how USB works - you have to sync with the next USB frame, which is every 1ms. Have to read the original mail to see which is the bootleneck, but the seen bandwidth points very much to this. Return to the buffer sizes - it increases the number of bytes one can send within each frame, just increasing the value is not enough as there are special bytes embedded. My patch was just receiving, but the other direction is pretty much the same - will have to reread an old thread, because Jörg Wunsch had corrected some maths and I have to check if the patch on my disk is the corrected one or the original. The patch was originally done to speed up an AVR-USB-programmer :) -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de