: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
I don't know what your setup is, Kent, but when I do a buildworld
my system is 95% cpu bound, with virtual no idle time at all. It's
all going to the buildworld. On both 3.x and 4.x.
Try mounting /usr/obj with softupdates turned on, and if your /tmp
is not a softupdates partition then make sure you are building with
-pipe in /etc/make.conf:
(For 3.x)
CFLAGS= -O2 -pipe
(For 4.x)
CFLAGS= -Os -pipe
: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
Seti does almost no I/O, which means that in general it will have
a much lower scheduling priority then even a cpu-bound buildworld.
Most people run seti niced to +20, which means that it does not run
at all if there are other 'normal' processes using the cpu. Under 3.x
this was broken - seti got cpu when it shouldn't have. Under 4.x this
is fixed. If you run a cpu-bound process niced to +20 it will get
very little cpu in the face of other unniced cpu-bound processing.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
