Not a member yet? Why not Sign up today
Create an account  

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
About Hz, jiffy values and governors

#1
Heart 
Here there is our well known history on Hz research and development:

Quote:* exact value, jiffy 0.01, 100Hz, common value;
* non exact value, jiffy 0,0078125, 128Hz, proposed by Colivas;
* exact value, jiffy 0.008, 125Hz, proposed by tropic;
* exact value, jiffy 0.005, 200Hz, common value;
* exact value, jiffy 0.004, 250Hz, common value;
* non exact value, jiffy 0.0033~, 300Hz, common value;
* non exact value, jiffy 0.003003~, 333Hz, proposed by tropic, probably worthless;
* exact value, jiffy 0.0025, 400Hz, tuning value for Android;
(*) exact value, jiffy 0.002, 500Hz, proposed by tropic;
> built by Xan, for all series of XanMod kernel from v1.160122 to v.1.160608;
> built by Xan, for all series of XanMod kernel from v1.161020 to current;
> built by Tigerite, for some versions of his kernel for Microsoft™ Surface devices;
> also discussed at Manjaro's forum;
* non exact value, jiffy 0.00167~, 600Hz, proposed by Rob;
(*) exact value, jiffy 0.0016, 625Hz, proposed by tropic;
> built by Tigerite, for the final versions of his kernel for Microsoft™ Surface devices;
> built by Mjasnik, for his testing version of his LQX kernel based on Liquorix;
> built by Xan, for all series of XanMod kernel from v.160608 to v1.161020;
> also discussed at Manjaro's forum;
* non exact value, jiffy 0.0013~, 750Hz, proposed by tropic;
* exact value, jiffy 0.00125, 800Hz, proposed by Tigerite;
> built by Tigerite, for the non-BFS/BFQ Linux kernel for MS™ Surface devices, dismissed;
* exact value, jiffy 0.001, 1000Hz, common value;
* non exact value, jiffy 0.00083~, 1200Hz, tuning value for Android;
* exact value, jiffy 0.0008, 1250Hz, proposed by tropic;
* non exact value, jiffy 0.00067~, 1500Hz, proposed by 'e';
* exact value, jiffy 0.000625, 1600Hz, proposed by tropic;
* exact value, jiffy 0.0005, 2000Hz, tuning value for Android;
* exact value, jiffy 0.0002, 5000Hz, proposed by 'e';
> built by 'e', for his legacy 4.4.5-xanmod10 for game server purposes;
* exact value, jiffy 0.0001, 10000Hz, proposed by 'e';
> built by 'e', failed to boot, dismissed;

Edit: there are only five exact jiffy values along the 300-1000Hz range.
Edit2: the first kernel ever at 500Hz was built by Xan, then by Tigerite.
Edit3: the first 625Hz kernel ever was built by Tigerite -- March 3, 2016.
Edit4: the second 625Hz kernel was built by Mjasnik -- April, 28, 2016.
Edit5: the longer stable 625Hz kernels were finally built by Xan -- June, 24, 2016.
Edit6: XanMod kernel returned to 500hz on 22 october, 2016.
Edit7: XanMod kernel built with 400Hz on 10 november, 2016
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#2
(...] All the best. (...)
"Everything has been thought of before, but the problem is to think of it again.“Goethe
Reply

#3
Now testing Stellarium 0.12.4 with 300/500/1000hz XanMod most recent available kernels with the most complex constellations, full-charged catalogue of stars, comets, asteroids, satellites, planets, orbits and all available plugins loaded. Some annoying short mouse and keystrokes delays observed with 300hz -- it happens occasionally with 500hz. ??? Should be enough 125hz more till reach 625hz to solve this little kind of issues? Rendering was quite good with 500hz, more than expected IMHO. Some weird behaviour observed sometimes with 300hz (freezings) and 1000hz (unexpected black and blinking screen when rotating the sky, occasionally). :o
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#4
Trying to solve the occasionally but very annoying freezings of Stellarium with 500hz kernel, I have installed the indicator-cpufreq package from repository and I have seen that it offered me four options for the CPU governors including performance, conservative, ondemand and powersave (ondemand is by default). Then I selected 'performance' governor option and the mouse freezings and keystrokes delays have gone immediately. Rendering is also a little smoother than before. Smile
Code:
~$ sudo apt-get install indicator-cpufreq
Then Alt+F2, write 'indicator' and click on 'indicator-cpufreq' to conclude install.
* In Ubuntu a small icon appears just near the battery or wifi icon.

Code:
#before
~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
ondemand
ondemand
#after
~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance

Edit: the change is temporary, you can change it whenever you want.
Edit2: more info at the 'CPU frequency scaling' section available below.

http://wiki.linuxaudio.org/wiki/system_configuration
Edit3: IMHO indicator-cpufreq is a must have tool.
Edit4: increased desktop responsiveness observed.
Edit5: Chromium lags are also solved with this governor.
Edit6: The 'performance' governor is also useful to see HD720/HD1080 videos and video streaming. It has solved for me some lag issues and image freezings in HD.
Edit7: annoying sound delays solved in PlayOnLinux.
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#5
I thought that "performance" governor would have a very negative impact on battery consumption but I haven't found such expected behaviour, furthermore this 500hz kernel is quit good and very recommended for battery saving. I wonder if Xan have made some tests about all this  -- IMHO the kernel should be shipped by default with this governor, but perhaps it's not easy to change the settings with a simple tweak.  :-X
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#6
Zika, if you want to help, just help. Every kind of politeness helping is always welcome. Smile
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#7
How to see if your cpu governor is offering you the maximum speed for all CPU cores:
Code:
~$ grep MHz /proc/cpuinfo
Smile
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#8
(02-02-2016, 09:06 AM)tropic link Wrote: How to see if your cpu governor is offering you the maximum speed for all CPU cores:
Code:
~$ grep MHz /proc/cpuinfo
Smile

To decrease your CPU core's speed to gain some more battery time for emergency situations is very easy with indicator-cpufreq, just select directly the desired available Mzh options or just select 'powersave' or 'conservative'. The lower value of Mhz the higher battery time you get, furthermore some config with governors also offers some options to save battery. 'Powersave' is a very good choice for non heavy long in time tasks, and also to decrease CPU temperature, while 'ondemand' is a very balanced option to work with. 'Performance' option just rocks for gaming! Smile
Code:
# 'performance' option
~$ grep MHz /proc/cpuinfo
cpu MHz        : 1666.000
cpu MHz        : 1666.000
# 'ondemand' option
~$ grep MHz /proc/cpuinfo
cpu MHz        : 1666.000
cpu MHz        : 1333.000
# 'conservative' option
~$ grep MHz /proc/cpuinfo
cpu MHz        : 1333.000
cpu MHz        : 1000.000
# 'powersave' option
~$ grep MHz /proc/cpuinfo
cpu MHz        : 1000.000
cpu MHz        : 1000.000
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#9
(02-02-2016, 09:06 AM)tropic link Wrote: How to see if your cpu governor is offering you the maximum speed for all CPU cores:
Code:
~$ grep MHz /proc/cpuinfo
Smile

To better observe the frequency scaling behavior:
Code:
watch -n 0,1 grep \"cpu MHz\" /proc/cpuinfo
Reply

#10
Quote:To better observe the frequency scaling behavior:
Code:
watch -n 0,1 grep \"cpu MHz\" /proc/cpuinfo

Thank you Xan. 'Performance' governor always work with maximum speed. Big Grin
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#11
After considering initial ideas with 432/500/625/864Hz kernels, yesterday I was thinking on arm11-CPUs phone-overclocking with Android tweaked JVT/JPO/JPU kernels at 1200Hz. What would happen if a 1200hz kernel get the BFQ/BFS patches? Would it even boot with Ubuntu and any other Debian distro liked?  ???

"In modern processors, the pressing demand for empirical performance figures is thwarted by the intrinsic unpredictability of instruction timing in most CPU designs due to cache memories, instruction scheduling, and branch prediction. As a response, CPU manufacturers introduced a way to count clock cycles as an easy and reliable way to measure time lapses. Therefore, most modern processors include a counter register that is steadily incremented once at each clock cycle. Nowadays, this clock counter is the only reliable way to carry out high-resolution timekeeping tasks." http://www.makelinux.net/ldd3/chp-7-sect-1
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#12
Some updates on Hz and jiffy values under development by our member TIgerite. Smile
http://xanmod.org/forum/index.php/topic,...tml#msg380
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#13
Some updates on Hz values beyond 1000Hz, for possible development, by our recent member e  -- the most brief nick I have seen in years. Smile
http://xanmod.org/forum/index.php/topic,...tml#msg380
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#14
Very interesting article on Linux governors, would be a well-tuned conservative governor better efficient than on-demand governor for whole long tasks when battery is needed?  ???
http://www.ibm.com/developerworks/librar...index.html
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#15
Our member 'e' is doing some testing with Hz values beyond 1000Hz: kernel panic observed with CONFIG_HZ=10000HZ -- most extreme value ever proposed here.  :o
http://prnt.sc/acrsw9

"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#16
Our member 'e' has recompiled latest XanMod to get 5000Hz. Smile
http://xanmod.org/forum/index.php/topic,...ml#msg1074
Edit: just look the latest results at the first post of this topic.
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#17
Hi Xanmod community,

I'm Rob McCathie from the Manjaro dev team.
Recently i've been investigating performance/responsiveness kernel tuning.

I've looked over all the changelogs for the Xanmod kernel and was hoping to ask some questions and get feedback on a few things, but will make a thread about that tomorrow night once i'm back home. For now just thought i'd mention that one interesting thing i've been testing is the Interactive frequency governor. I've got more testing to do yet, but so far i'm pretty impressed. It seems to do a pretty amazing job of keeping frequency at bottom when the system is truly idle, keeping it at top speed when there's an on-going intensive task and also reacting to new tasks at least on par with ondemand.

If you guys would also like to test it, i've put very up-to-date patches for it (created from the Android kernel source, newer than the 70-patch-set that was posted to the LKML late last year,) for the 4.1 series and 4.4 series up here:
http://paradoxcomputers.com.au/manjaro/p...-governor/

Note it must be set as built-in (not module) or it won't build. It also doesn't build for 32bit, only 64bit.
Reply

#18
Hello Rob, thank you very much for joined the Xanmod's members team! Thank you very much too for the interactive governor proposal as it's very interesting and probably it's also one of the better ideas for performance, battery and responsiveness as it said "(...) the 'interactive' governor uses a different approach. Instead of sampling the CPU at a specified rate, the governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy from exiting idle to when the timer fires then we assume the CPU is underpowered and ramp to MAX speed. (...)". It should be great advance in development! Smile
Please, get a warm welcome to the forum! Big Grin

P.S. I hope Xan will answer you as soon as he can. Smile
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#19
(15-04-2016, 12:53 PM)tropic link Wrote: Hello Rob, thank you very much for joined the Xanmod's members team!
...
Please, get a warm welcome to the forum! Big Grin

Thanks tropic Smile


Something else i considered today, and since this thread is also about a potential small increase to the interrupt frequency:
The kernel documentation regarding interrupt frequency makes a point of mentioning the framerate of common video formats (PAL & NTSC are mentioned). It makes sense that lining jiffy timing up with framerates of video people play or otherwise work with would be beneficial. I noticed you guys are using 500Hz and was going to prepare some 500Hz Manjaro kernels for testing, but noted that 500Hz, while exactly divisible by 25 and 50, is not exactly divisible by 24, 30 or 60.

600Hz however is exactly divisible by all common (and becoming-common) video framerates (24, 25, 30, 50, 60), so i'd think it's worth considering.
Reply

#20
(15-04-2016, 01:51 PM)Rob link Wrote: 600Hz however is exactly divisible by all common (and becoming-common) video framerates (24, 25, 30, 50, 60), so i'd think it's worth considering.

Hi again, Rob! Smile Well, it's a quite interesting question because after my initial proposal of 500Hz value in the past I thought that 625Hz should have been considered as the reference point for future kernel development  -- indeed Tigerite's kernel for Microsoft Surface devices is using it with very good results on performance at a low battery cost from those extra 125Hz. Anyway, the 500Hz has been one of the most valuable fruits from Xanmod development tasks and it actually remains as the perfect green flag on balanced performance/consumption reference ever -- I know it is, despite some neighbours are unable to understand this great innovation and they are still living in the chain of the 300/1000Hz dichotomy with no grateful to our efforts. Furthermore, I can sure you, and I know what I meant clearly what "sure" is, that there is no human eye capable to see any difference in any video playing scenario from above a 100Hz screen -- or 200Hz for 3D and always talking with real Hz and not from the common lies of CMR, Motion-Flow, MCI, PMR or Backlight. Smile
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply



[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Forum Jump:


Users browsing this thread:
1 Guest(s)