Performance DECREASE after CPU/memory upgrade

[Willem Grooters]

My dear collegues,

I consider this weird.
My (old ;)) Digital PWS500au had 256 Mb memory and (as the name suggests) a 500Mhz CPU. I run a CPU-intensive application on it that takes about 8 hours to complete. A lot of other processes are loaded as well and a number of them (Decnet and (inactive) TCPIP) are in HIBO or LEFO state - which doesn't really matter.
Well, I doubled memory and installed a faster (600Mhz) CPU, and changed CPU-clock accordingly. No problem for SRM, it signals the CPU speed is 600Mhz and the system has 512Mb memory, nor a problem for VMS: I have no HIBO or LEFO processes left (good).
However: the CPU-intensive process now takes about 10,5 hours to complete - runs about 25% SLOWER where I would expect a gain of about 15% (be a bit pessimistic....)

Can anyone explain this and give me some idea what to do (I _should_ run autogen???)

[Martin P.J. Zinser]

Hello Willem,

running AUTOGEN is certainly a first step.
It might be interesting to actually look at the report from AUTOGEN to see where it wants to change parameters.
Else you might want to check if the CPU is actually maxed out when you run your job or if there is still "free" CPU left.

[Mike Naime]

If you did not run Autogen after adding the additional memory, your OS and Apps may not really be aware that it is all there to be used.

Whenever you change your hardware platform, you MUST run autogen to allow the system to make necessary changes to allow for that additional hardware to really be used.

If you want to see the changes that it makes save your old parameters, and do a diff between the old and new parameters.

EX:
$ Copy alphavmssys.par Alphavmssys.old
$ mcr sysgen
use current
set /output .old
show/all
show/spec
exit
(*) make edits to modparams.dat
$ @sys$update:autogen getdata setparams nofeedback
$ mcr sysgen
use current
set /output .new
show/all
show/spec
exit
$diff/par/match=1/width=80/out=x.dif .old .new
$ type x.dif
verify that the edits in modparams took hold and are correct, note other changes
and verify they look ok as well.

When you are happy, Reboot the box!

[Martin P.J. Zinser]

Assuming your system has been up long enough
under load, you can also use autogen with savparams and feedback

[Willem Grooters]

Thanks to all - I'll run autogen anyway.
Someone else gave me a hint it could be caused by the hardware, e.g. because the memory isn't responsive enough: processor speed 600Mhz but memory would fit up to 433, for instance, which would cause an overall decrease of memery access - even if memory that _can_ handle this speed is accessed.
Anyone an idea about this?

[Antoniov.]

Hi Willen,
AUTOGEN can help you because some system parameters (that have value for 256 Mb and 500MHz CPU) don't work correctly with new hardware.
For example (but it's only a example)PAGEDYN could be set for 256 Mb and limit use of Dynamic Pool. If System need increase pool can overalloc new heap but system performance can down. Similar is NPAGEDYN and so on.
AUTOGEN solve theese problems.
Bye.

[Martin P.J. Zinser]

Hello Willem,

there is nothing in the old SOC that points in the direction of non-matching main memory. For all PWS from the 433au to the 600au the MSP01-C,D,E,F are listed as supported memory modules.

Greetings, Martin

[Willem Grooters]

I've done autogen (saveparams setparams) and rebooted (well - cycled power, due to some hardware problems I cannot reboot ;-().
Overall, it seems a bit better but the CPU-intensive program still is considerably slower than before the upgrade.
Could it be that due to extended memory, more processes are kept in memory - using at least some CPU time from time to time? (Although I don't believe this ought to lead to a decreament of 25%).

Any other ideas are welcomed...

[Martin P.J. Zinser]

Hello Willem,

to get a first overview how your system uses the memory and if there still might be idle CPU have a look at

http://www.decus.de:8080/www/vms/sw/perf_meter.htmlx


to check if your compile process is maybe running out of quota the following tool might be useful

http://www.decus.de:8080/www/vms/sw/show_quota.htmlx

Greetings, Martin

[Antoniov.]

Hi Willen,
can you post
a)Before change, other use can work when CPU intensive proc. was running? And now?
b)Can you increase priority process?
If you set prio=16, you set process as real-time so it goes out from round robin; setting prio=16 maybe dangerous because other process could go to stall and you must ready to decrease prio less then 16.

Martin's suggestion it's a safer good idea!

Bye,
Antoniov