*BSD News Article 87502


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!uunet!in1.uu.net!204.71.1.48!newsfeed.internetmci.com!chatta.samart.co.th!news
From: Ruediger Koch <rkoch@samart.co.th>
Newsgroups: comp.os.linux.networking,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc,comp.sys.sun.misc
Subject: Re: Sparc vs. x86 speed (was Re: Linux vs BSD)
Date: Mon, 27 Jan 1997 15:13:19 +0700
Organization: Samart
Lines: 69
Message-ID: <32EC639F.3D354CF3@samart.co.th>
References: <32DFFEAB.7704@usa.net> <5c155c$p6u@raven.eva.net>
		<5c19pg$rf6@lynx.dac.neu.edu>
		<5c58n9$hcb@innocence.interface-business.de>
		<32E66DE1.7E36AB48@samart.co.th> <5c8b0o$313$1@capsicum.wsrcc.com> <JASON.97Jan23151639@daffodil.cs.odu.edu>
NNTP-Posting-Host: ares.samart.co.th
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.18 i586)
CC: austin@visi.net
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:66213 comp.unix.bsd.bsdi.misc:5738 comp.unix.bsd.misc:2034 comp.sys.sun.misc:28094

Jason C Austin wrote:
> 
> 
>         But what was the end user performance?  Did you compare your
> mail volume per hour before and after the change?  A low load average
> usually means you're not getting things to the CPU fast enough to keep
> it busy.  I've found "PC" type systems tend to have too much CPU for
> the rest of the machine, since it looks good on an advertisement.  All
> you end up with is a hurry up and wait situation which gives you a low
> load average.

I don't think that our users ceased sending and receiving mail just
because we changed our mailserver. We get about 50 new users per week
and the mail volume is increasing more than proportional to that :-)
> 
>         A load average of 1-2 on a 1 CPU machine is just about where
> you want it to be.  If it's not, you probably have an I/O bottleneck
> of some sort.

That's probably one of the greatest nonsense I've ever heard. Reduced
load means that I have an I/O problem?! After our change, the response
time of the server if you do 

bash$ telnet yum 25

is a nothing. Before the change it took 1-3 seconds on a 100 MB
ethernet! The same is true for POP3. Don't tell me something's wrong
with nameserver, the routing or tcp wrapper settings. They're all the
same. So much about I/O performance. Doing something like:

bash$ ls -l /home > ./homedirs

with 6000 userdirs in /home took minutes!

Actually, I don't think that this has too much to do with the Sparc
hardware, but with it's OS, Solaris. I think I mentioned that we
replaced Solaris by Linux on a couple of them, beeing very satisfied
with the results (Only one crash till now). I guess, switching to SunOS
would have lead to similar results. The Sun hardware is just a little
overprized.
> 
>         As I said before, CPU is not what makes a fast machine for
> most applications.  If your application is almost all CPU with low

Sounds like a weak CPU makes a good database server?! Always this I/O
argument! This depends on your peripherals, of course. You can't compare
a Pentium or PPro with 8MB, an ISA 10MBit ethernet card and a slow IDE
drive with a $15,000 Sun. That is, however, what is usually done.
Compare a $15,000 PC with a $15,000 Sun! 

> I/O, you probably will be better off with the Pentium machine.  If
> you're doing database type applications (much more common), the Sun
> will leave it in the dust.  You need to get the right machine for the
> job.

Exactly. That why I stopped using Solaris and started to use Linux and
FreeBSD on production servers (after I used it for a while as my
personal box). We do not have any demanding database apps; for mail, PCs
running FreeBSD or Linux are simply better. 

I don't know if solaris is stable when running Oracle, but I do know
that it is not as a mailserver with more than 1000 mails per hour. I've
heard of poeple having trouble with 2000 mails per hour on an enterprise
6000.

If anyone ever made serious benchmarks and comparisons - they're greatly
welcome.

R"udiger