stokes@udiego.UUCP (David M. Stokes) (11/11/87)
I've just got the word that we'll have the $$$ to upgrade our
90x to a 9805. Now I have to start preping for the upgrade
(hopefully in January) and was wondering what sort of problems
others have encountered in 90x upgrades.
Any major problems?
How long did the physical installation take?
Operational differences in the 9805 compared to the 90x?
Thankx
--
David Stokes "USD where the future is tomorrow
Academic Computing Department and today is slightly behind schedule"
University of San Diego
(619) 260-4810 or {sdcsvax, sdsu, ucsdhub}!udiego!stokesbrian@prism.UUCP (11/14/87)
We have a 9820 and a 98x in house right now -- here is "the tale of two
upgrades" as well as I can remember it...
1) we started out with a 90x and a 98x. To get a 9820, we were going to
get rid of the 90, and upgrade everything to OSx4.0 (we were running 3.1).
2) The software upgrade to OSx4.0 revealed the following:
NFS was broken for a while, probably because of other problems.
portmap was broken for a LONG while -- it would just die for no reason.
After 4 (or was it 5?) PTF's, we had a system that stayed up for longer
than minutes.
the select() call for sockets was broken, and caused kernel crashes.
It has since been fixed. The behavior of flock() when used with LOCK_EX
or'd with LOCK_SH is different from that of Berkeley unix.
bc is broken (and still is) -- try e(1), e(0), e(2)....
3) I spent a 70 hour week, and a 93 hour week doing the upgrade. It was only
supposed to take 4 hours. The pyramid FE (software) in NE was diligent
enough to survive some of the all-nighters required.
4) We had some flakey hardware as well. We've been through a couple of
I-Units, a cache or two, and IOP/TPE controllers. Our IOP/TPE still
crashes occasionally. The maximum uptime so far has been about 5 days.
Our IOP (root disk controller) crashes enough to irritate, but not
enough to call service.
Beware "kernel mode page faults". I think some of the berk socket machinery
still needs oil... (also, another site had some complaints about the x.25
support...).
I'd like to hear from others who have done the upgrade as well, and if there
have been problems like these.
----
Brian K. Moran -- brian@mirror.TMC.COM
UUCP : {mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!brian
ARPA : brian@mgm.mit.edu
TryThis: brian@mirror.zone1.com
(we forward for .zone1.com)
Mirror Systems 2067 Massachusetts Avenue Cambridge, MA, 02140
Telephone: 617-661-0777 extension 122
"17.82 percent of all statistics are made up on the spot."
---hidley%baldar@SDCSVAX.UCSD.EDU (Greg Hidley) (11/14/87)
I have nothing but horror stories about our attempts to upgrade 3 of UCSD's 90X machines to the latest Operating System. Pyramid was little help in this and everything that could go wrong did. All things considered, I wouldn't even think of upgrading my hardware or getting another Pyramid again ... ever. greg Greg Hidley CSE Department C-014 University of California, San Diego La Jolla, CA. 92093 (619) 534-6170 decvax\ hidley@sdcsvax.ucsd.edu ihnp4 >---> sdcsvax ---> hidley ucbvax/ hidley@sdcsvax.uucp
scarter@caip.rutgers.edu (Stephen M. Carter) (11/15/87)
In article <516@udiego.UUCP> stokes@udiego.UUCP (David M. Stokes) writes: >I've just got the word that we'll have the $$$ to upgrade our >90x to a 9805. Now I have to start preping for the upgrade >(hopefully in January) and was wondering what sort of problems >others have encountered in 90x upgrades. > We went from a 90x to a 9810 in about 24 hours. I don't recall any major problems and the hardware was easy as Pyramid shipped in a whole new box and just moved the disks, memory, and tape over. Also, the software changes were well planned and plenty of heavy-duty unix gurus were around for the actual work.
hartzell@boulder.Colorado.EDU (George Hartzell) (11/15/87)
In article <516@udiego.UUCP> stokes@udiego.UUCP (David M. Stokes) writes: > Any major problems? I have been reading about people's upgrade experiences with the 90x and thought that I would add mine. We have a rather old 90x (still has some wire wrap) with xbif, not cache, and an "old style" cabinet. The most difficult part of any upgrade, from 2.5 -> 3.1 -> 4.0 was that fact that 2 of the tapes in the 4.0 upgrade had there labels switched. It took me a little while to figure out what the problem was when a read that was supposed to take 30+ minutes took 5, and the 5 minute read took forever. Other than that, it went smoothly. I should say though that this was not necessarily the case with other machines on campus; they had problems with revision levels on several of their boards. Also, we are having a problem in which our middle bank of ports hangs, seemingly at random. We have replaced the itp, with no effect. I am wondering if something in the 4.0 release is screwing things up. g. George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{hao,nbires}!boulder!hartzell
dennisg@pwcs.StPaul.GOV (Dennis Grittner) (11/16/87)
In article <4395@caip.rutgers.edu> scarter@caip.rutgers.edu (Stephen M. Carter) writes: >In article <516@udiego.UUCP> stokes@udiego.UUCP (David M. Stokes) writes: >>I've just got the word that we'll have the $$$ to upgrade our >>90x to a 9805. Now I have to start preping for the upgrade >>(hopefully in January) and was wondering what sort of problems >>others have encountered in 90x upgrades. >> > >We went from a 90x to a 9810 in about 24 hours. I don't recall any major >problems and the hardware was easy as Pyramid shipped in a whole new box >and just moved the disks, memory, and tape over. We didn't actually upgrade from a 90x to a 98(1,2,3,4)0, we went from a 90x to a 98xe. The whole thing went pretty smooth. It was done in a few hours. I think the entire time we were out of productionn ( we did it on a weekend so the time wasn't as important ) was less than an 8 hour day. Obviously, you can have a lot more trouble than this. Then, for 'some silly accounting/budget/political reasons' here we had to temporarily go back to a 90x for a month or so and we had all kinds of problems with reliability, etc. The only BAD software upgrade was the FAMOUS 3.1(?) upgrade where damned near everything was 'wrong', undocumented, etc - my exaggeration. Some of us on PUG ( Pyramid User Group ) complaimed to Pyramid a lot and the 4 release was a heck of a lot better. My experience with DEC was a lot worse - I remember a 'b' patch that crashed our system and they didn't fix that one till 'j' which was released two months later. I've never had a PTF cause that kind of problem with Pyramid. I think that you should go ahead and do your upgrade. In general the Pyramid folk have been pretty good. I think 3.1 was an experience for everybody at Pyramid that they learned from. -- Dennis Grittner City of Saint Paul, Minnesota (612) 298-4402 Room 700, 25 W. 4th St. 55102 "Let's just put Ollie, Ronnie, and the rest in jail!"
hedrick@athos.rutgers.edu (Charles Hedrick) (11/16/87)
My overall comment about upgrades is that any major change in a system (any system, not just Pyramids) is a possible source of problems, but that with proper planning things can usually be made to work with minimal hassle. My impression from some of the notes here is that some of the problems have been caused by trying to do too much at once. In particular, I'd avoid doing a hardware upgrade at the same time as a major OS change. I think my inclination would be to get the software up to date first. It should be possible to run the identical kernel on your old and new systems, if it is configured to include all the devices that are present on both. I believe this is even true for a change from a single processor to a multiprocessor system. I haven't tried this recently, but I believe you just get warning messages at startup. Of course running the wrong kernel is inefficient, but it is still useful as a debugging tool. (Running a multi-processor kernel on a single-processor system wastes a few percent of the CPU doing semaphore instructions that your configuration doesn't need.) Major OS changes have been nightmares on our VMS systems also. In general Pyramid upgrades have been no worse than VMS or Sun. Obviously things are much worse if you are badly out of date. As for the reliability you can expect, 3.1 was sort of a low point for Pyramid. The most reliable release we saw until recently was 2.4. It was not released, and 3.0 was rushed out the door order to get the first multi-processor systems (90Mx) working. 3.1 was also rushed. By 4.0 things had started to recover. The later PTF levels of 4.0 are quite reasonable. (The actual 4.0 release had some serious network problems, so we found it unusable.) I believe 4.1 is going to be at least as good as 2.4. Once you get your software up to date, then you can do the hardware upgrade. Most of the major upgrades might as well be buying a new machine, so you should expect that there is going to be a problem or two. Not necessarily, but any big machine has enough parts that trouble is a possibility. This means not doing it during the time when you are doing your final monthly payroll run, and at a time when Pyramid field service is likely to be available for the next couple of days to clean up any problems. This all may sound like too much bother, but if you don't do periodic upgrades, it's about as bad. I mean, you can't run 2.1 forever. If you want until 6.0 is out because you are afraid of upgrades, you'll have a much bigger problem than if you keep up with the software as it is released (or soon thereafter - there is something to be said for not putting up a new Pyramid release until there has been time for the first few PTF's, though I hope that this will not be true of 6.1). Similarly with the hardware. You don't want to be the first person to get a new model, unless you like being a pioneer, but falling behind -- with any vendor -- has penalties that are at least as great, in both performance and maintainability.