From owner-freebsd-ports  Wed Jun  2  9:32:13 1999
Delivered-To: freebsd-ports@freebsd.org
Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162])
	by hub.freebsd.org (Postfix) with SMTP id 4441E15284
	for <freebsd-ports@FreeBSD.ORG>; Wed,  2 Jun 1999 09:32:09 -0700 (PDT)
	(envelope-from sthaug@nethelp.no)
Received: (qmail 49498 invoked by uid 1001); 2 Jun 1999 16:32:08 +0000 (GMT)
To: eivind@FreeBSD.ORG
Cc: jkh@zippy.cdrom.com, dscheidt@enteract.com,
	freebsd-ports@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject: Re: a two-level port system? (fwd)
From: sthaug@nethelp.no
In-Reply-To: Your message of "Wed, 2 Jun 1999 17:35:28 +0200"
References: <19990602173528.B70808@bitbox.follo.net>
X-Mailer: Mew version 1.05+ on Emacs 19.34.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Wed, 02 Jun 1999 18:32:07 +0200
Message-ID: <49496.928341127@verdi.nethelp.no>
Sender: owner-freebsd-ports@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> > I still don't see what the fuss is about in any case since soft
> > updates would be SLOWER than the async mode I use during installation
> > and anyone who's actually bothered to benchmark extraction of files
> > with the two systems knows this.  Have you ever timed it?  If not, why
> > not?  That seems the minimum amount of work one would be expected to
> > put in before arguing passionately on any topic. :-)
> 
> Because benchmarking something that is synchronously creating inodes
> all over the disk in a rotating fashion (due to the directory
> allocation policy) against something that is running fully async and
> with an elevator sort over the full set of transactions should be sort
> of useless.  It's like doing uphill testing of a fat guy on a bicycle
> against a Lamborghini - you "know" the result beforehand.
> 
> If extraction of the ports collection (not files in general, just the
> ports collection) is slower using soft updates than using "async"
> mode, then it seems some elevator sorting isn't working the way it
> should, or we are getting queue stalls due to a limited queue size
> somewhere.

OK, here's a practical result. PII-350 running 3.2-STABLE, extracting
the ports from 3.2-19990526-STABLE.tgz. The disk is a Barracuda 9 LP
(ST39173W) on an Adaptec 7890 controller. The file system was newfs'ed
(8 kbytes/inode) before each extraction.

Softupdates:
# time tar xzf /local/ports-3.2-19990526-STABLE.tgz
6.274u 38.703s 11:09.90 6.7% 283+1045k 1100+112517io 0pf+0w

Async:
# time tar xzf /local/ports-3.2-19990526-STABLE.tgz
6.311u 69.739s 12:06.17 10.4% 283+1027k 1378+118407io 0pf+0w

Not a huge difference, but enough to be noticeable.

Watching with vmstat while the extraction was running, you could clearly
see more disk operations per second for softupdates.

As always, YMMV.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no


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