Date: Mon, 26 Jun 2000 13:58:03 +0200 From: Brad Knowles <blk@skynet.be> To: Matt Heckaman <matt@ARPA.MAIL.NET> Cc: FreeBSD-STABLE <freebsd-stable@FreeBSD.ORG> Subject: Re: Compatibility Question Message-ID: <v0422080db57cf2ae8076@[195.238.1.121]> In-Reply-To: <Pine.BSF.4.21.0006260733330.2314-100000@epsilon.lucida.qc.ca> References: <Pine.BSF.4.21.0006260733330.2314-100000@epsilon.lucida.qc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:42 AM -0400 2000/6/26, Matt Heckaman wrote: > I don't know, 512M (2x256) of ECC RAM will cost me 2,200$ - that's an > awful nasty hit to be taking for what the server will do, which is a > generally nasty business called shell services. Ouch. That is quite a lot of money, but then a shell server is usually the sort of machine that gets pounded on the worst, and in the worst ways -- all sorts of bizarre things that users try, some of which are actively trying to break security and exceed their authorized level of access, others that are just curious about this new thing they just heard about, some who are just plain clueless, etc.... > In other words, there is > no single client paying thousands of dollars for web hosting of their > company's core page that will cost them (and me) a fortune for any > downtime :) Given this situation, I've a hard time justifying that cost, > which is only a few hundred dollars less then the *entire* machine is > going to cost me, especially for it's role :) You have to make that cost/benefit analysis for yourself, and it may well not be worth it for you. However, I'd encourage you to go look at the archive for -questions, and do a bit of research on how many times people have strange unexplained crashes, how often they claim it works just fine for them under Windows, and then try to figure out for yourself how many of these crashes are likely to be RAM-related. Myself, I'd put that number up pretty close to 100%. However, that's just my own personal opinion. Of course, once you figure out what percentage you'd give to that number, you then have to figure out what your "costs" are. There's your time debugging the problem, the amount of work lost by your customers multiplied by the number of customers and what their time is worth, the amount of money that you could have been bringing in that was otherwise wasted trying to fix the machine, the "cost" resulting from damage to your reputation, and the resulting loss of future business. I'm sure there's a lot of other hidden costs in there that I'm overlooking. I hope someone else will jump in here and help flesh out this list. Once you have a full list of all potential costs, you can then assign estimates to their values. Once you've done that, you can then compare that total cost to the cost of the ECC RAM, and you can figure out whether it really is worth it or not. Only you can make this decision. My experience is that it's usually not worth trying to go through and do a full cost/benefit analysis of having or not having ECC RAM. Instead, I err on the side of caution, and I specify ECC RAM everywhere, perhaps in some cases where it isn't strictly necessary. However, we do tend to re-utilize machines around here quite a lot, and although for one particular purpose ECC may not be a strict requirement, for another it might. It's better for us to not have to worry about whether or not a machine has ECC RAM, should we have an emergency that requires that we get a new machine up and running as quickly as possible. But your shop may be entirely different. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, <blk@skynet.be> || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0422080db57cf2ae8076>