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

Re: problem with serial driver



On Fri, 20 Jul 2001, Mariusz Matuszek wrote:
> So I defined FLUSH_DMA_FAST only to discover that it wouldn't compile
> any more (with an explanatory note in serial.c around line 3090:
> TODO). :-|

Those things were in our 2.0 port and we're in the process of fixing them
in the Linux 2.4 release.

The fundamental problem is that usually one both wants high throughput
(i.e. DMA, buffers, FIFO's etc) and low latency. Low latency in serial
protocols usually means having to look at every byte, which is obviously
not compatible with the high throughput desire.

There is no good solution to this; if you have a timer that flushes the
buffers quickly you get bad throughput but better latency (that is
FLUSH_DMA_FAST). Serial-ports are inherently a bad and old protocol :) 

What are your figures - what latency do you expect and what baud-rate do
you run at ?

Depending on the baudrate and latency requirements you can or cannot find
a suitable value for the flushing. If you can do with 10 ms, just change
MAX_FLUSH_TIME from 8 to 0 (or 1, I don't remember which will work). That
is the variable that is similar to the RX_TIMEOUT_TICKS variable in the
future release.

> My question is, has anyone got this driver to work properly without
> buffering?

The extreme case is pure interrupt-driven I/O, without and DMA or FIFO'ing
at all. You get extremely bad throughput but lowest possible latency; this
is not coded yet but we're going to add the option to the ports soon,
because sometimes you need the DMA-channels to other I/O-ports. As long as
you're just running at, say, 19200 or 38400 this should not be a high
load, but if you're going for 920000 you'll probably feel it...

/Bjorn