From owner-freebsd-hackers Sun Apr 23 1: 6: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from corinth.bossig.com (mail.dohboys.com [208.26.253.10]) by hub.freebsd.org (Postfix) with ESMTP id 277F337B595 for ; Sun, 23 Apr 2000 01:06:02 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.242.92]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Sun, 23 Apr 2000 01:10:14 -0700 Message-ID: <3902AEE3.C4E64476@3-cities.com> Date: Sun, 23 Apr 2000 01:05:55 -0700 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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