KUBUNTU v8.04-BETA --- excruciating slowdown
6 Apr 2008 7:38:00 UTC
Topic 193616
(moderation:
On April 2 I "upgraded" a machine to KUBUNTU v8.04-BETA, and the cpu seconds for a typical WU using app version 4.38 doubled; from around ~23,000 to ~50,000 cpu-seconds. The machine in question is ID 972111, and if you can see its history you can see the step-wise increase in cpu-seconds around April 2.
In fact I stopped two jobs running, did the "upgrade", and got things going again, and you can see from the "slots/*/*.txt" files that the heartbeat checkpoints begin to occur after only every two sky-points, instead of every four or sometimes after every three.
Here is one of the tasks in progress when the change occurred:
Something about KUBUNTU v8.04, at least in the BETA flavor, seems amiss, at least as far as this project is concerned.
I will "back-grade" to KUBUNTU v7.10 ASAP.
.
KUBUNTU v8.04-BETA --- excruciating slowdown
)
We had this question at SETI a while back.
Turned out that the CPU was running at a slow, energy-saving speed, because the version of Linux in question thought that low-priority tasks weren't worth waking the CPU up to full speed for.
Hang in there, and I'll find the reference.
Edit - best answer in a long discussion is this one by Toby
He suggests using
cat /proc/cpuinfoand looking for the line that starts with "cpu MHz" to check that it matches what you paid for: andsudo cpufreq-selector -g performanceto get it back to full speed.see if "kerry beagle" is
)
see if "kerry beagle" is running by default after the new install. I've seen reports of it taking up much of the cpu %.
RE: see if "kerry beagle"
)
Indeed, this one is a real CPU waster when all you want to do is BOINC :-(. But Beagle would not have such a drastic affect on CPU time per WU, only on "wall clock time per WU.
I think the CPU frequency problem might be the solution, but note that WU runtime can vary quite a bit, although usually not as much as you reported.
I've seen a similar problem on Pentium-M with Dothan core, where the Dynamic CPU frequency switching kernel module was indentifying the CPU as running on 1.5GHz max, but infact it was a 2GHz model.
CU
Bikeman
RE: Edit - best answer in
)
OK - I just set up a new machine using Kubuntu v 8.04 release candidate; I looked at the cpuinfo and saw that the bogomips was way low, around 2,000 or so; and so I ran the "cpufreq-selector" command as shown. This brought my bogomips up to what I expected - about 5600 - and so I'm happy. I don't have a clue why the latest version of Kubuntu seems to want the CPU to run slow.
I am trying to figure out a good place amongst the init scripts to run the "cpufreq-selector" command.
Thanks to all who responded.
RE: RE: Edit - best
)
Actually, if you don't want to mess with an init script, you could go into your BIOS setup and disable Cool n' Quiet. (Or, SpeedStep, if you're talking about Intel machines.)
RE: RE: RE: Edit -
)
As a note, if the machine is an AMD quad-core, Cool & Quit must be left on (it defaults to 1/2 speed otherwise. In that case, I had to use the Performance Option for cpuspeed.
CPUInfo in Ubuntu is funny
)
CPUInfo in Ubuntu is funny anyway. It keeps saying my CPU is clocked at 2000 MHz- problem is, it is a 1600 MHz CPU and who on earth would overclock a laptop? I certainly didn't. But still, my OS seems to think so... 7.04 did it, 7.10 does it, and so did the 8.10 Live CD I tried. No problem for BOINC but I sometimes wonder if it messes up my power saving somehow...
Since the CPU is really quite common (Core Duo "Yonah") it might be related to my laptop having an ATI chipset which maybe messes up results...
Hi Richard, thanks a lot
)
Hi Richard,
thanks a lot for the information! Tomorrow I'll try the commands right away on 2 Ubuntu 8.04 boxes which I recently got access to.
Actually I came here to search for information if the Linux client was really that slow, though I already suspected soemthing was wrong with the hardware or software setup. The Matlab benchmark ran fine on these machines but my actual script ran only half as fast as under windows. It seemed a bit strange that hand optimized assembler code and Matlab would both run so slow under Linux..
I understand this behaviour is not a bug. But has been expressed to the K/Ubuntu guys that this is rather unwanted behaviour and shines a bad light on Linux (in case unexperienced people don't figure the reason/solution out). The power states should be determined by CPU load, not by priority.
Regards,
MrS
Scanning for our furry friends since Jan 2002
RE: CPUInfo in Ubuntu is
)
What does running 'cat /proc/cpuinfo' show? A simple way of finding the actual clock speed is to take the "bogomips" value and divide by two. I've often found that with power-saving capable machines the "CPU MHZ" lies.
Hello everyone, although
)
Hello everyone,
although this thread has been quiet for a while, I'd like to add that the behaviour you saw is not a bug, but a feature. Let me give the rationale and a better way to get BOINC to run at full speed than the hacks posted above.
Under Linux and similar OSs, each process has a priority that determines how the kernel scheduler distributes computation time. For example, when you build a webserver, you don't want your daily maintenance routine to slow down Apache; hence, you can assign it a lower priority than the Apache processes. Because of this behaviour, the priority value is generally referred to as a process' niceness. "Nice" processes yield their CPU time to not-so-nice ones. The niceness is a numerical value ranging from 19 (very nice) to -20 (not nice at all; highest priority).
Because BOINC is meant to run on desktop machines while the user is working, it usually runs with lowest priority, alongside some system daemons. Everything else is more important. Because "down there", there are usually no programs whose execution speed is important, most CPU frequency governors don't clock the CPU up when such a "nice'd" program has a lot of work to do. This saves energy and keeps users from having their CPU fans go on and off every time their scheduled background jobs come on.
So, if you're running a dedicated BOINC machine, the simplest and best method to get BOINC running at full CPU speed is simply to set its priority to 0 (right in the middle, where normal applications are) and you will observe that the CPU gets clocked up. The other methods suggested in this thread aim at disabling CPU frequency scaling altogther, which only makes sense on a machine that you know will never run idle any more.