Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.sys.sun Subject: Re: 4 MB Suns with OS version 4.0 Message-ID: Date: 23 Feb 89 12:03:28 GMT References: <8902031441.AA09131@rice.edu> Sender: usenet@rice.edu Organization: Rutgers Univ., New Brunswick, N.J. Lines: 70 Approved: Sun-Spots@rice.edu Original-Date: 14 Feb 89 18:47:59 GMT X-Sun-Spots-Digest: Volume 7, Issue 168, message 9 of 10 Yes, 4.0 has been a disaster. We use 4.0.1 on 4MB 2/50's and 3/50's. Reports are mixed. I did some side by side tests of a 4.0 one and a 3.2 one starting up suntools and lisp, and found things were OK. I use a 3/50 with 4MB as my normal machine, including building system software. It's certainly not a 3/60, but it works OK. But some users report that when they use a lot of windows, things are much slower. Our operator, who uses one window per server and switches a lot, was near to murdering us until we added aother 4MB to that machine. I've also had reports from some users that things seem a lot slower. It seems like there's a different paging strategy somehow. When you go back to a window that you haven't used for a while, chances are you'll have to wait while the program pages back in. One suspicion is that there's more of a tendency to let one program take over the whole system, so once a program is working in one window, all other programs get paged out more quickly than they used to. Sort of sounds like they let the working set grow too rapidly, doesn't it? But it could also be that paging with NFS is slower than paging with ND. There's a lot of things you can do to make things better: tailoring a kernel, making sure you don't run unnecessary daemons, making sure your syslog doesn't loop, etc. Sun has a list of them, and that list has been given here several times. But even after all of that is done, there is a difference between 4.0 and 3.2. I don't find 4.0 unbearable, but I just got a 3/50 as 4.0 came up, so I haven't had much experience under 3.2. I don't think you'll find single C compiles going slower. Where you'll be affected is when trying to do things in multiple windows. Note that I use X. I may be better off than suntools users. We have been able to build a shared X library, and so take advantage of that new facility to save memory. Unfortunately, we haven't been able to do that for suntools. The 4.0 suntools, although done with shared libraries, is too slow to be usable. We don't know what it is, but we went back to the 3.2 version. This helped, but didn't completely get rid of the difference. (I've contemplated building a 3.2 suntools with shared libraries, but this would involve some structural changes, so we haven't had time to do it.) At this point I plan to stick with 3.2 suntools until we get Sunview 2, which runs on top of X. Of course there's apparently some question whether the Sun merged X/NeWS will be usable on 4MB machines either. If not, we'll probably try to get people to migrate to the traditional X software. It does seem like things are faster on our 32MB Sun 4's. I'm not sure whether I'd switch if I had to do it again. My problem is that the university has lots of Sun's. Some need the new features, largely because of new hardware. We can't really maintain two versions. So we eventually have to upgrade. I'm sort of upset that the promised performance tuning is going to wait until 4.1, though as we start seeing how many bugs there are, I begin to understand that they have their hands full fixing bugs. I think at the moment I'd rather have not not add any features or change any algorithms, but just fix bugs. 4.0 and even 4.0.1 is fairly buggy. We have problems with just about everything related to networking. Rlogin sometimes doesn't turn XON/XOFF on and off. NFS hangs. ypbind crashes or goes catatonic. lockd crashes if your host name is long. Some of these have fixes. The ypbind from the answerline may fix the yp problems. But I have been using using at least one FTE person fixing bugs in the kernel and basic utilities for the last several weeks, and see no end in sight. I sent the first batch of fixes to sunbugs, and didn't even get an acknowledgement. I think if you have no strong reason to change, you might want to wait for 4.0.2. I think it will have a lot of the problems fixed, though I'm worried about rumors that they're not going to be able to tell us in detail what changed, as they did from 4.0 to 4.0.1, which means we'll just have to throw away everything and start from scratch. If I've done enough local work to make 4.0.1 stable by then, I may ignore 4.0.2. But a site without source will probably want to do it the other way. The other approach would be to wait for 4.1, which is supposed to address the performace problems. Though given our experience with 4.0, you might want t make it 4.1.2.