Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!cdin-1!icdi10!fr From: fr@compu.com (Fred Rump from home) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: Memory Parity. Is It Really Needed Message-ID: <1991Apr7.172634.17432@compu.com> Date: 7 Apr 91 17:26:34 GMT References: <6040014@hpspkla.spk.hp.com> Organization: CompuData Inc. Lines: 28 town@hpspkla.spk.hp.com (Brian R. Town) writes: >Yes you lost important data, but only what you were working on at the time. I >would guess that the parity error kept your application from writing the >corrupt information to disk, didn't it?? The 'important data' that you were >saved from loosing is the data on the disk that the parity checking kept the >program from trashing. Just consider what shape any data files that your >program writes would have been in if you would have used the program for a few >days without knowing that there was a problem. Sorry to keep harping on this, but the original question came from a wyse 286 system user. In our experience those systems did not have parity checking. Therefore errors were silently being ignored while garbage was being written to disk. A parity checking hardware feature would have indicated exactly what Brian above indicates: that there is a memory problem. The wyse machines had only 8 chips in a row of memory. The ninth chip for parity checking (actually the ninth bit) was not there to ensure proper memory function. This was done to save a few bucks as memory was assumed to be reliable. This was normally the case with only 640KB but as several megabytes were added on additional memory cards, the chance of error grew dramatically. It simply made those machines not usable for multi-user functions. fred -- W. Fred Rump office: fred.COMPU.COM 26 Warren St. home: fred@icdi10.COMPU.COM Beverly, NJ. 08010 bang: ...{dsinc uunet}!cdin-1!icdi10!fred 609-386-6846 "Freude... Alle Menschen werden Brueder..." - The Ode