droms@hydra.bucknell.EDU ("Ralph E. Droms") (01/18/89)
Can anyone with experience in replacing ASCII terminals with X Window System terminals (e.g., Visual 640 XDS) comment on the difference in CPU cycles required to support ASCII vs. X Window System. Suppose I have a VAX supporting twenty users - how much extra overhead is imposed by talking X instead of async. serial? Has anyone compared the per user cost of Visual 640 XDS + VAX versus Sun workstations (including file servers)? I'm trying to collect information to be used as input for our computer center, which is planning for an upgrade to its computing systems. I'd like to gather anecdotal or qualitative data that can help the center choose between centralized computing/terminal and workstations. - Ralph Droms Bucknell University Lewisburg, PA 17837 droms@sol.bucknell.edu droms@bknlvms.bitnet (717) 524-1145
swick@ATHENA.MIT.EDU (Ralph R. Swick) (01/18/89)
>Can anyone with experience in replacing ASCII terminals with X Window >System terminals (e.g., Visual 640 XDS) comment on the difference in >CPU cycles required to support ASCII vs. X Window System. Suppose I >have a VAX supporting twenty users - how much extra overhead is >imposed by talking X instead of async. serial? I think the differences in overhead between driving the X protocol on top of (e.g. TCP) on top of IP and bare-bones ASCII with XON/XOFF, various line disciplines, etc. (on e.g. RS422) will be far outweighed by the effect of just a couple of moderately sophisticated users of (any) window system. It would be appropriate to think of an ASCII terminal as a governor (constrictor) on each user. The two environments and the kinds of things users try to do with each are so vastly different that capacity planning based upon system overhead metrics is not likely to get very far. I suggest you arrange a visit here to Project Athena. :-)
smokey@WSL.DEC.COM (01/18/89)
Ralph: As a long time user of such systems, the real "problem" is not the system overhead involved with support X terminals vs. ASCII terminals. While there is probably much more overhead involved in supporting X (particularly burst repainting) that is not very significant compared to the "multi context" capability X offers over ASCII terminals. What really happens is that your 20 users are now capable of maintaining and interacting with many more simutaneous activities. People routinely read their mail, compile programs, debug others, compose documents, etc. ALL AT THE SAME TIME and X make them all a lot better at doing it. Now you can argue that they can't really be typing at all these applications simultaneously, but in fact the simplest users will start doing 2-3 things at once, and the really good guys will burn up all the cpu cycles you can possibly supply. One solution is to provide real workstations for your more sophisticated users and encourage them to do most of the computes locally. This presumes they then only use the central or networked resources for file storage, printing, etc. In doing this you will invent some other serious problems, like data backup, file sharing and so on, but there are no free lunches in this game. From a system manager/purchase position this all looks pretty bleak, but from the percpective of a manager who is trying to get the work done (research products, whatever) this all means more productivity. Most significantly it means more effective use of the end-users valuable time. This may not mean anything in a university setting, but for those of us in industry, it is a big deal. smokey@wsl.dec.com
leech@zeta.cs.unc.edu (Jonathan Leech) (01/19/89)
In article <8901181314.AA12697@LYRE.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: >of (any) window system. It would be appropriate to think of an ASCII >terminal as a governor (constrictor) on each user. The two environments >and the kinds of things users try to do with each are so vastly >different that capacity planning based upon system overhead metrics >is not likely to get very far. I find the 'window' tty-based window manager on BSD does 90% of what I want a window system for. The only major thing missing is large editing windows, and Ann Arbor can fix that problem. Followups to comp.terminals.misc. -- Jon Leech (leech@cs.unc.edu) __@/ ``After all, the best part of a holiday is perhaps not so much to be resting yourself as to see all the other fellows busy working.'' - Kenneth Grahame, _The Wind in the Willows_
ed@lupine.UUCP (Ed Basart) (01/21/89)
There are two ways that I use to think about how an X display station (aka X terminal) affect host systems. The first way is to imagine that the X station replaces a "dataless" Sun 3/50. The traffic that one finds between the workstation and the various hosts is essentially the same (especially if the Sun user is an X user) as with an X station. Note that dataless Suns have a small local disc to take care of booting and paging, so this activity is not on the net. This means that if you know the dataless workstation/server ratio, you can use the same ratio for X stations. The second model is to make the display station do terminal activity, just like a terminal. This means receiving input from the keyboard (I'll ignore the mouse in this comparison), and blasting the screen with characters. All comparisons that I've ever seen has shown output to outweigh input by a large factor, so I'll just talk about output. In our shop we have connected 10 stations to a Sun IV, and had them all "cat"-ing away. If memory serves me well, we measured an aggregrate throughput of 45,000 characters/second before the Sun ran out of gas (100% cpu utilization). I've never tried the same test using real terminals (especially ones that can run at 4,500 characters/second), but my guess is no more than 20 terminals can be run at full speed by a Sun. Now I know that real terminal users are interactive and what's really important is to measure a "transaction", which is typing a key and getting it echoed. The important measure is response time, and the maximum number of people typing before response time begins to vary. Once we can establish such a benchmark, we'll have a better measure. However, as has been pointed out, it's not clear how relevant it is to limit the X station to behave just like a terminal.