Date: Tue, 18 Feb 1997 22:01:24 +1000 (EST) From: Stephen McKay <syssgm@devetir.qld.gov.au> To: asami@vader.cs.berkeley.edu (Satoshi Asami) Cc: freebsd-hardware@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: 64 MB ECC or 128 MB non ECC ? Message-ID: <199702181201.WAA12652@ogre.devetir.qld.gov.au>
next in thread | raw e-mail | index | archive | help
asami@vader.cs.berkeley.edu (Satoshi Asami) wrote: > * Well, I'm glad I've got some cache to enable since without cache the kernel > * compile takes 15 times as long. Yes, my ECC, nocache test took 97 minutes! > * Yikes! The final result is that ECC is 12% slower than PARITY with no cache. > * (user+sys time only). This is in agreement with those people who predicted > * 10-15% main memory slow down, but, as noted above, reduces to 1% with both > >Thanks for verifying it. I've found out something new that means that what I've "verified" might not be what you thought I was verifying. Intel's TXC documentation states that you have to reduce your read accesses to x333 if using ECC. (There is a one clock lead-off penalty too.) Since I'm already running my FPM at x333 there would be (next to) no penalty there. Only EDO users would suffer. Looks like the read-modify-write penalty (as mitigated by the TXC write reassembly buffers) was what I was really measuring. > * caches enabled. 1% is no pain at all. > >Well that depends, if you are X-user-switch-around-between-20-windows >type of guy, you can actually feel the 10% slowdown as you use the >machine. I switched back to parity because I couldn't stand it. ;) Hmm. I beat my machines until they beg for mercy. :-) I haven't run X on the new box yet as I'm still experimenting with weird stuff (like old SCSI disks that lock up the SCSI bus), and I can't afford a second good monitor. If I never run it for real without ECC, I'll never know what I'm missing. :-) Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702181201.WAA12652>