|
Advice Beginners BIOS Guide CPUs Links Mainboards Memory Network Storage Video/Sound Cards Contact Forum SiteMap Sponsors WebNews Home |
. | . |
Prices: Mainboards ABIT ASUS Chaintech Shuttle Soyo Tyan CPU Intel P4 2.4C-800 P4 2.6C-800 P4 2.8C-800 P4 3.0-800 P4 3.2-800 AMD AthlonXP XP 1700+ XP 2000+ XP 2400+ XP 2500+ XP 2700+ XP 3000+ XP 3200+ Athlon64 Athlon64 3200+ Athlon64 FX-51 Opteron Opteron 240 Opteron 242 Opteron 244 Opteron 246 Memory Corsair Crucial Kingston Mushkin OCZ |
LOSTCIRCUITS
|
|
| Intel Pentium4 Prescott / 925XE chipset New Dimensions in Performance | |
|
(Review by MS November 21, 2004) |
| Intel P4 560+ At: |
The Poodle's Core
If we look back at the data, there are several facts:
One thing we noticed was that the upper portion of the mainboard had some very high heat output. In view of the thermal characterisics of the Prescott, this is not further surprising, however, heat is not merely confined to the CPU itself but affects / is generated by other components as well. Our first approach was to mount a fan blowing onto the NorthBridge with the result that the inflated memory scores were delayed, the same held for the gaming scores.
The 925XE datasheet states:
"The MCH supports a memory thermal management scheme to selectively manage reads and/or writes. Memory thermal management can be triggered either by on-die thermal sensor, or by preset limits. Management limits are determined by weighted sum of various commands that are scheduled on the memory interface."
and futher:
"MCH Thermal Sensor Event for SMI/SCI/SERR: This bit indicates that a MCH Thermal Sensor trip has occurred and an SMI, SCI or SERR has been generated. The status bit is set only if a message is sent based on Thermal event enables in Error command, SMI command, and SCI command registers. A trip point can generatge one of SMI, SCI or SERR interrupts (two or more per event is illegal). Multiple trip points can generate the same interrupt, if software chooses this mode, subsequent trips may be lost. If this bit is already set, an interrupt message will not be sent on a new thermal sensor event."
Even though these statements in their vagary do not allow a conclusive assessment of the situation, they indicate that READs and WRITEs are handled differently, moreover, only one bit is to be set to trigger thermal throttling in the memory controller -- which is the opposite of what we witnessed.
The only explanation that makes sense is that the system believes it is running slower, that is, the reference clock signal is slowed down, while all other system frequencies are a priori unaffected. Most benchmarks poll the system clock through a reference signal that is generated during boot-up and CANNOT query the real time clock while the system is running. There are obvious reasons for that, including the lack of accuracy if such an attempt was made. This reference signal is output by the clock generator IC. The same system is used to calibrate the FRAPS timer and to trigger the saving events. Therefore, if the signal is slowed down by a factor of 5, FRAPS, like any other frame counter will save the data points only every 5 seconds (instead of the defined 1 sec interval) which results in only 1/5 of the total data points compared to standard conditions and, moreover to an e.g. 5 x inflated score..

Left to right: The clock generator is located next to the AGP slot -- Close-up of the ICS 954123BF used on the ASUS P5AD2-E -- We used Arctic Silver Arctic Alumina thermal adhesive to attach a small heatsink.
Simply attaching our home-made heatsink to the ICS clock generator caused the system to almost behave normally. We then proceeded to chill the heatsink with liquid N2, so we are confident about claiming an operating temperature of at least -100 centigrades and our benchmark results were basically stable.
|
Intel P4 Northwood 2.4 (hard to find) |
In summary, it appears that the inflated benchmark results are primarily caused by overheating of the clock generator. With respect to the non-linearity shown for the last Everest run, most likely that one was caused by a progressive slowing down of the output clock while the benchmark was actually running. In other words, the data transfers are computed against runtime but the clock value shown is either at the beginning or at the end of the benchmark.
next page: => More Benchmarks, Conclusions =>
All advice and educational articles on LostCircuits are free, but if you feel you can, please make a small donation to us!