Date: Wed, 19 Mar 2003 19:33:55 -0800 (PST) From: Tom Samplonius <tom@sdf.com> To: Ryan Watson <watsonr@gulliver.summitoh.net> Cc: freebsd-isp@freebsd.org Subject: Re: Maximum recommended user limits on mail server Message-ID: <Pine.BSF.4.05.10303191917110.26390-100000@misery.sdf.com> In-Reply-To: <008c01c2ee51$2f8c22f0$d70d10ac@summitoh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Mar 2003, Ryan Watson wrote: > > Nice to ask for references, but not provide any yourself... > > > > The fastest Ultrasparc II is not faster than the fastest Xeon. There > > are plenty of processor benchmarks online. Come one: a 3Ghz CISC > > processor vs. a 1Ghz RISC processor? There is just no way. > > > > 32bit vs. 64bit is not really relevent. When you compile an application > > on US, the compiler will generate 64bit code on a US, and 32bit code on a > > Xeon. Which will run faster? The Xeon. The US can probably execute a > > few more instructions per cycle, but has a lot more instructions to > > execute (compare the size of US binaries to x86 binaries) and fewer > > cycles. > > I'm quite glad you're not the admin here in our data center. There is a > huge difference between 32bit, and 64bit. Also, the US won't automatically > compile 64bit code. It's completely dependent on the compiler you're using. > Often you'll want to compile both 32bit binaries, and 64bit binaries. The > Xeon has a max addressable memory of 4Gigs (because it's 32bit). I'm You should probably look that up. Even the lowly Dell Poweredge 2650 has a 8GB memory limit. > certainly not saying that 10-15k mail users need a full fledged Sun box, > however if you intend to do any serious Oracle work, or serve an enterprise > you'd lose your job quickly if you set it all up with a Xeon. The US should > automatically do twice as much data as the Xeon during one clock cycle, > that's if everything else is even, however it's not. The Xeon is designed > for clock speed (really deep pipelines, but not many of them), the US is > designed for computational speed at the sacrifice of clock cycles (ie: > they're not trying to woo consumers) with lots of pipelines. Also, if you > put significant load on the Xeon it'll come crawling to a stop, whereas the > US will keep churning along. Even people in the Intel server business don't > take the Xeon seriously, that's why they go with the Itanium. Ask Intel > whether the Xeon or Itanium is faster, and I'll tell you already that thus > far an Itanium can't touch an US. If you just flip the meaning of everything above, it sounds right. * The Itanium has no signficant server market share. No one except HP is even comitted to Itanium. * Lots of enterprises use Xeon (or even just P3/P4) boxes becuase with n-tier apps, individual server performance is unimportant. Look at the statements from Google's CTO on processors. Brace yourself, their enterprise is definitely bigger than yours, and has no ultrasparcs. And look, they all have jobs! And look, Dell has just announced that "Unix (they mean Solaris) is dead", and they are moving their Oracle supply chain app to intel boxes. * 64 bit doesn't mean that you automatically go twice as fast. It simply means your registers are bigger, so certain operations are faster. x86 processors fetch data in 64bit or 128bit chunks already. * As far as Sparc goes, they're out of money. They keep talking about a Ultrasparc III processor (3i, I believe) that is supposed to be a "Xeon killer". A year later, and well... * Put significant load on a Xeon, and it comes crawling to a stop? What does this mean? Lots of context switches? A processor is always executing, so it has no real concept of a little or lot of load. > Ryan Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10303191917110.26390-100000>