Subject: Re: Stupid Chip Q
To: None <port-i386@NetBSD.ORG>
From: Wolfgang Rupprecht <wolfgang@wsrcc.com>
List: port-i386
Date: 03/17/2001 12:26:25
> Let's see, my machine at work is a P2/450 with 256MB.  My machine at home
> is a P3/666 with 128MB.
...
> "I think it's got something to do with the difference between Ultra/33 and
> Ultra/100." :-)

;-)

I'm seeing a roughly linear speed increase with clock-rate on large
builds.  My old machine was a 333Mhz P-II and the one that replaced it
is a 1.1GHz T-bird.  The trick in getting a linear speed increase in
builds is judicious use of the "-j" flag in make.  One has to have
enough work queued up so that during a disk-i/o stall the cpu can
switch to a different ready to run parallel make.  The current
defaults of "-j2" seem to queue enough work up. The idle time in top
indicates only a few percent of CPU wasted here and there.

Another data point.  My mp3 lame encodes have been running for a full
cpu-week on the P-II now. (90 gigs of WAV files take a while to crunch
through.)  It should take another 2-3 days to complete the crunching.
Using the default grip settings the P-II-333 can crank out mp3's at
0.6x of real-time.  Using the same settings the T-bird-1100 can crank
out mp3's at 2.4x real time.  So yes, at times higher clock rate does
sometimes help, but usually it just heats the house.

Now if the cdrom/ide subsystem of Asus A7V was reliable I could run
grip on the faster machine.  Alas, it isn't and I can only rip 3 or 4
tracks before the cdrom driver hangs (requiring a reboot).  This is
the same physical cdrom that worked flawlessly when mated with Intel
motherboards.

-wolfgang
-- 
       Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
		    http://www.wsrcc.com/wolfgang/
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/