Post by ***@gmail.comPost by a***@math.uni.wroc.plconnector. He also said that transmissin was
via interrupts and that "IBM does not like
interrupts". I take this to mean that each
character triggered a separate interrupt.
My guess is that the guy connected "external
interrupt" line (which IIUC is standard thing
for IBM processors) to parallel-port style
connector so that modem could interrupt the
mainframe. Concerning "IBM does not like
interrupts": transmiting one character per
interrupt was horribly inefficient by IBM
standards. Since this was single line, there
was no problem. But the machine had probably
about 80 terminals connected using standard
IBM interfaces. Running 80 terminals in
async mode probably would not work (I mean
running in hacky way without something
like 3705).
I would hope that after 30 years (or whenever you were
doing this) of technology improvement that mainframes
can now cope with 80 terminals where previously they
could only do 1. I wonder what percentage of a modern
z/Arch CPU would be consumed coping with 80 monkeys
banging away on keyboards as fast as they can, with
each keystroke causing an interrupt.
Note that I wrote "character", not a keystroke. Most
people can not type faster than 10 cps and most of
the time will type slower. So 80 persons will
generate on average probably less than 200-300 keystrokes per
second. But characters include system answers, which
typically are much larger. And file transfers
where as fast as link would allow (something like
480 cps or 960 cps). Some of terminals were PC with
3270 interface, they could tranfer files rather
fast.
To put this differently, on 386 with its standard dumb
serial port it was quite possible to lose charaters
at higher transmission speeds because CPU was too slow
to handle interrups on time. Certainly such machine
would be overlowded by 30 standard dumb serial ports.
OTOH 386 machine generously equipped with memory (which
probably meant 16MB) was able to handle about 30-40
students connected via telnet and editing/compiling C
programs. Telnet transmits each keystroke separately
(in separate network packet) and normally keystrokes
were echoed by application (shell or editor) running on
386. So you got process switch and packet with echo.
Each packet were acknowledged so there were 2
acknowledgments. Normally one acknowledgment was
carried by echo packet, so there were 3 packets
per keystroke. Looks like a lot of activity, but
machine could handle it. However, opening file in editor
or paging trough file would cause screen redraw which
probably went in two packets. With dumb async link
screen redraw means 2000 interrupts.
Coming back to mainframes, 3705 (maybe 2 or 3 for faster lines)
could easily handle 80 async lines. I pretty sure that
limitation of line or 3270 mode was mostly software one.
That is hardware had enough CPU power enough to handle
input in character mode. Tricky thing is memory, in
3270 mode mainframe discs were fast enough to swap in/
swap out user VMs when needed. In line mode there
are more context switches, so more disc trafic.
Character-by-character is worse, probably 50-100
times as many context switches as in 3270 mode.
100 times as many context switches means more/faster
discs or enough real memory to keep all active code
and data in RAM.
Of course, with modern machines 80 users should be no
problem. But if you pay for z/Arch machine you
probably want more from it. Several years ago
IBM reported that is z/Arch machine handled 100000
web server hits pers second. For traditional
mainframe app that would mean generating 100000
screens per second. Typical expectation is that
user will want new screen on average once per 30
seconds. That means that this machine could
handle 3000000 users simultaneously. If you have
smaller number of simultaneous users, say 10000
than PC class machine will do. But you need to
program your system in efficient way. Allow
waste and you may have trouble with 50 users.
--
Waldek Hebisch