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

Re: Serial Latency Issues, Baud Rate Affects Buffering



On Friday 09 January 2004 12:31, Johan.Adolfsson@xxxxxxx.com wrote:
> The way CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS work
> 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 characters 
are transmitted in ~15ms.  If we flush the buffer every 10ms, then we should 
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.

So it appears that CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS suffers from a similar 
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 received 
or not?

> 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,

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?

> 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 similar 
line where info->flush_time_usec is being set.  Perhaps I need a newer 
version (version information provided below).

> 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?

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 developer's 
website.  The date on the patch is 2002-10-24.  Is a newer (better?) version 
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.

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