[cpu/frequency_governors] test seems to fail frequently

Bug #931775 reported by Jeff Lane 
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Checkbox Provider - Base
Won't Fix
Medium
Unassigned

Bug Description

I've noticed while doing certification reviews that the test cpu/frequency_governors tends to fail fairly regularly. It's not 100% but the percentage is high enough that it's essentially ignored during Ubuntu Friendly testing and certification testing. We need to either fix this test to not fail so easily or remove it from any required testing regime.

I'm more in favor of refactoring the fail criteria myself. I have a feeling that what causes the test to fail can change depending on several factors, such as current system load, the type and model processor, variations in how the kernel handles throttling, etc. A one-size-fits-all kind of test is obviously not working so well.

One solution would be to raise the thresholds to only fail in egregious cases where a governor doesn't work (maybe set the threshold to 30% instead of the current 10%).

Second, the output could be fixed to be a little more useful. For example, in the test that fails, the test outputs this:

Error: measured speedup vs expected speedup is 19.5% and is not within 10.0% margin.

What does that even mean? Does that mean that what we saw was actually 19.5% faster? or that what we expected was 19.5% faster than what we saw? and 19.5% of what? Just looking at the output, I really only know that the test failed during the userspace governor test.

Here's an example from the test where it failed:

pid 2518's current affinity list: 0-3
pid 2518's new affinity list: 0
System Capabilites:
-------------------------------------------------
System has 4 cpus
Supported CPU Frequencies: 2501 MHz 2500 MHz 2200 MHz 2000 MHz 1800 MHz 1600 MHz 1400 MHz 1200 MHz 1000 MHz 800 MHz
Supported Governors: conservative ondemand userspace powersave performance
Current governors:
cpu0: userspace
cpu1: userspace
cpu2: userspace
cpu3: userspace
Userspace Governor Test:
-------------------------------------------------
Setting governor to userspace
Setting CPU frequency to 800 MHz
Running CPU load test...
pid 2518's current affinity list: 0
pid 2518's new affinity list: 0
Minimum frequency load test time: 34.95
Setting CPU frequency to 2501 MHz
Running CPU load test...
Maximum frequency load test time: 8.61
Note: found ida flag, increasing expected speedup by 8.0%
CPU Frequency Speed Up: 3.40
Measured Speed Up: 4.06
Percentage Difference 19.5%
Error: measured speedup vs expected speedup is 19.5% and is not within 10.0% margin.
On Demand Governor Test:
-------------------------------------------------
Setting governor to ondemand
Waiting 5 seconds...
pid 2518's current affinity list: 0
pid 2518's new affinity list: 0
done.
Running CPU load test...
On Demand load test time: 8.61
Percentage Difference vs. maximum frequency: 0.0%
Waiting 5 seconds...
pid 2518's current affinity list: 0
pid 2518's new affinity list: 0 done.
Performance Governor Test:
-------------------------------------------------
Setting governor to performance
Running CPU load test...
Performance load test time: 8.61
Percentage Difference vs. maximum frequency: 0.0%
Conservative Governor Test:
-------------------------------------------------
Setting governor to conservative
Waiting 10 seconds...
pid 2518's current affinity list: 0
pid 2518's new affinity list: 0
done.
Running CPU load test...
Conservative load test time: 34.63
Percentage Difference vs. minimum frequency: 0.9%
Restoring original governor to userspace

Revision history for this message
Jeff Lane  (bladernr) wrote :

Confirming and setting to medium.

Changed in checkbox:
status: New → Confirmed
importance: Undecided → Medium
summary: - [cpu/frequency_governors] test seems to fail farily frequently
+ [cpu/frequency_governors] test seems to fail frequently
Daniel Manrique (roadmr)
tags: added: scripts
tags: added: ce-qa-concern
Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

This failure is getting to be quite pervasive, so I'll have a look at it.

Changed in checkbox:
status: Confirmed → In Progress
assignee: nobody → Brendan Donegan (brendan-donegan)
Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

At least on my own system, the application 'cpufreq-selector' completely fails to set the CPU frequency to the maximum value allowed - if this is a hardware bug then it at least partially explains why this test might fail. What's not good is that even though it can't set the speed, that's not the reason for the test failure. At the very least the test should be failing if the frequency can't be set when in 'userspace' mode.

Revision history for this message
Zygmunt Krynicki (zyga) wrote : Re: [Bug 931775] Re: [cpu/frequency_governors] test seems to fail frequently

One of those apps requires you to dpkg-reconfigure something as it needs to
poke stuff as root and it was unsafe to do so. If you want to check if you
have a hardware bug (very unlikely) just switch governor / frequency
manually in sysfs

On Tue, Jun 18, 2013 at 2:47 PM, Brendan Donegan <
<email address hidden>> wrote:

> At least on my own system, the application 'cpufreq-selector' completely
> fails to set the CPU frequency to the maximum value allowed - if this is
> a hardware bug then it at least partially explains why this test might
> fail. What's not good is that even though it can't set the speed, that's
> not the reason for the test failure. At the very least the test should
> be failing if the frequency can't be set when in 'userspace' mode.
>
> --
> You received this bug notification because you are a member of Checkbox
> Bug Wranglers, which is subscribed to checkbox.
> https://bugs.launchpad.net/bugs/931775
>
> Title:
> [cpu/frequency_governors] test seems to fail frequently
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/checkbox/+bug/931775/+subscriptions
>

Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

Colin King confirmed my suspicion that this is a hardware bug, so at the very least I need to fix the test so that it clearly fails if the userspace governor doesn't work at all.

Ara Pulido (ara)
Changed in checkbox:
assignee: Brendan Donegan (brendan-donegan) → nobody
status: In Progress → Confirmed
Revision history for this message
Rod Smith (rodsmith) wrote :

I'd just like to "bump" this, since I'm doing testing for checkbox/plainbox for trusty, and I've noticed the same thing. I've completed tests on three physical computers and one virtual machine so far today, and they've ALL failed on this test. All of these computers have run Linux successfully, some of them for years. (They're all x86-64 laptop or desktop systems, FWIW.) I can provide additional checkbox output if necessary.

Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

Hi Rod,

The problem with this bug (and the reason it never gets fixed) is because there are a number of reasons this test can fail. Could you open a new bug giving the details for the failure on just one system, and we'll take it from there.

Thanks!

Zygmunt Krynicki (zyga)
affects: checkbox → plainbox-provider-checkbox
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

I'm marking this as WONT FIX but please reopen if this is actively hampering anyone's work. My goal is to limit the number of open bugs to get a better idea as to what is really important.

Remember that you can always escalate bugs by contacting us in #checkbox on freenode (or #cert-infra in the internal IRC) or by responding in bugs directly.

Changed in plainbox-provider-checkbox:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.