KUBUNTU v8.04-BETA --- excruciating slowdown

Jim Howe
Jim Howe
Joined: 25 Mar 05
Posts: 18
Credit: 11707416
RAC: 0
Topic 193616

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.

.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2143
Credit: 2950130402
RAC: 690279

KUBUNTU v8.04-BETA --- excruciating slowdown

Quote:

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.


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/cpuinfo and looking for the line that starts with "cpu MHz" to check that it matches what you paid for: and

sudo cpufreq-selector -g performance to get it back to full speed.

Astro
Astro
Joined: 18 Jan 05
Posts: 257
Credit: 1000560
RAC: 0

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 %.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 713018113
RAC: 892002

RE: see if "kerry beagle"

Message 80612 in response to message 80611

Quote:
see if "kerry beagle" is running by default after the new install. I've seen reports of it taking up much of the cpu %.

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

Jim Howe
Jim Howe
Joined: 25 Mar 05
Posts: 18
Credit: 11707416
RAC: 0

RE: Edit - best answer in

Message 80613 in response to message 80610

Quote:

Edit - best answer in a long discussion is this one by Toby

He suggests using

cat /proc/cpuinfo and looking for the line that starts with "cpu MHz" to check that it matches what you paid for: and

sudo cpufreq-selector -g performance to get it back to full speed.

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.

Donald A. Tevault
Donald A. Tevault
Joined: 17 Feb 06
Posts: 439
Credit: 73516529
RAC: 0

RE: RE: Edit - best

Message 80614 in response to message 80613

Quote:
Quote:

Edit - best answer in a long discussion is this one by Toby

He suggests using

cat /proc/cpuinfo and looking for the line that starts with "cpu MHz" to check that it matches what you paid for: and

sudo cpufreq-selector -g performance to get it back to full speed.

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.

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.)

ohiomike
ohiomike
Joined: 4 Nov 06
Posts: 80
Credit: 6453639
RAC: 0

RE: RE: RE: Edit -

Message 80615 in response to message 80614

Quote:
Quote:
Quote:

Edit - best answer in a long discussion is this one by Toby

He suggests using

cat /proc/cpuinfo and looking for the line that starts with "cpu MHz" to check that it matches what you paid for: and

sudo cpufreq-selector -g performance to get it back to full speed.

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.

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.)


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.


Annika
Annika
Joined: 8 Aug 06
Posts: 720
Credit: 494410
RAC: 0

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...

ExtraTerrestrial Apes
ExtraTerrestria...
Joined: 10 Nov 04
Posts: 770
Credit: 576046900
RAC: 184189

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

Zxian
Zxian
Joined: 23 Oct 06
Posts: 40
Credit: 5121474
RAC: 0

RE: CPUInfo in Ubuntu is

Message 80618 in response to message 80616

Quote:
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...


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.

jstarek
jstarek
Joined: 21 Jan 08
Posts: 3
Credit: 2646415
RAC: 0

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.