Path: utzoo!utgpu!water!watmath!uunet!labrea!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!zorch!pacbell!att!lzaz!lznv!jlw
From: jlw@lznv.ATT.COM (j.l.wood)
Newsgroups: unix-pc.general
Subject: Re: achieving 19200 baud on the UNIX PC
Summary: EXTA -> 19200 bps
Keywords: 19200 baud console remote terminal
Message-ID: <1395@lznv.ATT.COM>
Date: 1 Jul 88 13:07:37 GMT
References: <187@gizzmo.UUCP>
Organization: AT&T ISL Middletown NJ USA
Lines: 87

In article <187@gizzmo.UUCP>, Kdavid@gizzmo.UUCP (David Solan) writes:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> It was suggested by Bob Ames that you could achieve a baud
> rate of 19200 by replacing getty in /etc/inittab with uugetty.  Though
> I was successful in getting the following to work with the console
> screen:
> 
> vid:2:respawn:/usr/lib/uucp/uugetty -t60 window 19200
> 
> and, though I was successful in getting the following to work with an
> RS-232 port (using a VT-100 terminal set to a 19200 rate on Transmit
> and Receive):
> 
> 000:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty000 19200
> 
> neither seemed to have ANY effect whatsoever in speeding up cat(1)'s
> to their respective screens, or to speed up very long scrolls in the
> vi editor, to take two examples.  I DID check this out by changing the
> prompts in /etc/gettydefs, and indeed, the 19200 prompt WAS coming out
> in both cases, and I also checked it out by keeping the VT-100 at 9600
> while raising the uugetty to 19200, producing pure gibberish on the
> screen, but, I repeat, there was no significant change in the rate of
> output to the screen at 19200 baud versus 9600 baud!
> 
> Obviously, this "19200", if it is real at all, is in SERIAL
> CONNECTION with a 9600 baud rate or such somewhere or other in the
> internals of the machine, thereby rendering the 19200 rate effectively
> null and void.
> 
> Curiously, even though the vi editor scroll seems to pause to
> catch its breath every 20 lines or so, while the cat(1) command seems
> to send its output to the screen in a more continuous flowing manner,
> both seemed to put out about the same number of bytes per unit time
> for long screen outputs on the UNIX PC or on a remote terminal,
> effectively about 8000 baud or so (assuming 9 bits out per byte) --
> with the remote doing a little better than the UNIX PC console,
> ESPECIALLY for files with short lines and many return carriages.


A couple of things about this posting.

1.  The raw bps of the port in asynchronous (also known as start-stop)
    communications has almost no bearing on the throughput when you
    exceed the throughput capcbility of one of the end devices.

2.  VT-100s cannot achieve a throughput of 9600 bps let alone 19200.
    There will be a whole lot of XOFFing and XONning going on.


I am also running a unix-pc at 19200 bps and achieving not so great
performance. I have a 630 MTG terminal and often run layers.  There is
one thing I had to do on my 3.51 system.  When I tried to change
the /etc/gettydefs entry to set the bit rate to 19200 by changing
B9600 -> B19200 I got something strange. (NB: the bit rate argument to
getty (uugetty) isn't the real bit rate, it's only a label to be matched
against a line in /etc/gettydefs; that's where the <real> bit rate
setting goes on.)  I think it went to the default of 300bps since the
flag wasn't recognized.  Calling on my vast (sic) store of old-time unix
lore I used EXTA as the new bit rate.  This at least established communications
with the terminal at 19200, but the performance didn't improve significantly. 
My terminal is attached to tty001 on a combo card if it matters.

Joe Wood
lznv!jlw

d
u
m
b

o
l
d

i
n
e
w
s

f
o
d
d
e
r