Messages in this thread | | | From | ketil@ii ... | Subject | Re: Building Big Ass Linux Machine, what are the limits? | Date | 28 Sep 1998 09:15:16 +0200 |
| |
Rik van Riel <H.H.vanRiel@phys.uu.nl> writes:
> With 150+ simultaneous users, you _will_ need some CPU power! > Go for a dual or quad CPU machine...
I'd suggest SMP too, since you're going to have a bit of interactive load. Your users are bound to run braindead software, and with a multi-CPU config, you can hope that some of the programs will only hose one of the CPUs.
PPro, while a good CPU is getting old, the Quad board costs $1000, and the PII is probably cheaper. You should be able to put together a dual PII at 350MHz for the price of the Quad board alone, it will be as fast, and have higher memory bandwidth etc for free.
> How about using RAID for more reliability? If you're using > the machine for really big work, I guess you can pay for > hardware RAID solutions with hot-swappable drives...
RAID mirroring is fast and reliable, but expensive, RAID striping with error correction, is cheaper in disk cost, but much slower writing.
(When will we see a mirrored volume acting as a cache for a larger stripe/ecc volume? HP does something like this, I think)
Last time the cache discussion was brought up - a long time ago, surely, it was concluded that controllers with cache was evil - or at best, a waste of money, and that that money was better spent on RAM, which is usually cheaper and faster, anyway. Has something changed?
> 2.0, almost; the 2.1/2.2 series is definately ready.
Wouldn't you want to run 2.2.x, where x is large enough that most bugs have been weeded out of 2.2.0? 2.1 is still labeled "experimental", and there's been enough troubles with the latest kernels that I'd wait a bit longer for an enterprise-critical system.
~kzm -- If I haven't seen further, it is by standing in the footprints of giants
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |