On 16 Apr 2001, at 16:27, Ernst Mayer wrote:
> Fry's (a big local discount computer & electronics chain) has a great
> deal on build-it-yourself Athlons (US$ 350 for 1.2GHz CPU, MB, case,
> floppy, ethernet card, 56K modem & video card) so I'm going to take
> the plunge.
Does sound like a good bargain... Are you _sure_ this includes the
processor? Tip, buy the best heat sink you can find, even if you have
to throw away the one supplied. And install an extra case fan.
BTW there are now two variants of Athlon (Thunderbird) processor,
with 200 MHz (100 MHz DDR) or 266 MHz (133 MHz DDR) front-speed bus.
Since the multiplier is fixed, you want to make sure you have the
correct type for your motherboard. Some motherboards are switchable
for FSB, but, if you install a 266 MHz FSB CPU in a M/B running at
200 MHz FSB, the system will run at only 3/4 of its rated speed.
Which will slow it down to about the same speed as a PIII running at
the same rated speed.
The key is the last character of the part type stamped onto the die.
A 200 MHz FSB CPU ends with B whilst a 266 MHz FSB CPU ends with C.
Unfortunately you won't easily be able to read this if you have
bought a system with the heat sink already stuck onto the processor.
> The one question that remains is whether to buy ECC or
> non-ECC memory? Neither is terribly expensive (256MB of
> Athlon-compatible PC133 memory goes for $45 non-ECC, $90 ECC at
> pricewatch.com), but I don't want to pay extra unless I'm sure it will
> give some definite advantage. So the question is: does ECC memory of
> this kind actually do active error correction, or merely detection?
Actually there are several questions here...
Memory described as ECC should actively correct single-bit errors and
detect most multi-bit errors. If an uncorrected error is detected, it
should raise non-maskable interrupt, which (depending on the OS) will
probably cause a kernel panic (or BSOD on a Windows system).
If an error is detected and corrected, the memory should raise a
different interrupt, which the OS may ignore, or log somewhere.
My understanding is that the correction is actually done in the DIMM
itself, but depends on the appropriate signals being supplied by the
chipset.
The only experience I have of a corrected memory error on a PC-type
system was on a 486 running linux kernel 2.2.x (using old FPM SIMMS);
the error was logged in /var/log/messages & the system sailed happily
on for months afterwards.
Something similar should happen if you have the CPU cache ECC
enabled.
However, whether this works or not depends on the chipset as well as
the BIOS settings and the OS. Note that the VIA chipsets often
supplied on Athlon motherboards do NOT support ECC; if you install
ECC memory, it functions as non-parity memory.
I much prefer ECC memory, but there is absolutely _no_ point in
paying extra for ECC memory if the capability is non-functional due
to deficiencies in the chipset. However it is definitely worth paying
the small amount extra for faster memory (PC133 instead of PC100,
even if the memory bus is running at 100 MHz, or CL2 instead of CL3)
since this can and usually does significantly benefit system
performance - though some tuning of chipset memory timings through
BIOS may be necessary.
> If OTOH
> one only gains the ability to *detect* errors, is Mprime configured
> with this in mind, i.e. will it restart from the last savefile if a
> memory error is detected?
Not relevant - mprime will not be aware of a corrected memory error,
whilst a kernel panic will crash the system, so mprime have to
restart from the last savefile (once you've stood the system up
again!) Even if the system crashes whilst mprime is writing a
savefile you should be OK, since the savefile is renamed to something
mprime will look for only after the file has been written
successfully.
Even with full ECC capability, there _could_ still be an uncorrected,
undetected error - but this would have to be multi-bit, and therefore
rather rare. The chance of this happening without there being a high
rate of corrected errors must be rather small.
BTW if you're looking for a x86 linux distribution, I'd strongly
suggest you look at "Rawhide" which is the beta for RedHat 7.1. This
comes with an apparently functional & reasonably stable kernel
(v2.4.2 last time I looked); there are _major_ advantages in running
a v2.4 kernel on an x86 system (support for UDMA66 & UDMA100 disks,
built-in I2C support which is useful for CPU temperature sensing,
etc.). But the real point is that it's a lot easier to install
Rawhide from scratch than it is to do an install of RH 7.0 then
upgrade the kernel. I have little experience of distributions other
than RedHat, but I have little doubt that the same principles apply.
Regards
Brian Beesley
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
