Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!hanche From: hanche@imf.unit.no (Harald Hanche-Olsen) Newsgroups: comp.sys.apollo Subject: Re: DON'T PUT SR10.3 ON DN2500 !!!! Message-ID: Date: 27 Jan 91 17:10:40 GMT References: <1991Jan25.160628.10897@alchemy.chem.utoronto.ca> <1991Jan26.181425.21685@quintro.uucp> Sender: news@ugle.unit.no Organization: The Norwegian Institute of Technology, Trondheim, Norway. Lines: 41 In-Reply-To: kts@quintro.uucp's message of 26 Jan 91 18:14:25 GMT In article <1991Jan26.181425.21685@quintro.uucp> kts@quintro.uucp (Kenneth T. Smelcer) writes: In article <1991Jan25.160628.10897@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >There is a severe bug in SR10.3 on DN2500's (only DN2500's according to the >Hotline) - the system clock goes crazy, gaining 1-10 minutes for every >minute of real time, with the gains being worse the heavier the load >is on the system. [...] >Moving the mouse causes the load average >to shoot over 15 (which is probably wrong since the clock is screwed), [...] Well, I don't know about anyone else, but I've been running SR10.3 on my DN2500 (16MB, 200M disk) for about three weeks with very few problems. The system clock is fairly stable (it loses about 8 seconds a day), and X windows works fine. We have seen problems similar to those described by Mike. The most reproducible way to provoke this behaviour is as follows: Someone logged in on a node other than the 2500 starts compiling a big file in a directory which is on the 2500. Once every minute or so, the load jumps sky high, and the clock jumps forward by a couple minutes. Meanwhile, the poor guy who is trying to use the 2500 screen is stuck, unable to do a thing. We "solved" the problem by moving everybody's home directory away from the node, after which the problem is still present but not nearly so noticable. (The guy we hired to take care of our computers was supposed to follow up on this, but he quit before Christmas and apparently never got around to it, which means I will have to do it (sigh)). Anyway, some clock racing was still present, but after we installed xntpd on all our machines the 2500's xntpd has managed to keep the clock in line, more or less. The advice to not install sr10.3 on a 2500 before the patch is out is probably a good one, although Kens experience implies that not all machines will be bitten by this bug. That could explain why neither HP nor the beta testers ever saw it. - Harald Hanche-Olsen Division of Mathematical Sciences The Norwegian Institute of Technology N-7034 Trondheim, NORWAY