7300 and 9600 baud modems

[Bill Mayhew]

Cu is not a good way to judge the throughput of your serial
connection.  One obvious problem is that if you are logged in at
the console of the UnixPC, you are using /dev/w... for tty output.
The window driver has to do processing of the escape sequences, and
deal with the bitmap of the window to display the output.  Chances
are, what you are seeing are the delays of the console driver and
not the modem/port itself.

There are also two flavors of cu.  The stock cu that comes with the
machine writes each character to stdout as it is received.  This is
s-l-o-w, and in fact can't even keep u with a 1200 buad modem.  The
cu that comes with Honey DanBer uucp is much better.  It buffers
something like 64 characters and writes them to stdout all at once.
Of course, there is a time-out such that the characters are written
anyway after a certain delay, even if an entire 64 aren't received.
The HDB cu can keep up close to 4800 baud output to the console.

Speaking of uucp, there's the ticket for gauging throughput more
fairly.  You have to make sure that you send big files though, as
the LOGFILE or xferstats includes the overhead of closing the file
in the char/sec times it reports.  30Kbyte minimum files for fair
resuls are needed.  My tests show that a UnixPC can keep up a
steady rate of 1200-1400 char/sec in uucp if there aren't any other
piggy processes running.  With smart high speed modems, the best
results obtain when the CPU feeds the modem at a higher rate than
the physical transport will support, and allowing the modem to
mediate flow.  This works particularly well with the uucp spoofing
in the Trailblazer mdoem since the uucp packets are small, and the
modem can mediate flow by simply stopping ACKing packets for a
while.  Uucp will gag if the modem inserts an Xoff (control S)
character in the data stream in attempt to do in-band flow control.
While not pure ANSI RS232 spec, the Unix C does do hardware flow
control with the RTS/CTS modem leads.  The RS232 spec defines the
leads only for initial handshake, so the Unix PC is in essence an
upward compatible extension of the standard.  The default for
hardware flow control is OFF.  The tty driver defaults to xon/xoff
flow control.  Use /etc/hfc +/dev/tty00x to endable HFC.  One side
effect is that you can not have your cake and eat it too.  You will
lose xon/xoff recognition when you turn on HFC.  With the
Trailblazer, it is best to leave xon/xoff enabled, since the
packets are small enough in uucp to not need flow control.

For the record, the only terminal I have used that actually has full
cursor addressability and all the bells and whistles of a smart
terminal AND can keep up a steady 9600 baud throughput without any
flow control is an HP 2645.  Of course, there may be others, but
the 2645 is the only one I have seen.  The 2645 was designed around
1976, and has a TTL bit slice processor; it is also about the size
of a Yugo.

An Apple ][ will not come anywhere close to displaying at 9600 baud
on its console if you use the I/O routines in the monitor ROM.
This is espically true if you have an Apple //e - enhanced model
with the 65C02 and new ROMs with mouse support.  The ROMs switch
off interrupts for ~30 mS at various points so the mouse can be
read (like when you write a CR to the display).  I know about this
from an Apple program I wrote that had to keep track of a A/D board
and write to the console at the same time.  It was a major pain in
the neck on that machine.  Even a program like Proterm that doesn't
use the monitor I/O can't keep up becasue too much CPU time is
required to swap bytes around in the screen character buffer to
effect scrolling ... especially true if the 80 column screen is in
use on a //e.  Put a data monitor on the Tx leads of your apple and
then cat a file to it at 9600; chances are good that the comm
program will be sending a lot of xon/xoff to keep from dropping
characters.  Don't feel bad; a VT-240 will start to send xon/xoff
at 2400 buad in text mode even without any cursor addressing!


Cheers,
Bill