System performance degrades over time ONLY with 800 MHz FSB

I'm involved in performance testing of different CPU/motherboard
combinations.

On our previous 533 MHz FSB (3.2GHZ Dual) system, process times were
stable (roughly 30 sec per). After upgrading to the 800 MHz 3.2 Dual,
the first execution takes as little as 22 sec, but each following
execution increases by 0.5-1 sec until it seems to stabilize at 35
sec.

This behavior happens with HT both enabled and disabled; this behavior
only happens on the 800 MHz FSB.

Using .NET's System.Diagnostics.ProcessThread.UserProcessorTime/PrivilegedProcessorTime
APIs, I can see that the total time (user + privileged) has close to
doubled for all the threads in our application.

What aspect of the 800 MHz FSB could cause this behavior?

Thanks,
-ken

Perhaps you should start testing some Opteron and Athlon 64 systems instead.

Ken Durden wrote:

I'm involved in performance testing of different CPU/motherboard
combinations.

On our previous 533 MHz FSB (3.2GHZ Dual) system, process times were
stable (roughly 30 sec per). After upgrading to the 800 MHz 3.2 Dual,
the first execution takes as little as 22 sec, but each following
execution increases by 0.5-1 sec until it seems to stabilize at 35
sec.

This behavior happens with HT both enabled and disabled; this behavior
only happens on the 800 MHz FSB.

Using .NET's System.Diagnostics.ProcessThread.UserProcessorTime/PrivilegedProcessorTime
APIs, I can see that the total time (user + privileged) has close to
doubled for all the threads in our application.

What aspect of the 800 MHz FSB could cause this behavior?

Thanks,
-ken

"Ken Durden" wrote in message
om...
I'm involved in performance testing of different CPU/motherboard
combinations.

On our previous 533 MHz FSB (3.2GHZ Dual) system, process times were
stable (roughly 30 sec per). After upgrading to the 800 MHz 3.2 Dual,
the first execution takes as little as 22 sec, but each following
execution increases by 0.5-1 sec until it seems to stabilize at 35
sec.

This behavior happens with HT both enabled and disabled; this behavior
only happens on the 800 MHz FSB.

Using .NET's
System.Diagnostics.ProcessThread.UserProcessorTime/PrivilegedProcessorTime
APIs, I can see that the total time (user + privileged) has close to
doubled for all the threads in our application.

What aspect of the 800 MHz FSB could cause this behavior?

Thanks,
-ken

Are you checking if thermal throttling is gradually triggered? Do you
monitor
the CPU temperature in process of benchmarking?

- aap

JK wrote:
Perhaps you should start testing some Opteron and Athlon 64 systems instead.

It's amazing. I *KNEW* this thread would draw you out. I think I'm
psychic! :-P

--
My words are my own. They represent no other; they belong to no other.
Don't read anything into them or you may be required to compensate me
for violation of copyright. (I do not speak for my employer.)

Are you checking if thermal throttling is gradually triggered? Do you
monitor
the CPU temperature in process of benchmarking?

- aap

No, I'm not checking for this.
We're running Dual P4 Xeons, I didn't realize throttling was
implemented except on the laptop processors.

Any ideas on how to check for / disable this?

Thanks,
-ken

Ken Durden wrote:

What aspect of the 800 MHz FSB could cause this behavior?

When you upgraded, did you upgrade your RAM to match?

--
Mike Smith

JK wrote:

Perhaps you should start testing some Opteron and Athlon 64 systems instead.

*YAWN*

--
Mike Smith

What did Yousuf call him... a Jehovah's witness? LMAO! Pretty funny stuff.

Ken Durden wrote:
Are you checking if thermal throttling is gradually triggered? Do you
monitor
the CPU temperature in process of benchmarking?

- aap


No, I'm not checking for this.
We're running Dual P4 Xeons, I didn't realize throttling was
implemented except on the laptop processors.

Any ideas on how to check for / disable this?

Well use any of the thermal monitoring software or reboot and use the
BIOS if you must. But don't disable it unless you really dig putting in
new CPUs. There's a *reason* they added that feature!

--
bill davidsen )
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com

"Ken Durden" wrote in message
om...

Are you checking if thermal throttling is gradually triggered? Do you
monitor
the CPU temperature in process of benchmarking?

- aap

No, I'm not checking for this.
We're running Dual P4 Xeons, I didn't realize throttling was
implemented except on the laptop processors.

Any ideas on how to check for / disable this?

Thanks,
-ken

The throttling is implemented in all recent Pentium-4 class processors.
Yes, all new Xeons also have the TCC - Thermal Control Circuit, the
thermal throttling is a part of it. I am not entirely knowledgeable
with recent Intel offerings, but it seems that the "800MHz" models
are the only Xeon models with new co-called "90nm technology".

You also said you "upgraded" your system. This somewhat implies
that you reused the old heat sinks. If it is true, the thermal
interface must be damaged and likely results in higher thermal
impedance. Also, the new "800MHz system bus" Xeons have 10% higher
TDP, so all things combined may cause the case temperature to
raise too high, and the throttling develops, and your observations of
gradual performance decrease is clear indication of it.

The easiest way to make sure that throttling occurs is to monitor
one of processor's pins called "PROCHOT#"
using a scope - the signal will toggle when throttling starts.
I would guess that a truly high-RAS server system would have some
means to monitor this very important thermal protection feature,
but I might be mistaken.
You shouldn't attempt to disable the throttling - as people say,
there must be a reason for it. Some people believe that
the 90-nm leakage current will sharply increase with temperature
and cause a "thermal runaway" potentially damaging the processor.

One way to deal with throttling is to vastly increase the airflow
across the case of computer, and lower the ambient temperature.

- aap