[comp.sys.pyramid] Upgrade to 5.0

mike@blia.BLI.COM (Mike Ubell) (10/13/89)

We have a bottom of the line 90x processor.  Our operations folks have
been told by RTOC that in order to upgrade to Os 5.0 we cannot have an
8Mhz processor and would need to upgrade to a 10Mhz processor. 
Does anyone know why an operating system cares how fast the processor
is running (or is the new OS such a dog that it needs the extra speed? :-)

csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/13/89)

>We have a bottom of the line 90x processor.  Our operations folks have
>been told by RTOC that in order to upgrade to Os 5.0 we cannot have an
>8Mhz processor and would need to upgrade to a 10Mhz processor. Does anyone
>know why an operating system cares how fast the processor is running?

OSx 5.0 includes significant changes both to the OS and the compilers. There
are instructions, instruction sequences, and memory utilization patterns that
have never been generated before. The worry is that the very oldest machines
(> 4 years) weren't subjected to the rigorous margining of the later systems,
and old stable machines have been known to suddenly "break" when handled
output from a new compiler. 

Note that the 10Mhz systems represented much more than an increase in clock
speed; many little changes were made that resulted in the whole system being
more tolerant as it aged. Hardware bugs were fixed, too.

We had quite a tussle over this. Some folks -- particularly former customers,
like me -- insisted that it was a bad thing to make customers upgrade old 90x
systems that worked perfectly well. And fact is, your old 90x *might* run OSx
5.0 without any problems. Might. But Field Engineering thinks it's a fair bet
that it won't, and they've got the experience to know.

A final problem: we have only one 90x systems left in R&D, and it's still on
OSx 4.4. This makes it tough for us to QA to software. :-(

Anyone know if Ultrix 3.0 is supported on a VAX 11/780? :-)

I heard something about an incentive program to make upgrades to the faster
systems reasonably priced. You'll have to talk to your salescritter. It's
well worth it, anyway. The difference between the 8MHz and 10MHz systems is
much more noticable than you'd think.

<csg>

scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) (10/13/89)

In article <9694@blia.BLI.COM> mike@blia.UUCP (Mike Ubell) writes:
>We have a bottom of the line 90x processor.  Our operations folks have
>been told by RTOC that in order to upgrade to Os 5.0 we cannot have an
>8Mhz processor and would need to upgrade to a 10Mhz processor. 
>Does anyone know why an operating system cares how fast the processor
>is running (or is the new OS such a dog that it needs the extra speed? :-)

The basic gist is correct - OSx 5.0 will not run on the 90x SP processor
set.  However, it's not that you need a fast (i.e., 10MHz) board set, but
that you have to upgrade to an AP processor.  Sounds like a garbled
communication problem to me.  The AP processor is 10MHz, though.  (I think.)

Regarding 5.0 being a dog - I don't think so, but it *is* probably a pig...
4.4 required a minimum of 8M of memory to run; I'm sure 5.0 will need at
least that much.
-- 
Scott Hazen Mueller| scott@zorch.SF-Bay.ORG (ames|pyramid|vsi1)!zorch!scott
685 Balfour Drive  | (408) 298-6213   |Mail to fusion-request@zorch.SF-Bay.ORG
San Jose, CA 95111 |No room for quote.|for sci.physics.fusion digests via email

csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/14/89)

In article <918@zorch.SF-Bay.ORG> scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) writes:
>However, it's not that you need a fast (i.e., 10MHz) board set, but that you
>have to upgrade to an AP processor.

No, he was right the first time. You need at least the 'F' version of the SP
processor. We still sell those brand new, y'know (the 9805). The AP is the
real 9800 series CPU, as in 9815, 9825, etc. The XP is the MIServer processor.

>Regarding 5.0 being a dog - I don't think so, but it *is* probably a pig...

Actually a little better than 4.4, because of the new VM. But yeah, you really
want at least 8MB main memory.

<csg>