[net.periphs] Buffer overflow in AT&T 4425 video display terminals

larry@kitty.UUCP (Larry Lippman) (10/26/86)

	I finally got around to replacing the AT&T 4415 video display
terminals on our development 3B2 with 4425's, and relegated the 4415's
to other uses where their non-VT100 idiosyncracies did not matter.
	I just noticed something for the first time - which rather shocked
me (even though I had used 4425's previously).
	Since I was only running at 9,600 baud, and since the 4425 is supposed
to be an _improved_ terminal, I decided not to enable the DC1/DC3 mode.  No
problem at first - until I did a uulog, and watched the screen barf after
about 50 lines.  Any large text display (without attributes, even) causes the
screen to barf and lose characters, lines, etc. UNLESS the DC1/DC3 mode is
enabled.
	Why is this?!  These 4425's seem to have slower character throughput
than their predecessor 4415's.  I get FULL 9,600 baud throughput on other
VT100 clones, like the Datamedia DT-100. 
	In all fairness to AT&T, I find their terminals to be well-designed
and robust.  But WHY can't they achieve full 9,600 baud throughput like other
vendors?
	Can anyone tell me the _true_ character throughput for the 4425?
	Hello, AT&T/Teletype...

==>  Larry Lippman @ Recognition Research Corp., Clarence, New York
==>  UUCP:  {allegra|decvax|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry
==>  VOICE: 716/688-1231           {hplabs|ihnp4|seismo|utzoo}!/
==>  FAX:   716/741-9635 {G1,G2,G3}      "Have you hugged your cat today?" 

jkg@gitpyr.gatech.EDU (Jim Greenlee) (10/26/86)

In article <1384@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes:
>	Since I was only running at 9,600 baud, and since the 4425 is supposed
>to be an _improved_ terminal, I decided not to enable the DC1/DC3 mode.  No
>problem at first - until I did a uulog, and watched the screen barf after
>about 50 lines.  Any large text display (without attributes, even) causes the
>screen to barf and lose characters, lines, etc. UNLESS the DC1/DC3 mode is
>enabled.
>	Why is this?!  These 4425's seem to have slower character throughput
>than their predecessor 4415's.  I get FULL 9,600 baud throughput on other
>VT100 clones, like the Datamedia DT-100. 
>	In all fairness to AT&T, I find their terminals to be well-designed
>and robust.  But WHY can't they achieve full 9,600 baud throughput like other
>vendors?

I would say that a terminal which can achieve full throughput at the higher
baud rates would be the exception rather than the rule. The "baud rate" is
not necessarily the "baud rating", but is simply a number which guarantees
that the sending and receiving units will be synchronized to a common clock.
This is absolutely necessary for serial communications since there typically
is no acknowledgement between the two devices on a character-by-character
basis (as with most parallel connections).

My advice is just set the terminal up for Xon/Xoff protocol and don't worry
about the throughput. I know that the AT&T 5520 terminals are notoriously
slow because when a screen scrolls up, they do a lot of data copying instead
of just manipulating pointer registers in hardware. I do not know if this is
the case with the 4425, but my (admittedly limited) experience with it would
lead me to believe that it does the same thing.

(As an example of what I'm talking about on the baud rate, try connecting
a serial printer up at >= 9600 baud and no protocol - I imagine the results
will be much worse)
                                           Jim Greenlee
-- 
The Shadow
Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jkg

wb8foz@ncoast.UUCP (David Lesher) (10/28/86)

In article <2500@gitpyr.gatech.EDU> jkg@gitpyr.UUCP (Jim Greenlee) writes:
>In article <1384@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes:
>>	Since I was only running at 9,600 baud, and since the 4425 is supposed
>>to be an _improved_ terminal, I decided not to enable the DC1/DC3 mode.  No
>>problem at first - until I did a uulog, and watched the screen barf after
>>about 50 lines.  Any large text display (without attributes, even) causes the
>>screen to barf and lose characters, lines, etc. UNLESS the DC1/DC3 mode is
>>enabled.
>>	Why is this?!  These 4425's seem to have slower character throughput
>>than their predecessor 4415's.  I get FULL 9,600 baud throughput on other
>>VT100 clones, like the Datamedia DT-100. 
>
>I would say that a terminal which can achieve full throughput at the higher
>baud rates would be the exception rather than the rule. The "baud rate" is
>not necessarily the "baud rating", but is simply a number which guarantees
>that the sending and receiving units will be synchronized to a common clock.
>This is absolutely necessary for serial communications since there typically
>is no acknowledgement between the two devices on a character-by-character
>basis (as with most parallel connections).
>The Shadow
>Georgia Insitute of Technology, Atlanta Georgia, 30332
>...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jkg

I did some work a few years ago to "load down" a CSMA/CD LAN to see
what it really offered in throughput. One of my biggest problems was that
NO (text) terminal in the house could keep up. The only box fast enough
(Note this was 9600) was a $$$$ TEK graphics terminal. I do not recall
the # of it, but it had a 80286 aux processer built into it, if that helps.
It offered speeds up to 38.4, but I never found a fast enough source to test
that aspect.

-- 

		      decvax!cwruecmp!ncoast!wb8foz
			ncoast!wb8foz@case.csnet 
		(ncoast!wb8foz%case.csnet@csnet-relay.ARPA)

    	         		"SERIOUS?
		Bones, it could upset the entire percentage!"