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

[Bigler, Stefan]

Hi

We are trying to use U-Boot that it can be remote controlled over
netconsole and in locally over the serial terminal. 
We were quite successful but we saw some latency issues on the serial
terminal. The polling of the serial driver is too slow to get all
characters. This does not allow you to e.g. to copy/paste, most of the
characters are lost.

We analyzed the code and tried to speed it up, without the required
improvement.
The tests are done with an MPC852 at 66MHz and an MPC8247.
  
In the file common/console.c we added hooks to measure the time for
tstc() execution. 
The measured time are:
serial-driver     3 Microseconds
nc		     15 Milliseconds

The result is, that the serial interface is polled only every 15
Millisecond.
On the serial interface with a line-rate of 115200 we receive aprox
10'000 Character every second. This is one character every 100
Microsecond.

The serial driver has one buffer-descriptor with the space for one
character. This results in a maximal polling period of 100 Microseconds.

The HW-FIFO for a MPC852T is 2 bytes.


There are 2 possibilities to solve the problem:
-----------------------------------------------
a) make the netconsole faster
b) make serial more "robust" and allow more latency

The better solution is of course to make the netconsole faster. But can
we reach 100 Microseconds?
We can reduce it (as already done e.g. accelerate the readout of
env-variables). To accelerate by factor 150 we need to do major changes
e.g. read-out the env if changed so we need a mechanism to see this.

On the other hand we can enhance the serial driver to "absorb" e.g. one
line that allows you to copy/paste.
This is not a big code change but it needs more dp-ram.

The copy/paste test shows the following result
copy          paste           
0123456789 -> 0 -> first character 


a) So I tried to make the netconsole faster with the optimisation of
tstc()
------------------------------------------------------------------------
---
There is the possibility to do the getenv() only if the env is changed.
I added a "transactionId" what is incremented after every write to env.
So the user of env can check if the env changed and only read if
changed.
This reduced the tstc() of nc to 60 Microseconds. So the polling of
serial is done every 70 Microseconds. 
In principle this should be fast enough to be able to copy paste 
copy          paste           
0123456789 -> 013679 -> 50%

Why are we receiving only half of the character? This due to the fact
that processing a character needs time. If we check how often we call
getc() while copy/paste, this is every 180 Microsecond. The method
getc() do not need lot of time, but the received character is sent over
nc before we get the next char. I think we cannot avoid this.

I do not see how we can reduce this time even further.

The measurement is also done without nc. There the getc() is called
every 80-90 Microseconds. So we see that is little headroom to do
additional processing!


b) Make the serial driver more "robust" to absorb bursts
--------------------------------------------------------
I think it would make sense to be able to absorb the burst of one line
e.g. 128 character.

This can be done in 2 way:
b1) use more buffer descriptor with one character
b2) use the feature of smc to allow multi-character buffer 

b1) driver with multi buffer descriptor
---------------------------------------
This is the possibility that is quite simple to implement, but needs
more resources. I have already sent this. The required dual-port-memory
is high
128 bd * 8 byte plus 128 byte for character = 1152 byte more.
(I also implemented this driver)

b2) driver with multi-character buffer
--------------------------------------
I have implemented this driver for MPC852T (SMC) and attached a patch.
The additional use of DP-RAM is the size the buffer (e.g. 128 bytes) and
4 bytes for an index to the next character to read. 
A define can be used to specify the size of the buffer. If undefined the
size is 1.


Conclusion:
-----------
I do not see a good chance to be able to reduce the processing time in
the netconsole below 100 Microseconds.

I expect copy/paste to work for a line (128 characters).

So I propose to enhance the serial driver.

Best regards,
Stefan Bigler