Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!basser!yar From: yar@basser.oz (Ray Loyzaga) Newsgroups: comp.arch Subject: Re: X-terms v. PCs v. Workstations Message-ID: <2762@basser.oz> Date: 3 Dec 89 22:42:41 GMT References: <1128@m3.mfci.UUCP> <1989Nov22.175128.24910@ico.isc.com> <3893@scolex.sco.COM> <39361@lll-winken.LLNL.GOV> <17305@netnews.upenn.edu> <1989Nov25.000120.18261@world.std.com> <1989Nov27.144016.23181@jarvis.csri.toronto.edu> <1989Nov27.213238.24130@cs.rochest Organization: Dept of Comp Sci, Uni of Sydney, Australia Lines: 92 In article <32382@winchester.mips.COM> mash@mips.COM (John Mashey) writes: > How about getting this off the sociology track [because most of it came > down to "I know good compcenters" vs "I don't], and consider some of > the interesting system architectural issues, like: > > 1) How much load do X-window terminals put on a a host? > 2) How much load do diskless nodes put on a host? > 3) If the people are doing the same kind of work, does the host do more > or less disk I/O in cases 1) or 2)? How does the Ethernet traffic differ? > 4) Experiences with X-window terminals: how many can be served, doing what > kind of work, from what kind of host? > 5) How do you characterize the kinds of work that people do in any of > these environments? > -john mashey DISCLAIMER: > UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com > DDD: 408-991-0253 or 408-720-1700, x253 > USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 We have been doing quite a bit of evaluation of X-terminals as an alternative to workstations for undergraduate computing laboratories. The testing that we did was on a Mips M120-5, with 16Mb of memory, with 9 NCD16's, 1 NCD19 and a Visual X-19. We place 10 pgrads/hons/tutors/programmers in front of these terminals (one ncd16 was locked in an office!), and performed sufficient brain surgery to make them behave like second and third year computer science students (you can guess whether the surgery involved removal or addition of tissue!). 1. CPU load is hard to quantify, the machine stopped working 2. All our competent sun users run their applications on the fastest machines, this means or sun servers or (more likely) our 4 M120s. Distributed computing has just meant that our users just move from one cpu to another whenever a faster one comes along ... Measuring load on a sun. When we didn't have the M120's the sun servers were at their limit with the 10-12 diskless/dataless clients that they served. 3. On the basis of ethernet traffic, the analysis showed that a user with 5 xterms, running vi, and with an xclock running was doing about 2-3k worth of I/O on the ethernet, this is our expected typical student load (we don't actually expect to use vi!). A sun 3/50 running suntools was generating ~20k ethernet traffic for the same sort of task (fast editting of pascal source and running). On the basis of this we concluded that the x-terms were no problem on the ethernet if they were just used as text-based windowing systems. Running a program like xmaze or other graphically oriented X applications caused ~30kb of traffic on the ether. 4. The X-terms need ~3Mb to be as usefull as suns (~18 xterms, fast response, able to store overlaid windows in the backing store etc). They work very well, when served on a lightly loaded, well configured machine, they can be very fast (some reminders of blit performance on a single user vax), mainly from fast window creation/deletion, this is especially true for the NCD19(68020 processor). I'd expect between 15-20 can be served by a 48Mb M120. This should be true for our expected student loads. We were supporting 10 once we grabbed some boards out of our other machines and made the test machine a 32Mb beast. 5. X-terminals are a very good answer for people who want a windowed environment for mainly textual work, or program development. They will last longer than the server that they are connected to, and will therefore end up as a much cheaper solution than workstations that need to be replaced or seriously upgraded every few years because of the insatiable memory demands of commercial Unix systems. Most (90%) of our users fit into this category of users, the most popular "graphical" program run on our suns is a home grown troff proofing program, this sort of activity should suit Xterminals perfectly. People requiring "real graphics" should have their own dedicated workstation, but then again that machine should have at least 24 bit planes, 32Mb ram, and some serious disks, and > 10 mips in the engine room. Right now I don't think we can afford to give this to each of our users, so we compromise! 6. The above 5 questions should have been asked in something that approximates reverse order. Notes: Each "student" load was consuming ~2-3Mb of the CPU servers' memory. This is what cause the initial hiccup during testing. 48Mb should mean no swapping during normal use (20 users), although 32M was showing a small amount of swapping during the testing (10 users). There seems to be a large amount of swap fragmentation which caused some of the initial slow down, this could be an artifact of the way NTEXTs are treated in RISCOS? It is expected that the students will be using a windowing editor (Rob Pike's sam) and Killian's debugger (pi), which should be great win over vi and dbx. Xterminals will give us the ability to give a windowing environment to all our users, while fitting into our shrinking budgets (we are open to donations!!!), and allowing us to administer the machines with the few technical staff that we have, it should almost be like ascii terminals connected to some central machines. Ray Loyzaga, Basser Department of Computer Science Sydney University yar@cs.su.oz.au Brought to you by Super Global Mega Corp .com