Originally posted by: Pauli
Ah, this conversation reminds me of the good old days of RAM during the 386 and 486 days. About the time that EDO RAM was introduced, almost all PC memory sold was 9 bits per byte - 8 for the data and 1 for parity. Alas, RAM was very expensive in those days (what, about $30 a MB or so?), and memory and MB manufacturers were able to ever so slightly lower the cost of PC RAM by eliminating the parity bit.
Even worse, they faked it, with a logic chip on the board instead of an extra RAM chip. (This was probably done, because many of the OEM boards of the day couldn't even run without parity memory. Early Gateway systems come to mind.)
Originally posted by: Pauli
I'm not sure how this all transpired, but ever since that time, standard PC Memory is still pretty much sold without parity bits. ECC memory, a more robust hardware error detection technology, was available in those days, but was so much more expensive that it never was really a factor in the consumer market. I don't know, is ECC memory even available in SDRAM or DDRAM or even RDRAM?
Yes, ECC (and parity) is still available, and is more prevalent than parity for DIMMs (well, actually, it comes out about the same technically for 64/72-bit memory buses). I ONLY use ECC memory in my current systems. No-way would I go without that sort of protection. I've read about so many problems that came about from faulty RAM. It's not like ECC is some magical fix, but if your memory is failing, there is a much greater chance to find out about it.
Originally posted by: Pauli
In any case, this is the reason why POSTs are not able to detect memory errors. PC Memory today simply does not have any error detection technology built into it. It's really a shame because memory is so cheap these days it would add almost nothing to the cost.
For the most part, POST memory "testing" is really just a count. It is a throwback to the original IBM-PC, which laboriously counted every little KB of memory upon bootup. (I have a clone TurboXT box with EPROMs with a real IBM-PC BIOS in it, so I know. It even has the BASIC built into ROM too.)
From my experience, the memory test that HIMEM.SYS does, in DOS 6.22 and above, with the /TESTMEM
😱N switch, actually does catch most flakey memory. I've managed to find bad memory with that, within a few boot-ups, that Norton's NDIAG.EXE "comprehensive memory testing" failed to find after HOURS of leaving it running. I think the difference is, NDIAG.EXE only does read/write pattern testing, whereas HIMEM.SYS might actually do cache-line-fill code fetches from the memory. The behavour of the memory subsystem can show differently depending on whether the accesses are for code or data, believe it or not.
Another good way (also a good way to find out if your CPU cache and memory subsystem is stressed from overclocking), is to start SMARTDRV.EXE with a large cache size, and then do looping PKUNZIP.EXE tests on several large .ZIP files (but small enough to fit into the smartdrv cache). The asm code in PKUNZIP.EXE is pretty damn tight, and can really stress memory subsystems. (They even have a command-line switch to use a "slower" code-path, because of that reason, for usability on poor hardware, amazingly enough.)
