[EMAIL PROTECTED] wrote:
On Fri, Aug 29, 2008 at 11:58:18AM -0700, David Brown spake thusly:
Building the kernel is by far the best memory test I've ever found.
This is a very good point. At MP3.com the kickstart install would download
the kernel source that the machine was intended to run, compile that
source and install the source it compiled. No pre-compiled kernel rpm's.
Because we also found that running a kernel compile is the best way to
stress test a box before putting it into production.
A kernel compile may not test all memory in a system, depending upon how
much memory the system has. What it will do is use extra resources that
memtest does not. You could say that a kernel compile is a *limited*
system test. A kernel compile will use the disk subsystem (including
DMA), video subsystem to a small extent (more if you use the X GUI to
configure the kernel), possibly the CD/DVD-ROM, all CPUs present will be
running at full bore, and some portion of memory will be used. All these
extra resources use power and make the system do a lot of extra work. As
a result, a power supply that can't cut the mustard may cause the system
to glitch, balk, and maybe outright fail. A kernel compile will not max
out a video subsystem though, which in a multi-SLI system can suck a ton
of power and use the bus (and chipset)like mad.
A memory test on the other hand (including memtest) does not use all
these extra resources. It certainly doesn't use the CPUs to the extent a
kernel compile will and there's no large files, etc. to be transfered
from disk (if there are any at all). It will test *all* memory, even if
the system has a TB of it (which is way more that a kernel compile will
use).
The ideal test would exercise all subsystems while running a memory
test. Lacking such a thing, the best compromise would be running memtest
over night (the extended, full test) and following it up with a kernel
compile (or running some other system intensive application/process). On
a system that has high-end video, running a high-end 3D game or
simulation would be the test.
Finally, there will be a difference between 800 and 667 in a system such
as mine that is used for high-end games. Memory bandwidth in such a case
is very important and the bottleneck when disk access is not involved is
always memory bandwidth (especially when you have 64-bit multiple cores
fighting for the same system memory).
Think of it this way. the bandwidth for DDR2 is double the rated speed.
So, 800x2 = 1600MHz and 667x2 = 1334MHz (it's really 1332MHz). That's a
268MHz difference or about 15% slower, which can be a reduction in frame
rate of the same, which could be very noticeable.
PGA
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting
http://www.randomlogic.com
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
