🚀 go-pugleaf

Hi,
to my experience, their is another considerable source of problems ->
memory.  Large (>64MB), hispeed memory gives you a considerable risk of
bit errors, specially if memory is driven rather hot. Parity will only
catch One-Bit errors, all other can be seen only be ECC. Some memory
assemblies have no checking at all for a cheaper price. Memory testing
will not show these errors at all, because they occur only randomly. The
typical symptoms are:

- non-reproducable traps
- corrupted files after copying them (!) even if the CRCs of the source
where OK .

My advice:
- parity checked memory is a must,
- run memory stress tests at least before installing new SW,
- use boards and memory with ECC if ever possible if you use more than
128MB. The payback period is very short.

Regards
Uwe

---------------------------
"Victor Bien delete nspam. to reply" wrote:

>   A few weeks ago I asked this group whether for me any FP > 9 were
> any good.  One observation made by Jim L <lifedata@xxvol.com> in the
> discussion was that some hardware responds badly to certain FPs.
> While this may be true I am now wondering whether some problems that
> people, including I, have encounterd are due to slightly corrupt
> downloads or at least slightly corrupt files?  These downloads may not
> only be done by oneself but by a colleague and passed on via CD-ROM.
>
>   The reason for my suspicion is that, for example, the XR_M010.ddk
> obtained by CD-ROM unpacked with "no errors" by DIUNPACK nevertheless
> did not produce a CMD.EX_ file.  When Service & Fservice ran it fell
> over when it could not install this file.  I had to break off and
> download a fresh copy of FP10 from Hobbes and after doing another
> DIUNPACK on the fresh XR_M010.ddk would the application of service
> complete.  (Incidentally FP10 applied OK and so far it looks good.  So
> I've been able to move on from FP9!  I intend to observe the system
> under use for while and move onto the following FPs one step at a time
> hoping to reach FP14 with its new kernel!).
>
>   Another example of a faulty download appeared in a 3MB installation
> file for the Windows environment.  This fell over when I tried to run
> it.  I downloaded another copy and everything went fine.  The
> interesting thing was that the byte count of the two copies were
> exactly the same.  However, running COMP on the files showed more than
> 10 bytes different when COMP exited saying there were too many
> differences!
>
>   We are in a period of maximum sunspot activity perhaps with more
> incident cosmic rays capable of flipping bits.  The above mentioned
> Windows file installed OK when first downloaded a couple of weeks ago.
> So maybe the download was OK and then became "faulty".  There are no
> viruses on this OS/2 machine and in any case there are very few
> viruses against OS/2 anyway.
>
>   So I'm wondering whether IBM could supply a CRC list with a tool to
> check the diskimage files CRC against?
>
> Victor Bien
> VCB Computing Alternatives (R)
> http://sydney.dialix.com.au/~vcbien/