[Raspberry Pi1] Speed Boost
#16
sounds interesting misa, I'll let popcornmix come and say something about it maybe before having a go.

misa I have been able to increase my overclock from 1100 to 1300 and it has been stable for a day. so doing the steps above seem to let you increase overclock slightly. lets see if its stable

edit LOL thats meant to read 1130, (I wish it was 1300)
Reply
#17
(2015-07-01, 11:44)MediaPi Wrote: sounds interesting misa, I'll let popcornmix come and say something about it maybe before having a go.

misa I have been able to increase my overclock from 1100 to 1300 and it has been stable for a day. so doing the steps above seem to let you increase overclock slightly. lets see if its stable

edit LOL thats meant to read 1130, (I wish it was 1300)

1130 mmmm, and stable? My question will be if we have to delete all the config.txt overclock settings if we use that tip and which overclock settings we have to delete

I got this stable at the moment:

arm_freq=1062
sdram_freq=480
core_freq=590
over_voltage=4
gpu_mem=320
hdmi_ignore_cec_init=1

over_voltage_sdram_c=0
over_voltage_sdram_i=0
over_voltage_sdram_p=2
avoid_pwm_pll=1
force_turbo=0
Reply
#18
(2015-07-01, 10:25)misa Wrote: The question for me now is, what does it exactly do Smile

It changes the "turbo" mode settings to make turbo mode happen more often.

Isengard actually changes the settings even more aggressively, so don't do use the linked settings with a clean nightly install.

These are the latest OE settings:
https://github.com/OpenELEC/OpenELEC.tv/pull/4200

Turbo mode works by polling periodically (every sampling_rate microseconds) and checking the CPU load of each core.
If any are above up_threshold %, then we kick into turbo mode. The switch back down is only done every sampling_down_factor poll intervals.

So smaller sampling_rate microseconds will mean faster to switch into turbo mode, but will waste more CPU checking.
Smaller up_threshold means we kick into turbo mode at lighter loads. Too low and it may never leave turbo mode.
Larger sampling_down_factor means it stays in turbo mode longer even when the load has gone away.
Also io_is_busy means treat any IO (e.g. sdcard access) as a trigger for turbo mode.

The new official OE settings do mean you are in turbo mode more often, so you should get a performance benefit.
The numbers in the Milhouse PR came from me, so that would be my recommendation.

Note: if you use force_turbo=1 then all these settings are irrelevant as you are in turbo mode all the time.
Reply
#19
Thanks voor explaining, so if you are on Millhouse builds the advise would be, don't do these changes
Reply
#20
Let just check what I get with a Milhouse build:
Code:
OpenELEC:~ # cat /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
1
OpenELEC:~ # cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
50
OpenELEC:~ # cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
100000
OpenELEC:~ # cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
50
They all look good to me. If you are seeing the same settings then I wouldn't change anything.
If you have different settings (e.g. on Helix build) then there may be a benefit to changing them.
Reply
#21
I wanted to disable the fanart and icon fade animation, I'm sure its using up the cpu cycles. I found out how

you need to modify the includes.xml

find

Code:
    <constant name="FanartCrossfadeTime">500</constant>
    <constant name="IconCrossfadeTime">400</constant>

and replace with

Code:
<!--    <constant name="FanartCrossfadeTime">500</constant>
    <constant name="IconCrossfadeTime">400</constant> -->

subjectively things just pop now. let me know if its any good, I'm adding to first post
Reply
#22
(2015-07-07, 14:29)MediaPi Wrote: I wanted to disable the fanart and icon fade animation, I'm sure its using up the cpu cycles. I found out how

you need to modify the includes.xml

find

Code:
    <constant name="FanartCrossfadeTime">500</constant>
    <constant name="IconCrossfadeTime">400</constant>

and replace with

Code:
<!--    <constant name="FanartCrossfadeTime">500</constant>
    <constant name="IconCrossfadeTime">400</constant> -->

subjectively things just pop now. let me know if its any good, I'm adding to first post

It pops yes, seems quicker again
Reply
#23
glad to hear Smile
Reply
#24
Nice thread ! Im not using my original pi now but I would have definitely played around with theses tweaks Smile
Reply
#25
yeah I know, really wished I knew about these or researched them before the Pi2 came out lol
but seriously the speed I'm getting in conjunction with learning keymap editing, I can work through menus with ease. I'm using my Pi1 with a crt tv so I think for this tv I'll stick with Pi1 and get the Pi2 in a few months.
Reply
#26
You thought about unsquashing and modifying the latest stable image with all your tweaks ?

I always used Millhouses builds on my original pi because he included many of the tweaks mentioned, ive continued to use the builds on the pi 2. But it may help people that still run the pi that don't want to run test builds.

One thing that I also used to find helped on the original pi was to drop the fanart and image res. To 540p in my advanced setting. It may have just been placebo.
Reply
#27
I just dropped the fanart and image res on my setup because I have an sd tv. but for some reason I think thats more of a personal choice
I have no idea how to do the unsquashing thing, but frankly I want this thread to be about users willing to do some tinkering like this. you learn alot, I mean I just messed around with one idea and its led me to look at the code that devs use and now I've learnt that you can modify it yourself, I can only do simplest of modification, but its more than I've done in the past.
and if other users are willing to go that far maybe they can come back and share information that they learnt. Smile like you just did with reducing fanart
Reply
#28
(2015-07-07, 14:59)misa Wrote:
(2015-07-07, 14:29)MediaPi Wrote: I wanted to disable the fanart and icon fade animation, I'm sure its using up the cpu cycles. I found out how
...
subjectively things just pop now. let me know if its any good, I'm adding to first post

It pops yes, seems quicker again

It's certainly quicker, but without the fanart fade animation the Confluence "bubbles" background will often replace the last shown fanart as you scroll rapidly through lists (ie. Thumbnails view), and this causes the background to appear to "flicker", which can be a little disconcerting/distracting.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#29
I did notice that and for now I'll see if its to distracting enough
Reply
#30
nofliptimeout?

The settings in your post are:
I did try <nofliptimeout>1000</nofliptimeout> instead of <nofliptimeout>0</nofliptimeout>, but that seems to shoot my CPU back up. I haven't played with it more since changing the dirtyregions to 3 fixed things for me. So here is where I'm setting and having good luck so far....

<advancedsettings>
<gui>
<algorithmdirtyregions>3</algorithmdirtyregions>
<nofliptimeout>0</nofliptimeout>
</gui>
</advancedsettings>

if you look @ this link: http://kodi.wiki/view/Dirty_regions

You see the settings: <algorithmdirtyregions>3</algorithmdirtyregions>
<nofliptimeout>0</nofliptimeout>
Are Default for Kodi.... i think this in more somting for Windows do..?


And how does this work?: https://github.com/xbmc/xbmc/pull/2265
Reply

Logout Mark Read Team Forum Stats Members Help
[Raspberry Pi1] Speed Boost1