From owner-freebsd-isp Wed Mar 19 21: 9:59 2003 Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C08F37B401 for ; Wed, 19 Mar 2003 21:09:57 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADC5743FA3 for ; Wed, 19 Mar 2003 21:09:54 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 18vqoW-0001jS-00; Wed, 19 Mar 2003 19:33:56 -0800 Date: Wed, 19 Mar 2003 19:33:55 -0800 (PST) From: Tom Samplonius To: Ryan Watson Cc: freebsd-isp@freebsd.org Subject: Re: Maximum recommended user limits on mail server In-Reply-To: <008c01c2ee51$2f8c22f0$d70d10ac@summitoh.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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