Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Dec 1998 12:06:55 +0000
From:      Karl Pielorz <kpielorz@tdx.co.uk>
To:        "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc:        current@FreeBSD.ORG
Subject:   Re: Also seeing IRQ oddness with -current now.
Message-ID:  <367A455F.2D9C0ED4@tdx.co.uk>
References:  <31115.913981805@zippy.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help


"Jordan K. Hubbard" wrote:
> 
> > My SuperMicro P6DNF has done this since the first time I ran SMP -current on
> > it... I vaguely remember talking to someone about it - I'm sure they said it
> 
> OK, well, let me ask you another question then:
> 
> Going from a single to dual CPU configuration, did you see any change
> in your "worldstone" times?  Before I added a second CPU to my PII/450
> tonite (and started seeing those messages as a consequence of added
> SMP support), I carefully timed a `make -j4 world' running off a
> single 9GB Cheetah with soft updates enabled for all file systems.

I don't see much difference - you tend to get more of a difference with a
higher '-j' factor ;-) I tend to use anything from 8 to 16 (higher the number,
bigger the gain, bigger the chance of a foulup with makeworld)...
 
> With one CPU, it's 1:05.  With two CPUs, it's 1:01.  This either
> proves that I'm seriously I/O bound or that multiple CPUs aren't
> helping the compile times for some weird reason. :-)
> 
> None of the other benchmarks I've found (GENERICstone, rc5,
> calculating pi :-) seem to be affected by single-vs-dual CPU, but this
> doesn't particularly surprise me either.  The fact that rc5crack
> claims to use multiple CPUs doesn't necessarily make it so and none of
> the others are designed to benefit from SMP at all.

If I run rc5 twice on the same machine - appart from things getting a bit
'choppy' - it does appear to crack keys roughly twice as fast... Maybe if you
run things like 'pi' twice? And see if the aggregate throughput is better than
it 'should' be (i.e. both instances don't sink down to half the throughput)...
 
> Hmmmm.  As usual, we come down to the fact that we really don't have
> any decent benchmarks for measuring the effectiveness of SMP.  I've
> asked the folks who sell SMP Linux systems at VA Research about this
> and they've also confessed to not really having any decent ways of
> actually testing Linux's effectiveness for SMP.  Looks like we can at
> least claim parity with Linux as far as that one is concerned. :-)

True... :)

I've noticed since I've gone SMP - I can 'get away' with higher load averages
on the machine, I've quite often managed to push this up to around 30-40 - and
it's still been nice and responsive... I have a lot of drives in the box (i.e.
seperates for root, usr, usr obj, web server, home dirs etc.) - I think this
helps...

Other winners seem to be things like Apache (i.e. lots of processes) - mind
you until we lose the 'big lock' on the Kernel anything that's kernel bound
(i.e. probably I/O bound, 'system' bound whatever) is not going to show much
improvement...

-Kp

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?367A455F.2D9C0ED4>