Ucom/Uftdi Thru-put

[Bernd Walter]

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 at bwct.de                                  info at bwct.de