[U-Boot] RFC - How to speed up multiplexed input between serial and network?

[Gary Jennejohn]

On Wed, 29 Oct 2008 13:14:52 +0100
Wolfgang Denk <wd at denx.de> wrote:

[big snip details of analysis]
> My suggestion is to make the multiplexing more intelligent instead of
> making the serial driver more complex. The nice thing  with  this  is
> that  you  probably  still get the same results (actually even better
> ones as the artificial 128 byte line lengt limit can be avoided), and
> the changes are only in the new code, i. e. users  who  do  not  need
> such I/O multiplexing will not be affected.
> 
> I think it should be fairly simple to implement something similar  to
> the VTIME feature for non-canonical reads in the Unix serial drivers
> (see "man tcsetattr"):
> 
> - In idle mode, all configured input devices are polled in a
>   round-robin manner (as it is done now).
> 
> - As soon as a character is received on the serial line, a  timestamp
>   is  taken. As you calculated, one character at 115 kbps takes about
>   100 us on the wire. Within a window of (for  exmaple)  500  us  (or
>   about 5 character times) now polling of all other I/O ports will be
>   skipped.
> 

I took a quick look at this idea, but I didn't try to implement all the
fancy timestamp stuff, etc.

Basically, I kept the pointer to the last device which had input and
checked it first in tstc().

My testing was done on a sequoia at a baudrate of 115200.  The sequoia is
a fast board.  Testing was done with combinations of stdin and stdout
devices (serial and nc).

I observed no performance improvements.

I then looked more closely at the results of a rather simple case -
stdin=serial and stdout=serial,nc.  In this case the change mentioned
above would have no effect since ther is only one stdin device.

Doing a paste of an 80 character line resulted in 90% loss of input.
With stdin=stdout=serial cut&paste worked with no character loss.
The obvious conclusion is that the _output_ to nc was so slow that it
caused the character loss.

Thus, efforts to try to optimize the input at high baudrates in the
multiplexing code itself it will not help due to the slow output.

The suggestion to lower the baudrate seems like the most intelligent
solution.

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************