[Gllug] High-latency RS-232

[James Courtier-Dutton]

On 19 March 2010 07:45, TM <tm at tm.uklinux.net> wrote:
>
> We talk to this piece of kit via RS-232 over TCL. We use xon/xoff. We
> have traditionally used Windows and the comms works a treat. Now they
> have moved to Linux and the serial port has turned sluggish. It takes
> about 1000 characters to stop/pause. Which is way to much.
>
> I suggested fiddling with the niceness of the process. This helped but
> wasn't good enough to solve the problem.
>
> They run a 'stock' kernel from Fedora and/or RedHat. Moving to a
> different distribution (thinking real-time kernel here) is complicated
> because there is a lot of code developed for the current
> kernel/distribution.
>
> I think they could just happen to have a serial port with a generic,
> poorly optimised driver. I have suggested googling for a serial card
> well supported in Linux.
>
> We have also played with the RTS-CTS handshake. This introduces a bunch
> of other issues (solvable, no doubt, but requiring time and effort). So,
> we would like to sick to Xon/Xoff.
>
> Can anyone suggest ways of tackling the problem please?
>
I don't suppose you have a sample TCL program you can share.
There are two ways to do XON/XOFF in Linux.
One is at the application layer, the other is in the tty layer.
The tty layer will react faster.
You do not say which direction the problem is in. I.e. the Linux
sending, or the other box sending chars.
Another problem you might have is Linux by default uses the nagle algorithm.
What this means is that the serial buffers will buffer up input chars
until either the buffer is full, or there is a gap is transmission.
So, what you might be seeing is characters that have already been
received by the Linux box, but were just buffered. The XOFF causes a
gap in transmission, and thus you see the buffer empty and pushed to
the application.

Now, XON/XOFF is quite rare now, so there might be a bug in the Linux driver.
If it is using the tty layer correctly, I think that you should never
see the XON/XOFF chars in the stream at the application layer. The tty
layer should take care of them.

If the problem is in the send direction. I.e. Linux is sending chars,
and waiting to receive an XOFF.
This will be slow to react. It always has been in Linux. There is no
need to make it any quicker when Linux is talking to Linux.
Linux is actually much faster at reacting in the other direction. I.e.
It can send an XOFF very quickly when needed. It is just rather
sluggish detecting the incoming XOFF. A way to speed this detection up
is to try to ensure that your application reads the serial port as
quickly as possible. Thus the input buffers are kept fairly empty and
thus the XOFF is processed more quickly. One then needs to also only
fill the tx buffers just in time, because the way Linux handles XOFF
is that when it receives the XOFF, it continues to send everything in
the ring buffer and then stops sending more. The ring buffer is about
4K in size, so only sending 1000 chars is actually quick a good
result!!!
It is technically possible to detect the XOFF earlier, but Linux
choose not to do it that way. Detecting XOFF early makes everything
more complex and uses more CPU resources.

Extract from a Linux programming guide:
"Hardware handshake is optional, but very useful. It allows either of
the two stations to signal whether it is ready to receive more data,
or if the other station should pause until the receiver is done
processing the incoming data. The lines used for this are called
"Clear to Send" (CTS) and "Ready to Send" (RTS), respectively, which
explains the colloquial name for hardware handshake: "RTS/CTS." The
other type of handshake you might be familiar with is called
"XON/XOFF" handshaking. XON/XOFF uses two nominated characters,
conventionally Ctrl-S and Ctrl-Q, to signal to the remote end that it
should stop and start transmitting data, respectively. While this
method is simple to implement and okay for use by dumb terminals, it
causes great confusion when you are dealing with binary data, as you
may want to transmit those characters as part of your data stream, and
not have them interpreted as flow control characters. It is also
somewhat slower to take effect than hardware handshake. Hardware
handshake is clean, fast, and recommended in preference to XON/XOFF
when you have a choice."

So, you have two options.
1) Implement fast handling rx of XOFF in the kernel yourself.
2) Modify your program to ensure the tx and rx buffers are kept as
empty as possible.
3) Use hardware flow control.

Generally, XON/XOFF is really only meant to be used for interactive
terminals where their are often gaps in tx and rx of data, so the
XON/XOFF is processed in good time.
All other datacomms should really use hardware flow control.
I do not know exactly what your application is, but I would be
surprised if PCs nowdays can not handle full speed serial comms
without ever having to send an XOFF or even resort to flow control.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug