Igloopatch Revisited

[Bob Thrush x210]

In article <1162 at igloo.Scum.COM> learn at igloo.UUCP (william vajk) writes:
> [deleted]
>Average speed for transfers based on 9600 baud fall in the high 700 char 
>range. 19.2 with this hardware and software is a dream to forget.

  My milage with a 6 Mhz 1 wait original IBM AT with 16550 and
TB+:
  ~600 chars/sec uucp receive rate on an otherwise idle system.
  ~800 chars/sec uucp transmit rate on an otherwise idle system.
The above numbers were collected from the other end of the connection,
since the clock interrupts are mostly missed during TB+ activity
thus rendering the local clock useless.

  The TB+/16550 combo has been working very well for me since July, 1988.
I have not experienced the lockup that others have reported.

  Although I'm not using the igloopatch, I have a script that uses
/src/outb.c to enable the fifo's.  I experimented with different 
fifo thresholds and was unable to measure any significant difference 
(other than the system would not work at 9600 when fifo's were disabled).
I wound up with 'outb 2fa 01; outb 3fa 01'.

  The bottom line is that enabling the 16550 fifo allows 9600 baud uucp
operation with the stock 2.4 serial drivers.  I believe that higher
performance (maybe 19200) would be possible if a driver were crafted
specifically to take advantage of the 16550 and implement hardware handshake
with the TB+.

>
> [most of igloopatch deleted]
>
>		In addition, if the CPU takes too long to read the FIFO, the
>	16550 will send its own flow-control to throttle back the incoming
>	data, preventing buffer over-runs that have plagued microport from day
>	one.

  I have a 16550A preliminary data sheet and did not see this reference.
Could you elaborate on this "other flow-control" mechanism?  As I recall, 
the RTS and DTR pins are controlled only by explicitly programming the 
modem control register.

-- 
Bob Thrush                 UUCP: {rtmvax,ucf-cs}!tarpit!rd
Automation Intelligence,   1200 W. Colonial Drive, Orlando, Florida 32804