[fedora-arm] BeagleBone Black CPU speed

Peter Robinson pbrobinson at gmail.com
Wed Jan 22 07:01:08 UTC 2014


> On 01/22/2014 04:14 AM, Peter Robinson wrote:
>>>>
>>>> It looks like the BeagleBone Black is still running at 550MHz with the
>>>> latest Fedora 20. Does anyone know what is holding it back from running
>>>> at
>>>> 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw
>>>> a
>>>> version of uboot referred to as making the BBB run at 1GHz, but when I
>>>> tried
>>>> experimenting with that I got the same 550MHz clock speed.
>>>
>>> If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch
>>> kernel [1] on your BBBlack. It should add freq scaling support and you
>>> should be able to tell if it detects it appropriately if the
>>> cpufreq-cpu0 module loads. Feedback welcome.
>>
>> So that kernel works with my testing but the module doesn't auto load
>> the cpufreq-cpu0 module. If you do:
>>
>> modprobe cpufreq-cpu0
>>
>> You then get:
>> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
>> 300000 600000 800000 1000000
>>
>> Even with 3.12.8 you can manually load that module and it works but
>> you only get up to 720mhz.
>>
>> Peter
>>
>>> [1]
>>> http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl.rpm
>
> Earlier Jos Vos reported the following results for his BeagleBoneBlack
> running pystone.py
>
> Fedora:
> Pystone(1.1) time for 50000 passes = 10.9073
> This machine benchmarks at 4584.1 pystones/second
>
> Debian:
> Pystone(1.1) time for 50000 passes = 4.38
> This machine benchmarks at 11415.5 pystones/second
>
>
> Before this latest kernel I was getting results a few percent slower than he
> reported for Fedora. With this new kernel RPM I get
>
> Pystone(1.1) time for 50000 passes = 6.23986
> This machine benchmarks at 8013.01 pystones/second
>
> That speed is very consistent across runs of the test. The speed has
> increased, but it seems to still be well below that of Debian. If I use
>
> cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
>
> While the machine is idle it says 300MHz. While pystone.py is running it
> says 1GHz. When the machine is idle, top says the CPU is around 1% loaded.
> When pystone.py is running it says it is 99.x% loaded. As far as I can tell
> the clock jumps from 300MHz to 1GHz as pystone.py starts up - i.e there is
> no substantial lag, resulting in half the test running at 300MHz and half at
> 1GHz.
>
> If my board really is now running pystone.py at 1GHz, I wonder what else
> could be causing this test to be around 50% slower than with Debian.

Well at least in the short term we've nearly doubled the speed.... one
step at a time :-)

What is the SD card you are using and are they the same? I suspect
that will have some effect too. You'd also need to look at the patch
set Debian uses, with 3.13 we're pretty close to mainline in terms of
the patch set and other than the OPP dtb patch there's nothing there
that should really have much effect on performance. My guess would
possibly be something DMA related, or maybe Debian has a patch that
improved memory timings, or similar.

What sort of things does pystone measure? I've never used it. Can you
get it to break the tests it does down so you can compare the
different components of the test, this might give us a better idea
where to look. What about one of the other test suites like
phoronix-test-suite?

Peter


More information about the arm mailing list