Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Apr 2000 01:05:55 -0700
From:      Kent Stewart <kstewart@3-cities.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Michael Bacarella <mbac@nyct.net>, Alfred Perlstein <bright@wintelcom.net>, Kevin Day <toasty@dragondata.com>, hackers@FreeBSD.ORG
Subject:   Re: Double buffered cp(1)
Message-ID:  <3902AEE3.C4E64476@3-cities.com>
References:  <Pine.BSF.4.21.0004221320250.38433-100000@bsd1.nyct.net> <200004221736.KAA55484@apollo.backplane.com> <3901F277.66DDDDAF@3-cities.com> <200004222317.QAA56834@apollo.backplane.com> <39026874.F652A405@3-cities.com> <200004230625.XAA58076@apollo.backplane.com>

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


Matthew Dillon wrote:
> 
> :You are right but that is because I haven't started keeping record on
> :4.0-Stable and we were comparing apples and oranges. A buildworld of
> :3.4-Stable required around 2000u seconds using gcc-2.8.2 on my system.
> :Setiathome, which is running at a nice of 19, still consumed 90% of
> :the cpu. A buildworld on 4.0-Stable required 3500u seconds using
> :gcc-2.95.2 and setiathome didn't accrue any appreciable cpu time
> :during the build. There were definitely some changes there :).
> :
> :Kent
> :
> :--
> :Kent Stewart
> :Richland, WA
> 
>     Both 3.4 and 4.0 buildworlds are cpu-bound.  If you are trying to test
>     buildworlds, then don't run setiathome (or anything else) while doing
>     the test... it will skew the results of your tests due to differences
>     between the 3.4 and 4.x schedulers (specifically, various scheduler
>     bugs were fixed in 4.x that effect niced cpu-bound background programs
>     such as setiathome, giving them way, way too much cpu).

The bugs were fixed in 4.0? What I saw was far too much cpu going to
setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities
because I have only noticed the really large increase in cpu time
required to build 4.0. The wall clock time on a buildworld hardly
changed (55-60 minutes) whether I ran seti or not on 3.4. I can watch
the wall clock time on some of my future builds and see how they are
skewed by stopping seti before I being the buildworld. I just haven't
got 4.0 to the capability I had with with 3.4 before I tried to
upgrade to 4.0 and it died in the middle of creating the
installkernel. The rest of the system was pretty much broken at that
point and I used the opportunity to restructure everything. It has
been a good check on some of the ports because I found a few that
assumed you have things like Bison, automake, and autoconf installed
and I didn't.

> 
>     It is simply impossible to fairly measure I/O performance in the
>     presence of unrelated background-running programs, especially under 3.x.
>     And even though 4.x does a better job of it, it will still skew the
>     results.

I was looking at this as more of a real world setup simulation. Seti
is almost pure cpu and the buildworld used everything else. I ran the
build world from an x-term and from the command line. That didn't seem
to matter much. The system also provided my dialup and nat'ing for my
internal network. Seti was run from a script that was started from an
<alt><F2> login before I did my startx. It would chug along from one
network problem at Berkeley until the next one with out any
intervention on my part. The system was on a UPS and didn't go down on
the occasional 1 or 2 second long power outages. Between the two
codes, they mimic most of the types of calculations I've been
associated with for many years. I have people that are using Windows
9x machines and I think they would be better off with something like
FreeBSD. The programs were developed in unix environment. A lot of
users are using Linux. Some are using PVM to combine systems into a
single parallel virtual calculation. Lehey Fortran-90(77) running on
Win9x with their protected mode interface setup has to be a terrible
choice. The problem is proving it and providing an alternative :). A
couple would run better on a scsi because of the queued read/write I/O
that you identified. You can say anything is a POS but people won't
listen unless you can show them a better way. I'm retired and no
longer have a contract manager to answer to and can experiment.

Cheers,

Kent

> 
>                                                 -Matt

-- 
Kent Stewart
Richland, WA

mailto:kstewart@3-cities.com
http://www.3-cities.com/~kstewart/index.html
FreeBSD News http://daily.daemonnews.org/

SETI(Search for Extraterrestrial Intelligence) @ HOME
http://setiathome.ssl.berkeley.edu/

Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR
http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3902AEE3.C4E64476>