HP3000-L Archives

April 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
Date:
Tue, 17 Apr 2001 11:29:24 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (69 lines)
Satish Metha answers Tony Luna's question about being advised by a newsletter
to upgrade his 1.5GB machines to 3.75GB before moving to 6.5 with the
following:

> Tony: I have upgraded 959KS-100 when we had 512 MB of memory and did not
>  have any problem with upgrading process.  Since then we have added
>  additional 512 Mb (not because o/s requirement but because we added a
>  substantial number of virtual terminals)

Satish's answer is the truth, not the newsletter's.

It *is* recommended that if you're only running 64MB in your HP3000 that you
upgrade to at 128MB before you move to 6.5, but that is only because the OS
has grown in size -- as all operating systems do over time -- to a size that
leaves an insufficient amount of user space in RAM when only 64MB is present.
With 6.5 on a 64MB machine, the system is going to spend too much time
performing disc swaps to keep a relatively small number of users
characteristic of 64MB machines memory resident.

Otherwise, if you already have 1.5GB of memory, and everything is working
well now, you're probably not going to see any difference at all.

The standard recommendation regarding memory has become: "How much can you
afford?", but there's a certain amount of misinformation in that advice.
Additional units of memory make an extraordinary difference in performance if
your machine is truly memory-limited (no user can stay resident for very long
and you're suffering an enormous number of page faults). In these
circumstances, a little bit of money will go a very long ways in improving
your overall system performance.

But once a performance plateau is reached, in that every user is
memory-resident for the duration of his launched processes, and page faults
are brought down to virtually zero, adding more memory only enriches the
memory vendor, not you. You're simply spending money for no benefit. Indeed,
if you overdo this process of adding memory correctly, users that signed off
two Thursdays ago can still be memory resident now, two weeks later, simply
because that segment has not yet felt any pressure to be overwritten by a
more current process.

Although it is only theoretical on my part, in the sense that I've never
actually measured the phenomenon, the shape of the performance curve vs.
memory size must look something like a very sharp rise initially that fairly
rapidly breaks over onto a plateau. That plateau is that long extended flat
part of the curve where you can continue to add memory and see virtually no
performance increase at all. At this point, you're just wasting money.

However, the process very likely even gets worse as you continue to add
memory. There is most likely is a point where continuing to add memory starts
you on a gradual downslope, in the sense that adding more memory will
actually slightly decrease performance. As the memory sizes grow to very
large sizes, so must the accompanying memory manager tables. Almost
certainly, the time to search these tables has to grow (but perhaps only very
slightly) as excess real memory increases.

In any circumstance, that newsletter -- which I also get -- irritates me
every time I see it. It is unusual for an HP3000 vendor to so blatantly
misrepresent the facts or so purposefully create confusion as does this
particular vendor.

I mentioned yesterday that Hermes was the patron god of vendors. He was also
the god of eloquence, commerce and theft. No one alive today knows or
remembers Mr. Hermes first name, but his initials are known for certain. They
were: B.S.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2