tty layer and lbolt sleeps

[Mike Durian]

On Tuesday 16 September 2003 04:47 pm, Mike Durian wrote:
> I'm trying to implement a serial protocol that is timing sensitive.
> I'm noticing things like drains and reads and blocking until the
> next kernel tick.  I believe this is due to the lbolt sleeps
> in the tty.c code.

Following up on my own post in case anyone was interested.

My assumption about the lbolt sleep was incorrect.  The delay
I'm seeing is not in the tty layer, it is in the sio driver.

If I change the tick count for the siobusycheck timeout
from (hz / 100) to just 1 and bump up HZ to 5000, I can get
some reasonable responsiveness with write and drain.

To get good responsiveness in the read direction, I need to force
the RX FIFO trigger level down to FIFO_RX_LOW.

After doing both those things, I can acheive the control I need.
However, I don't really like cranking up HZ just to get decent
sio(4) latencies.  I'm assuming the use of siobusycheck in a polled
manner is just an artifact from old crufty serial devices.  I
suppose uart(4) will clear this up when it is stable.

Adding an ioctl to set UART RX trigger levels would be something
I would find useful.  Perhaps others too.

I disagree with the following comment in the sio.c source:

 * Use a fifo trigger level low enough so that the input
 * latency from the fifo is less than about 16 msec and
 * the total latency is less than about 30 msec.  These
 * latencies are reasonable for humans.  Serial comms
 * protocols shouldn't expect anything better since modem
 * latencies are larger.

It makes the tacit assumption that all serial protocols go
through a modem and thus latency isn't important.  I suspect
I'm not the only person out there using a serial port that
isn't connected to a modem or a terminal.

mike