gnu@sun.uucp (John Gilmore) (01/14/85)
> > 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... > > 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 !!! It's actually not the channel architecture but the terminal<->host protocol that is in question here. A UNIX application that restricted itself to running on block-mode ASCII terminals (and DMA serial I/O hardware) would have the same low I/O overhead as the IBM system. You can run conversational terminals on IBM systems, but since the I/O system assumes each interrupt is for a large block of data, it's not optimized for the kind of 1-char tty interrupts taken by typical UNIX systems. There is a minor channel architecture problem in that an IBM subchannel can't both read and write a device simultaneously, but this can be trivially solved by calling each terminal two devices. Mainframes these days use a front-end processor to talk to the terminals anyway, so you could hook up conversational terminals to one and STILL not have high I/O overheads in the mainframe. The front end can decide whether to interrupt the mainframe on each character or to gather up a bunch and then interrupt. Of course, it must be told by the program in the mainframe which action is desired. Multics does this pretty well, I'm told -- it was done by Bernie Greenberg for Emacs support. Due to severe brain damage on IBM's part, 3270 terminals cannot scan the keyboard and display output simultaneously. In an application like Multiple Console Support (make a 3270 into a system console), the screen can update or scroll at any time while you type a command into the input area, losing whatever keystroke you happen to be pressing at the time. This may have been fixed in the 3278.