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

[Wolfgang Denk]

Dear "Bigler, Stefan",

In message <D839955AA28B9A42A61B9181506E27C4012E192F at SRVCHBER1212.ch.keymile.net> you wrote:
> 
> > This should give you raw serial driver  performacne  while  a  serial
> > data  transfer  is running, while keeping functionality for all other
> > use cases.
> > 
> > What do you think?
>
> First we need to have a good and accepted solution to reduce the time in
> NetLoop e.g. read only the env when changed. Then the polling is not
> anymore critical path. 

Hm... sorry, but I disagree. With my suggestion above, the time spent
in NetLoop() does not matter any more at  all.  So  no  optimizations
there will be needed to get your code working.

Optimizing NetLoop() is a complex thing with global impact that will
require a lot of testing. There is little chance to see this in
mainline soon - at least not in the upcoming 2008.12 release.

My suggestion however results in small code,  and  additionally  this
code  affects only users of the new console multiplexing feature, but
nobody else.

Such a modification could go into mainline much faster.


But I agree that it is a worthwile goal to optimize NetLoop() anyway.


> The main problem from my point of view is the echo of the received data
> to serial and also to nc. This is done now immediately, character by
> character and this takes time (more than we have). 

Sorry. I don't get it. It seems you bring up a new topic here.

Less than 6 hours before this you wrote: "The polling of  the  serial
driver  is  too  slow  to  get  all characters. ... we added hooks to
measure the time for tstc() execution. The measured time are: ...  nc
15 Milliseconds".

My interpretation was (and is) that it's the *input* processing which
is your major concern. And I showed a way to solve this problem ( at
least I think that my suggestion will solve it).


Now you bring up a  new  topic  -  the  time  needed  to  output  the
characters. May be we should try and solve problems sequentially - if
we  throw  all  isses we see into one big pot we might not be able to
swallow this.

BTW: did you measure any times for the character output?

> Am I right when I say that between a read from character getc() until
> the next call of getc() we have 100 Microseconds to do all the required
> processing otherwise we lose data?

On average, yes. The time for a single character might be longer  (up
to  close  to  200  us) assumimg we are fast enough then to catch the
third char. All this assuming a console baudrate of 115 kbps.

BTW - reducing the console baud rate would be a trivial way to  avoid
most of these issues ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I had the rare misfortune of being one of the first people to try and
implement a PL/1 compiler.                             -- T. Cheatham