On Wed, 18 Dec 2002 00:23:55 -0600 seebs@plethora.net (Peter Seebach) wrote:

> In message <20021218153216.285b9425.ggm@apnic.net>, George Michaelson
> writes:
> >Peter Seebach points out he has a 2.4Gz 640Mb system which is dog slow
> >doing CVS. With that much memory/CPU bandwidth, there should be no problem.
> >No?
> 
> Just 2.0Ghz.  Not 2.4.
 
my bad.

> 
> But it's an IDE drive, see...

me too. atactl says:

# atactl /dev/wd0 identify
Model: IC25N010ATDA04-0, Rev: DACOA70A, Serial #:          170171J6499
Device type: ATA, fixed
Cylinders: 16383, heads: 16, sec/track: 63, total sectors: 19640880
Device capabilities:
        IORDY operation
        IORDY disabling
Device supports following standards:
ATA-2 ATA-3 ATA-4 
Command set support:
        NOP command
        READ BUFFER command
        WRITE BUFFER command
        Host Protected Area feature set
        look-ahead
        write cache
        Power Management feature set
        Security Mode feature set
        SMART feature set
        Advanced Power Management feature set
Command sets/features enabled:
        look-ahead
        write cache
        Advanced Power Management feature set

> 
> Note that I'm doing CVS over a "mere" 640Kbps link, so there's no chance
> of saturation.  This machine can scp files back and forth from scratch space
> all day without *any* measurable performance hit.  Perhaps more
> interestingly, I can run make build and be pretty well off.  On the other
> hand, nightly dumps get me 10 second cycle time on refreshing a Mozilla
> window.
> 

Make is doing cc -pipe, it will be using tmp backed on swap? so its memory
intensive and the softupdates write-back will be in the background mostly.

Make forks lots of sub-processes. Maybe they carve up the job better innately
by virtue of the jobmix and the disk i/o mix interacting 'better' 

> What's the resource used by CVS and dump, but not by scp, make build, or
> number crunching?  I think it's moving heads on the disk.

dump only forks one or two sub-tasks. cvs is all-in-one isn't it? tar
likewise.

Me too now thinks its the IDE. But mediated by something via the file buffer
cache, and the sequence of calls cvs and dump and tar calls. is it too many
sync() calls? I've read stuff in linux lists talking about re-writes on the
disk I/O to move on from the 'elevator' scheduling, but surely the BSD family
is much more consistent in how it does IDE? Why would FreeBSD be 'better' at
this?

Oh, for a SCSI enabled laptop...

-George