Date: Thu, 18 Sep 1997 19:00:07 -0500 From: dkelly@hiwaay.net To: Michael Beckmann <beckmann@nacamar.net> Cc: hardware@FreeBSD.ORG Subject: Re: Parity trouble with Asus mainboard Message-ID: <199709190000.TAA20506@nospam.hiwaay.net> In-Reply-To: Message from Michael Beckmann <beckmann@nacamar.net> of "Thu, 18 Sep 1997 12:42:20 %2B0200." <3.0.3.32.19970918124220.00b51290@mail.nacamar.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Following up to myself. I got 8 x 32 MB with parity from a different vendor > today, and they work fine in the Asus mainboard with ECC on. So something > weird apparently is wrong with the other SIMMs, so that they are > incompatible with the Asus board. I used these other 8 x 32 MB in a busy > newsserver since 3 days now, with parity off, and there was no problem. The > same mainboard doesn't like these SIMMs with parity on. Maybe a timing > problem with the parity chips on the SIMMs. > > Thanks, > > Michael As somebody else mentioned there are quacks selling "logic parity" or "virtual parity" or other nonsense-named SIMMs with fake parity. Most real parity 72-pin SIMMs I've seen have 12 chips. Fake parity will have 9. If all your chips don't have the same part number then its likely you have fake parity. Fake parity is worse than none. It lets a vendor label memory x36 rather than x32. It lets questionable mom&pop PC shops to ship a box with parity enabled in the BIOS setup (sometimes) and suggest to the unkowning that the system is better than it really is. Fake parity SIMMs are slower than the marked speed because their logic has to calculate the faked parity bits and can't do that until after the memory read has happened. And if it so happens your MB calculates parity different than the SIMM, then you get the situation you just uncovered. ECC is likely to calculate the high 4 bits differently. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709190000.TAA20506>