Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.PCS 1/10/84; site ahuta.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!ahuta!dmt
From: dmt@ahuta.UUCP (d.tutelman)
Newsgroups: net.micro,net.college
Subject: Re: Overloaded Computing Systems
Message-ID: <333@ahuta.UUCP>
Date: Tue, 8-Jan-85 08:46:15 EST
Article-I.D.: ahuta.333
Posted: Tue Jan  8 08:46:15 1985
Date-Received: Wed, 9-Jan-85 03:26:31 EST
References: <773@amdahl.UUCP> <10468@watmath.UUCP> <1312@eosp1.UUCP> <4844@utzoo.UUCP>, <7195@watrose.UUCP>
Organization: AT&T Information Systems Labs, Holmdel NJ
Lines: 34
Xref: watmath net.micro:9023 net.college:622

REFERENCES:  <773@amdahl.UUCP> <10468@watmath.UUCP> <1312@eosp1.UUCP> <4844@utzoo.UUCP>, <7195@watrose.UUCP>

> The last time I used an IBM 4341 (approx CPU power of a VAX 780) with
> 80 users (active) to do editing on a 3278, there was a minimal degree
> of I/O wait involved......
> The point is this.. mainframe channel-style architecture exacts a small
> convenience price for a huge performance improvement.
> Real life has confirmed this many times over for me, and that's why I'd
> rather use VM/CMS for editing than vi and 4.2bsd, especially if system load
> is a problem.
> ......
> Wether the performance improvement is due to full duplex or not, I cannot
> answer, but I can type and read input simultaneously on a 3278, so it looks
> all the same to me !!!

Once again ..... The performance improvement has little to do with
EITHER full-duplex or "Mainframe channel-style carchitecture". It lies in
the combination of terminal and application:

-	The 3278 terminal does not send every character as it is keyed in.
	In most applications, it doesn't even send lines, but full
	screens. I'm not sure exactly what you're doing, but I bet
	you're using the buffering and screen editing built into
	the 3278 in some useful way.

-	"vi" uses raw input, which interrupts the application every
	keystroke.... VERY consumptive of real time. It is NOT the
	full-duplex transmission (used by UNIX in line input mode
	as well) that's causing the problem. If your mainframe
	application needed to capture arbitrary keystrokes, all the channel
	architecture in the world wouldn't keep it from being a
	drain on real time.

					Dave Tutelman