mp@allegra.att.com (Mark Plotnick) (10/13/90)
A few people here with low-end Sun-3's (e.g. 4MB diskless 3/50 and 3/75) have expressed interest in using OpenWindows so that they can run pageview. OpenWindows 1.0 seems rather sluggish, though, compared to sunview. I know OpenWindows 2.0 runs faster in benchmarks on well-endowed systems, but is there also an improvement on memory-poor diskless systems where paging may be a factor? If not, is it worth our while to try to get OpenWindows 1.0.1 from Sun? Mark Plotnick allegra!mp or mp@allegra.att.com
hedrick@athos.rutgers.edu (Charles Hedrick) (10/13/90)
I have a 3/50 on my desk (though I must confess that normally I use someone else's desk, and he has a 3/60). I consider OpenWindows releases previous to 2.0 -- even 2.0 beta -- essentially unusable on a 4MB 3/50. 2.0 is just barely usable. However X11R4 is noticably faster, at least with the tuning we've done. The difference is enough to matter, as it takes you from a situation where you really wonder if it's worth using windows at all to one that is usable. Here's what we've done to optimize X11R4 for small systems. First, we have a special image that has removed as much as possible, things like color support, support for xdm, etc. The goal is to get as small an image as possible. (Removing the shapes extension didn't seem to save enough to be worth doing.) Also, on a 4MB system I recommend running the X11R4 server with the options -su -bs. Finally, I strongly suggest disabling the swapper on SunOS 4.0.x: adb -w /vmunix nosched?W 1 ^D It doesn't take effect until reboot. This patch was originally proposed as a workaround for the PMEG problem on SS1's, but seems to make 3/50's noticably more responsive. So in short, if your target is a 4MB system, I would not bother trying to get any OpenWindows before 2.0. 2.0 is usable if you have some strong reason to need it, like you're a user support person trying to support people with 8MB systems, but you're stuck with a 4MB system. But for most purposes I recommend using X11R4 on 4MB systems. I believe the reason X11R4 performs better is simply that it's smaller, and on a 4MB machine that's more important than CPU use.
naughton@wind.Eng.Sun.COM (Patrick Naughton) (10/14/90)
In article <42929@andante.UUCP>, mp@allegra.att.com (Mark Plotnick) writes: |> A few people here with low-end Sun-3's (e.g. 4MB diskless 3/50 and 3/75) |> have expressed interest in using OpenWindows so that they can run |> pageview. OpenWindows 1.0 seems rather sluggish, though, compared |> to sunview. I know OpenWindows 2.0 runs faster in benchmarks on |> well-endowed systems, but is there also an improvement on memory-poor |> diskless systems where paging may be a factor? If not, is it worth our |> while to try to get OpenWindows 1.0.1 from Sun? |> |> Mark Plotnick |> allegra!mp or mp@allegra.att.com Hand in hand with the performance tuning we downsized the server quite a bit. The working set of the V2 server and a set of V2 XView tools is quite a bit smaller than the same configuration was in 1.0.1. I don't have the numbers handy, but I'd say you will notice a win with V2 on 8M machines, but 4M 3/50's will still page if you run the clients locally. If you just run the xnews server on the 3/50 and run ALL of the clients from a server then V2 should work well for you. I wouldn't bother even trying this with 1.0.1. -- ______________________________________________________________________ Patrick J. Naughton ARPA: naughton@sun.com Window Systems Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: (415) 336 - 1080
ktl@wag240.wag.caltech.edu (Kian-Tat Lim) (10/14/90)
With regard to this discussion of the speed of OW2.0, we have found that it feels slow on our 4/20s (SLCs) with 8 MB. Two are configured with /, /var, and swap on a local disk, with the rest NFS-mounted; the third has everything including /usr/openwin on its 380 MB disk. Slowness involves a number of components. Startup time is about 90 seconds (compared with 30 for the NeWS server on our SGI 4D/25s). Input-focus changes (I use "Move Pointer" focus policy) can take multiple seconds. Bringing up menus can also take seconds. This is with a modest set of clients: 3 cmdtool, cm, clock, mailtool, perfmeter, emacs (18.52 under X). The culprit seems to be lack of real memory; vmstat gives a "fre" number less than 512K all the time, and much paging and swapping seems to be occurring. The kernel has been trimmed down, but is still 1076624 bytes (text+data+bss). Installing the PMEG patch did little for performance, though no stolen PMEGs are now reported during normal operations. Does anyone have suggestions for speeding OW2.0 up, besides buying more RAM (a path we are already looking at)? Only DECwindows on an overloaded VS3100 approaches the slowness of common OW tasks, making systems like NeXT look attractive as low-end workstations. -- Kian-Tat Lim (ktl@wag240.wag.caltech.edu, KTL @ CITCHEM.BITNET, GEnie: K.LIM1)
laukee@canon.co.uk (David Lau-Kee) (10/15/90)
ktl@wag240.wag.caltech.edu (Kian-Tat Lim) writes: > Slowness involves a number of components. Startup time is >about 90 seconds (compared with 30 for the NeWS server on our SGI >4D/25s). Input-focus changes (I use "Move Pointer" focus policy) can >take multiple seconds. Bringing up menus can also take seconds. This >is with a modest set of clients: 3 cmdtool, cm, clock, mailtool, >perfmeter, emacs (18.52 under X). > The culprit seems to be lack of real memory; vmstat gives a >"fre" number less than 512K all the time, and much paging and swapping >seems to be occurring. The kernel has been trimmed down, but is still >1076624 bytes (text+data+bss). This is surprising. We ran OW2 on 4/20s with 8Mb (since upsized to 16) and I don't remember speed problems anything like as bad as you indicate (and this was before a proper kernel was configured). Diskless at 16Mb startup is under 30 seconds, focus changes and menu raises are effectively immediate. Top says the server sits around 3Mb resident. Your kernel looks a little large at 1076624 bytes (text+data+bss). We get: jessica:ttyp0 size /vmunix text data bss dec hex 688128 111280 33952 833360 cb750 without any sort of fiddling at all. ------------- David Lau-Kee Canon Research Centre Europe, 17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. NRS: laukee@uk.co.canon, INET: laukee%canon@nsfnet-relay.ac.uk UUCP: laukee@canon.uucp, PATH: ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360