(2013-01-16, 12:06)tuxen Wrote: [ -> ]Edit: Do you have the incorrect bogomips bug? Or knows where it comes from? It's still present.
Do you have force_turbo enabled (note: can void warranty).
I do, and my bogomips value is correct:
Code:
gpu_mem=128
gpu_mem_256=128
gpu_mem_512=128
boot_delay=3
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=4
over_voltage_sdram=2
current_limit_override=0x5A000020
force_turbo=1
Code:
root ~ # dmesg|grep -i bogo
[ 0.000753] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
root ~ # cat /etc/release
RPi.arm-devel-20130116225548-r12952
root ~ # uname -a
Linux rpi512 3.6.11 #1 PREEMPT Wed Jan 16 23:03:05 GMT 2013 armv6l GNU/Linux
(Note: this is a custom build of OpenELEC that I built last night, the only difference between Master and my build are modifications in my build to fix NFS auto-update, so nothing that would account for any bogomips difference)
(2013-01-17, 11:58)MilhouseVH Wrote: [ -> ] (2013-01-16, 12:06)tuxen Wrote: [ -> ]Edit: Do you have the incorrect bogomips bug? Or knows where it comes from? It's still present.
Do you have force_turbo enabled (note: can void warranty).
I do, and my bogomips value is correct:
I don't (my overclock is supposed to be dynamic) and this is what I get:
Code:
root ~ # dmesg|grep -i bogo
[ 0.000309] Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032)
(2013-01-17, 02:25)tuxen Wrote: [ -> ]But the failure here is you can not use the systeminfo screen to measure CPU idle usage neither must you be on this screen while measuring with top.
For anyone that might be interested, I've written a simple script to monitor Raspberry Pi vital stats such as current ARM/Core/GPU frequency, current temp (and max temperature achieved), current Core/SDRam voltage, IRQ/s, network RX/s and TX/s, CPU load, memory used/free. Will also display current memory config and which codecs are hardware enabled.
Code:
wget http://www.nmacleod.com/public/bcmstat.sh && chmod +x ./bcmstat.sh
./bcmstat.sh -x
The load stats will be equivalent to those in top, and the other information can be useful when monitoring network and other performance issues (eg. is your CPU frequency increasing as expected or stuck at stock etc.).
(2013-01-17, 12:09)pplucky Wrote: [ -> ]I don't (my overclock is supposed to be dynamic) and this is what I get:
Code:
root ~ # dmesg|grep -i bogo
[ 0.000309] Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032)
Then I think what you are seeing is "by design" - your Pi will boot at the stock 700MHz speed, and this speed will be used to calculate the bogomips value. What overclock settings do you have in your config.txt, as admittedly your bogomips value is on the low side. Another option to add to your config.txt is "initial_turbo=30" which should see your Pi calculate a more accurate bogomips without forcing turbo all the time (it will just be enabled for the first 30 seconds during boot).
If you want to monitor your CPU frequency, try the script I have linked in the post above.
(2013-01-17, 12:11)MilhouseVH Wrote: [ -> ] (2013-01-17, 12:09)pplucky Wrote: [ -> ]I don't (my overclock is supposed to be dynamic) and this is what I get:
Code:
root ~ # dmesg|grep -i bogo
[ 0.000309] Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032)
Then I think what you are seeing is "by design" - your Pi will boot at the stock 700MHz speed, and this speed will be used to calculate the bogomips value. What overclock settings do you have in your config.txt, as admittedly your bogomips value is on the low side. Another option to add to your config.txt is "initial_turbo=30" which should see your Pi calculate a more accurate bogomips without forcing turbo all the time (it will just be enabled for the first 30 seconds during boot).
If you want to monitor your CPU frequency, try the script I have linked in the post above.
This is what I currently have on my config.txt:
Code:
gpu_mem=100
arm_freq=900
core_freq=333
sdram_freq=450
over_voltage=2
force_turbo=0
initial_turbo=30
Usually I use SSH command 'vcgencmd measure_clock arm' to get my current CPU frequency...
(2013-01-17, 12:56)pplucky Wrote: [ -> ]Usually I use SSH command 'vcgencmd measure_clock arm' to get my current CPU frequency...
Yes, that's what the script uses but is also a little more informative - it will run continuously and periodically (default every 2 seconds) show you current values for most measurable items relating to Pi hardware.
(2013-01-16, 14:00)tfft Wrote: [ -> ]The compilation process grabs various packages from the openelec.tv's sources directory from the web, so there are files listed there akin to,
xbmc-f14f5a5.tar.xz
xbmc-f70eb43.tar.xz
xbmc-ff434fe.tar.xz
xbmc-theme-Confluence-f70eb43.tar.xz
xbmc-theme-Confluence-ff434fe.tar.xz
My question relates to those "hash" values (I'm guessing they are hashes) after the name - what do they point to ? I was not able to find a 'FF434FE' hash within the XBMC git tree and I'm a bit baffled as to what this value relates to as far as what is being pulled from GitHub. In other words, how can I take that FF434FE and transform it into a valid XBMC hash to know what has been pulled.
I just downloaded the xbmc github tree and was able to find the FF434FE string above (as an example); I then looked for the current xbmc PKG_VERSION (F70EB43) and that got me nowhere (its NOT part of the xbmc github log) - can someone please shed some light on where this hash is coming from ? I'd like to know which xbmc snapshot is being grabbed as compared to whats on github.
Is a different/private repository for xbmc being used ?
Thanks.
(2013-01-17, 14:46)sraue Wrote: [ -> ] (2013-01-17, 14:23)tfft Wrote: [ -> ]I then looked for the current xbmc PKG_VERSION (F70EB43) and that got me nowhere (its NOT part of the xbmc github log) - can someone please shed some light on where this hash is coming from ? I'd like to know which xbmc snapshot is being grabbed as compared to whats on github.
xbmc-f70eb43.tar.xz ---> https://github.com/xbmc/xbmc/commit/f70e...56fccce531
Strange - on github's web pages the hash noted doesn't resolve (it doesn't show-up in the 'git log' output either) and is not there even if 'gitk' is used. Oddly enough these two commits are equivalent,
https://github.com/xbmc/xbmc/commit/1336...0992624357
https://github.com/xbmc/xbmc/commit/f70e...56fccce531
The only difference I can see is that 'S. Davilla' committed again but why doesn't that commit show-up in github's mainpages ? Shouldn't every commit be available and accessible through the logs ?
Very strange...
Thanks for replying - I was (still am) rather baffled and wondering how to decipher such oddities in the future.
(2013-01-17, 15:47)tfft Wrote: [ -> ]Strange - on github's web pages the hash noted doesn't resolve (it doesn't show-up in the 'git log' output either) and is not there even if 'gitk' is used. Oddly enough these two commits are equivalent,
https://github.com/xbmc/xbmc/commit/1336...0992624357
https://github.com/xbmc/xbmc/commit/f70e...56fccce531
The only difference I can see is that 'S. Davilla' committed again but why doesn't that commit show-up in github's mainpages ? Shouldn't every commit be available and accessible through the logs ?
Very strange...
Thanks for replying - I was (still am) rather baffled and wondering how to decipher such oddities in the future.
change to the Frodo branch, or checkout the frodo branch and you will find this commit :-)
(2013-01-17, 11:58)MilhouseVH Wrote: [ -> ] (2013-01-16, 12:06)tuxen Wrote: [ -> ]Edit: Do you have the incorrect bogomips bug? Or knows where it comes from? It's still present.
Do you have force_turbo enabled (note: can void warranty).
I sure do and measuring from cmdline shows correct clock, this is only with rbej's build.
As he said himself he had the bug to I guess it was normal in he's builds. (look at post #895)
Therefore the question was more directed at him. I guess he has a bug somewhere then?
I know all about warranty and stuff I'm more worried about the other hardware as I had to replace a sdcard slot and I was not even pressing hard or anything it just snapped the edge holding one side. =)
Another pi arrived with the capacitor broken off ordered from RS board from china I also had to fix that after waiting months I was not prepared to wait god knows how long for a return. I have complained to RS though. No answer yet.
Edit: just checked dmesg and bogomips are calculated wrong there. (697)
I also have some "cpufreq: switching to governor on demand" at the end shouldn't this be disabled?
vcgencmd measure_clock arm is correct though 1050Mhz at idle.
Oh and thanks for the script.. Everything shows correct. Weird.
Let's see with the next rbej build if he is nice enough to share it with us. I know I'm lazy for not setting up a build environment and getting familiar with the process but I'm not complaining either its just odd.
Edit: I guess it also could be the firmware or maybe more likely "special rpi kernel 3.6.y" which I don't know what means. Which kernel and firmware are you using in your build MilhouseVH?
Thanks rbej. It just sounded more exotic to me than the boring 3.6.11 uname -a gives me
Looking forward to test a new build. No idea why it calculates the delay loop wrong then.
hopefully not going too far off topic - but has anyone managed to integrate (as a plugin, or seperate) NZBGET with openelec / xbmc please?
not wanting to download while I'm watching things of course, but my Pi uses a lot less power than my desktop while downloading.
(2013-01-18, 16:37)gizmomel Wrote: [ -> ]hopefully not going too far off topic - but has anyone managed to integrate (as a plugin, or seperate) NZBGET with openelec / xbmc please?
not wanting to download while I'm watching things of course, but my Pi uses a lot less power than my desktop while downloading.
You can install
SABnzbd-Suite as an add-on in OpenELEC, though personally I would run that sort of thing on a separate Pi (running Raspbian, headless...).