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:[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
