[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: <johana@xxxxxxx.com>
Sent: den 9 januari 2004 20:22
Subject: Re: Serial Latency Issues, Baud Rate Affects Buffering

> On Friday 09 January 2004 12:31, Johan.Adolfsson@xxxxxxx.com wrote:
> > 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 Configure.help states:
> Number of timer ticks between flush of receive fifo (1 tick = 10ms).
> At 4800 baud, each character is transmitted in 2.1ms.  Therefore, 7
> are transmitted in ~15ms.  If we flush the buffer every 10ms, then we
> receive data in our read() looping every 20ms.  This does not occur, we do
> not receive data until the buffer is flushed when it is full at 256 bytes.
> However a comment in the code states:
> ... forces an end-of-packet for the dma input channel if no chars
> have been received for CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS/100 s.

Note the "to see if we should force DMA to flush" in the help text,
which make it consistent with the code - "we should" is only true
if no data has been received since the last check.

> So it appears that CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS suffers from a
> problem to CONFIG_ETRAX_SERIAL_FAST_TIMER that you describe below.
> What changes would I have to make to force the DMA buffer to flush every
> CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS regardless of if data has been
> or not?

You could modify force_eop_if_needed() I guess, but I wouldn't recommend it.

> > 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
> > 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,
> Based upon previous discussions in this newsgroup, I believe this would
> involve writting a device driver as the current serial.c does not support
> interrupt driven operation.  Is this correct?

Not any more, it's implemented in the 2.4.22 kernel along with other
You can download it from http://developer.axis.com/download/linux/
The latest version of serial.c is 1.58, but 1.57 should be fine as well
(unless you use CMSPAR)
(Not sure what version is in the tarball)

> > 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;
> >   else
> >     info->flush_time_usec = 4*info->char_time_usec;
> >
> > (or change the 4)
> My version of serial.c does not have the above code.  It has a line
> line where info->flush_time_usec is being set.  Perhaps I need a newer
> version (version information provided below).

Yes, please try a newer version, see above.

> > 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
> > Does the data arrive after 256 bytes?
> Version is "$Id: serial.c,v 1.40 2002/10/14 05:33:18 starvik Exp $".
> We are running 2.4.19 with a 2.4.19 patch acquired from the Axis
> website.  The date on the patch is 2002-10-24.  Is a newer (better?)
> available?
> With fast timers at 4800, we never received any data; not even in 256 byte
> blocks.  I can rerun the tests to confirm this.

If I remember correctly, I might have fixed such a problem.
Please try 2.4.22.

> Eric