[152161] in North American Network Operators' Group
RE: Most energy efficient (home) setup
daemon@ATHENA.MIT.EDU (Jamie Bowden)
Mon Apr 16 08:10:18 2012
From: Jamie Bowden <jamie@photon.com>
To: "'Joe Greco'" <jgreco@ns.sol.net>, "Luke S. Crawford" <lsc@prgmr.com>
Date: Mon, 16 Apr 2012 12:08:25 +0000
In-Reply-To: <201204160215.q3G2FTJZ075724@aurora.sol.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> From: Joe Greco [mailto:jgreco@ns.sol.net]
> I'd have to say that that's been the experience here as well, ECC is
> great, yes, but it just doesn't seem to be something that is
> "absolutely
> vital" on an ongoing basis, as some of the other posters here have
> implied, to correct the constant bit errors that are(n't) showing up.
>=20
> Maybe I'll get bored one of these days and find some devtools to stick
> on one of the Macs.
In all the years I've been playing with high end hardware, the best sample =
machine I have is an SGI Origin 200 that I had in production for over ten y=
ears, with the only downtime during that time being once to add more memory=
, once to replace a failed drive, once to move the rack and the occasional =
OS upgrade (I tended to skip a 6.5.x release or two between updates, and af=
ter 6.5.30 there were of course no more). That machine was down less than =
24 hours cumulative for that entire period. In that ten year span, I saw T=
WO ECC parity errors (both single bit correctable). On any machine that sa=
w regular ECC errors it was a sign of failing hardware (usually, but not ne=
cessarily the memory, there are other parts in there that have to carry tha=
t data too).
As much as I prefer ECC, it's not a show stopper for me if it's not there.
Jamie
