FIFO -t opt on devc-ser8250 & IRQTUNE

the default for -t on devc-ser8250 is 0

does that mean - off

or - auto detect (14 on a 16550A or better)


And I know you will say this is a hack that Linux needs -

BUT, don’t you need EVERY optimization in a RT system???

IRQTUNE - http://www.best.com/~cae/irqtune/

dedicated hardware - arrange your interface’s IRQs to
minimize forwarding/router/NAT/firewall delay
professional audio

Michael J. Ferrador <n2kra@orn.com> wrote:

the default for -t on devc-ser8250 is 0

does that mean - off

or - auto detect (14 on a 16550A or better)

off I believe (don’t have the specs for an 8250 or a 16550
handy at the moment)

Thomas

“Michael J. Ferrador” <n2kra@orn.com> wrote in message
news:8vvahi$h79$1@inn.qnx.com

the default for -t on devc-ser8250 is 0

does that mean - off

Actually I’m not sure, but I am sure someone else will.

or - auto detect (14 on a 16550A or better)


And I know you will say this is a hack that Linux needs -

I wouldn’t call it a hack at all; on chip buffering has a lot of
desirable attributes. One attribute of on-chip buffering that
is not good (from a real-time POV) is that it introduces a
latency. The latency introduced is often not a problem, but
sometimes it is.

BUT, don’t you need EVERY optimization in a RT system???

No. Precisely because a real-time system will process a
rx interrupt (and the interrupts resultant pulse handler) in a
determined period of time, and because with QNX that
deterministic interval is smaller than the inter-character
interval generated by the interruption rate associated with
(say) a 10,000 byte per second (115 kbps) data stream
(100 usec/byte), you don’t need to have on-chip buffering,
in order to reliably receive all data.

Having said that, it is certainly much more efficient to enable
on-chip buffering, and, with an RTOS like QNX this will free
up more CPU for you lower priority processes. As above,
the only caveat is if the remote side of the connection sends
12 bytes and then stops, your RT app won’t receive notice of
the first byte in the buffer (all ready received 1.2 ms ago) for
another ms or two (depending on the timeout factor). There
are definately real-time applications where this latency would
be unacceptable.

IRQTUNE - > http://www.best.com/~cae/irqtune/

dedicated hardware - arrange your interface’s IRQs to
minimize forwarding/router/NAT/firewall delay
professional audio