Kdavid@gizzmo.UUCP (David Solan) (07/01/88)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.
Is an additional change in /etc/gettydefs needed? What about
changing the "s4" or "vt-100" entries in /etc/termcap by adding:
:pb#19200: ?? What about changing /unix itself?! If you have any
ideas, I would be glad to experiment with them on a separate machine I
have available if you are afraid to do so on yours.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Solan
Objective Programming Incorporated
Post Office Box 123
Norwalk, CT 06856
Voice: (203) 866-6900
attmail: <!dsolan>
USENET: gizzmo!kdavid
--
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
{codas,u1100a}-----\
David Solan rutgers!rochester!pcid!kodak!gizzmo!kdavid
{lazlo,ethos,fthood}-----/jlw@lznv.ATT.COM (j.l.wood) (07/01/88)
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
alex@umbc3.UMD.EDU (Alex S. Crain) (07/03/88)
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 >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. Sorry, Its even more fundimental thatn that. A vt100 can't scroll at 19Kb, period. It can talk at 19Kb through the wonders of XON/XOFF flow control. That means that the terminal will accept input at 19K until its internal buffers fill up, and then send XOFF (^s) to the host which instructs the host tostop sending input until an XON (^q) is sent, after the terminal has dispersed its buffered data. The window driver can't talk at 9600 baud either. 19Kb terminal output is only really useful over terminal networks, because it enables the host to send data in spurts, and terminals spend less time waiting for other terminals. I would be interested to see if two 3b1's could sustain 19Kb (or higher) file transfers (uucp or whatever). Anybody ever tried? -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
jcs@tarkus.UUCP (John C. Sucilla) (07/05/88)
In article <1060@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: > I would be interested to see if two 3b1's could sustain 19Kb (or >higher) file transfers (uucp or whatever). Anybody ever tried? Well, for what it's worth my 3B1 (tarkus) has a TrailBlazer+ on tty002 and it's locked at 19200 between the modem and the machine. I just started talking csdev's 'Blazer (csdev is another 3B1) and the average throughput so far is 947 bytes per second. I'm not sure if Garry's 'Blazer is locked at 19200 like mine or if it's set up for 9600. On the other hand, tarkus gets it's news feed from ddsw1 (a Tele-386) with a 'Blazer set to answer at 19200. I just got the latest maps from Karl over there. The 2,176,135 byte xfer got here at 1031 bytes per second. Sending small files like mail shows even greater throughput. A 1500 byte file can be dumped into the 'Blazers buffer in one chunk and would show a througput of > 1500 bps. I think the highest number I've seen was a little over 1700 bytes/second. Therefore yes, the 3b1 can handle 19200 baud. The slower rates can be blamed on uucp overhead and Telebit turning the line around. BTW: 19200 is the max for the UNIX-PC, it'll never do 38K as is (Grrr). -- John "C". Sucilla, A silicon based life form. {ihnp4,chinet,ddsw1}!tarkus!jcs You have a better idea? Now's the time..
kls@ditka.UUCP (Karl Swartz) (07/07/88)
In article <1060@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: > I would be interested to see if two 3b1's could sustain 19Kb (or >higher) file transfers (uucp or whatever). Anybody ever tried? I've had two different machines connected to ditka at 19200 for uucp transfers, running HDB. One is formtek, a Sun-3/180 at my office, talking via Telebit TrailBlazers running at 19200 on both sides. Large news batches regularly show 1300-1400 bytes/second as reported in xferstats. (I also talk to a few out-of-state TrailBlazers; these times aren't quite as good but are still in respectable range.) The other case was a hardwire to royko, a 0.5 MB 7300, also with HDB. Here, I only saw about 800-900 bytes/second. Looks like the serial port can handle the speed, but the machine can't really keep up with it. -- Karl Swartz |UUCP {emoryu1,pacbell,decvax!formtek}!ditka!kls 1-412/937-4930 office | {pitt,psuvax1}!idis!formtek!ditka!kls |BIX kswartz "I never let my schooling get in the way of my education." (Twain)