| Subject: Re: The annoying way that BOINC "throttles".. |
| From: Jan Knutar |
| Date: 19/11/2007, 09:06 |
~misfit~ wrote:
SETI BOINC seems to throttle on time. For instance, I've got my
preferences set to 75% of both CPU cores. It seems that it works on
quarter-second (or similar) chunks of time, 75% being 100% load for 3/4 of
a second, then 0% load for the other 1/4, resulting in 75% average over
the whole second.
There's actually no other way to make a CPU hog consume X% of CPU other than
to sleep for a certain amount of time and then work again for a certain
amount of time. Having 1s switching time sounds a bit coarse to me though,
especially since it leaves enough time for the power saving features of the
CPU to try adjust.
thermal cycling isn't doing my CPU any favours either. Why can't these
code-monkeys write code that simply uses 75% of the CPU constantly and
smoothly rather than just switching between 100% and 0% load?
Everything that runs on the CPU essentially runs at 100% when it runs. A
word processor will occupy the cpu 100% for blinking the cursor. It's just
that the amount of time it spends on the CPU to turn the cursor off or on
is so small, so that in order for any measurement program to see it as 100%
it would have to have an update rate of a few hundred thousand times per
second...
A media player playing your favourite mp3 goes to sleep and asks the OS to
wake it up when there's room in the sound buffer again. The OS gets
notified through an interrupt by the sound chip when it has played a buffer
fragment. The OS wakes up the media player, which will consume 100% CPU
until it has decoded more sound and filled up the sound buffer again. This
probably takes less than a millisecond though. It might also not have had
enough of the mp3 in memory, in which case it will have asked the OS to
give it more data from the harddrive. The player is forced to sleep again,
until the IDE/Sata/USB/etc controller fires an interrupt telling the OS
that the data it requested is now available, the OS wakes up the player
again and feeds it the requested data, and the player consumes 100% CPU
until it does something again which makes it sleep. CPU usage is simply an
average of how much time is spent sleeping and how much time is spent
running.
You might ask why the programmers didn't choose to switch between working
and not working more frequently? There's a compromise, the quarter second
boinc isn't doing anything, the CPU can spend in a reduced power state. If
boinc was switching 100 times per second, which would probably be fast
enough to make all sorts of measurement and monitoring programs show a
"constant" 75%, then CPU would use more power since it would only have
about 25ms at a time to spend in a lower power state. Transitioning between
the different power states takes time and power too, so the power saved
would be less.
If you want the cycle to be much shorter than 100ms you'd have to request
the OS to use a faster timer interrupt, which also increases power
consumption.
I guess it's up for debate whether the slower switching causes more thermal
stress on the computer compared to faster switching... The best solution,
as was suggested later in this thread, is probably to let it run 100%
daytime and switch it off for the night, if the cooling of the computer at
all can handle full load.. :)