Re: 24 x 80 is too small.

[Douglas Handy <dhandy1@xxxxxxxxxxxxx>]

Trevor,

>By modern I was not referring to block mode. What I was saying was that we
>used to design according to poor performance - that being caused by block
>mode. 

On the contrary, IMHO block mode leads to *better* performance on systems.  It
is what allows the offloading from the main CPU of handling keystroke level
processing and lets a IOP like the WS controller handle the traffic until an
"Attention IDentification" (AID) generating key is pressed.  It is only then
that a program must resume execution or be swapped back into storage, and this
allows the main processor to handle more tasks more efficiently.

With this model, interactive programs spend most of their time in a wait state
so the CPU can service a higher volume of concurrent users or get more batch
work done while awaiting the next AID request from a block mode device.

If the program had to run to service each key press and release, you'd have much
more task dispatching going on and you'd need much more horsepower for good
performance with the same number of interactive users.

With block mode, you can only get "poor performance" when a block is sent and
received.  On underpowered systems where that is true, you could get much worse
performance if the system had to respond at the keystroke level instead.

Block mode is why we could have subsecond response times with multiple
concurrent users even when the entire main storage was 48-64KB (not MB) on the
early S/34's.  And by using MRT's, we could handle an even higher concurrent
user load in a given amount of main storage.

And if we were working with remote workstations over a speedy multipoint 2400bps
line, block mode was even more beneficial...

Just my .02,
Doug