[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serial Latency Issues, Baud Rate Affects Buffering

----- Original Message -----
From: "Eric Sorton" <esorton@xxxxxxx.org>
To: <dev-etrax@xxxxxxx.com>
Sent: den 9 januari 2004 16:51
Subject: Serial Latency Issues, Baud Rate Affects Buffering

> Hi All,
> We have an ETRAX100LX development board.  For testing, serial port 2 on
> ETRAX is connected to a PC via a null modem cable.  In the production
> a wireless modem (limited to 4800 baud) will sit between the PC and the
> ETRAX. At this time, we are operating the serial ports without hardware or
> software flow control.
> The PC runs a simple program which sends 7 bytes of data to the ETRAX via
> Serial port at a rate of 50Hz (7 * 50 = 350 which is within the bandwidth
> capabilties of a 4800 baud modem).  Instrumentation in the PC program
> that it sends the data at the proper rate and meets its timing deadlines.
> The ETRAX runs a simple application which loops at a rate of 50Hz.  Each
> iteration, the serial port is read.  Ideally, we would like to read 7
> of data each loop iteration.

To rely on such a a behaviour is probably a bad idea since workload
might affect when data is transferred from the serial driver to the tty

> Initally, CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS was set to 5 and
> was poor.  On most iterations (at 115200 and 4800 and others) we would
read 0
> bytes, when the buffer was finally flushed, we would read multiple 7 byte
> packets.  A bit research indicated that changing
> CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS to 0 or 1 would help the problem.
> With CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS set to 0, if we set the baud
> between the PC and the ETRAX to 115200, the ETRAX behaves well, and reads
> bytes each iteration.  If we set the baud rate between the PC and the
> to 4800, the ETRAX behaves poorly and reads 0 bytes on some loop
> while reading greater than 7 bytes on other loop iterations.  Why does the
> baud rate affect the behavior of the buffering?  Is there anything we can
> to fix this issue?

When using DMA for the serial ports in ETRAX you must flush the DMA:s
by software to actually receive the data if it's less then the amount
specified by the DMA descriptors.
There are three config options for this:

is to check the port at a certain timer tick intervals to see if we
should force the DMA to flush. That interval is not related to the
baudrate so that's one of the reasons it affect the buffering behaviour.

The CONFIG_ETRAX_SERIAL_FLUSH_DMA_FAST does basically the same but at a
much higher rate which affects the overall performace negatively.

CONFIG_ETRAX_SERIAL_FAST_TIMER on the other hand should force the DMA to
flush when no new data has arrived in 4 character times.
However - with 7 bytes at 50 Hz the idle time between chunks will be less
then 4 character ((7+4)*50 = 550 which is above the throughput provided
with 4800 baud)

You could try using the port in manual (interrupt driven) mode instead,
or try changing the line:
  info->flush_time_usec = 4*info->char_time_usec;
in os/linux/arch/cris/drivers/serial.c:update_char_time()
to something like:
  if (info->char_time_usec > 1000)
    info->flush_time_usec = info->char_time_usec+info->char_time_usec/2;
    info->flush_time_usec = 4*info->char_time_usec;

(or change the 4)

> We also tried setting the CONFIG_ETRAX_SERIAL_FAST_TIMER and the
> CONFIG_ETRAX_SERIAL_FLUSH_DMA_FAST options.  This made the situation worse
> and NO data was transmitted between the PC and the ETRAX.
> With CONFIG_ETRAX_SERIAL_FAST_TIMER enabled, we were able to successfully
> transmit and receive 7 byte packets at 50Hz at 115200 baud.  When we tried
> operate at 4800 baud, no data was received (a logic probe confirms the PC
> transmitting data).

What version of os/linux/arch/cris/drivers/serial.c are you using?
See above for why things dont get flushed at 7 chars at 50Hz at 4800 baud.
Does the data arrive after 256 bytes?

> With CONFIG_ETRAX_SERIAL_FLUSH_DMA_FAST, no data was recevied.
> Port 0 on the ETRAX is connected at 115200 to a different device.  We have
> seen no issues communicating with this device with any combination of
> options.  However, we do always run this port at 115200.
> We are looking for suggestions on what to try next as we are out of ideas.
> Any help would be greatly appreciated,
> Eric
> --
> Eric Sorton
> Senior Member Research Staff
> Institute for Scientific Research (ISR), Inc.
> 119 Roush Circle
> Industrial Park Road
> Fairmont, WV  26554
> Email: esorton@xxxxxxx.org
> URL: http://www.isrparc.org
> Voice: 304-368-9300 x219
> FAX: 304-534-4106

Best regards