# BFS + timer freq = 1000 : CONFIG_NO_HZ = y/n ?

## aCOSwt

Having googled a week for guru's deep thinkings about the topic, I am left a bit...   :Confused:  as I did not find any kind of common agreement.

So... let's open the discussion with you who really actually tested this.

My concern about this is that I need a low latency experience, (not necessarily the lowest average but the lowest variance), am not concerned by energy saving per se but am strongly concerned by overheating as, in order to save noise, my system (Core 2 E8400) is being passive-cooled and slightly over-clocked.

This concern is being increased by the significant drop in cpu temperatures I noticed from my 2.6.34 -> 2.6.38 move.

(But I admit it could be because of an abnormally hot spring   :Twisted Evil:  )

My workload is the result of standard desktop usage interspersed with a full hour of non-stop sound recording / processing.

So... as far as you are concerned... CONFIG_NO_HZ is... worthy ? useless ? low-latency-killer ?

From what I can tell on my side... I have not yet noticed any significant change in my sensors report (but I might have missed something   :Confused:  ) ... and... I cannot really tell about latency as... in order to reduce it... I... do not implement anything dedicated to its measurement.   :Twisted Evil: 

----------

## PaulBredbury

I assume you mean rise in temperature, not fall - see slashdot and see whether pcie_aspm=force helps for your PC's broken BIOS.

CONFIG_NO_HZ seems fine for me - I've tried it on and off, with 300, 432 and 1000hz - difficult to see a difference, as a gamer and user.

I would recommend NO_HZ at 300hz, personally - it's what I use. Con K. doesn't even mention 432/864 anymore (dunno why), and 1000 is extreme, so I hear.

If overheating is a problem for you, then you should improve the passive cooling.

You're using a realtime kernel, right? I dunno how much that changes the game parameters.

----------

## aCOSwt

 *PaulBredbury wrote:*   

> I assume you mean rise in temperature, not fall

 

 :Embarassed:  Yes indeed ! Sorry for my bad english mainly based on rugby language and its drop that... if success is expected, was associated in my mind with a sudden... rise !   :Rolling Eyes: 

 *PaulBredbury wrote:*   

>  - see ...Nailing-the-Cause-of-Recent-Linux-Power-Issues... and see whether pcie_aspm=force helps for your PC's broken BIOS.

 

Thanks for the tip. I jumped on this at once as my system will not survive if current weather conditions last longer.

(un)fortunately, my system is not concerned by this.

 *PaulBredbury wrote:*   

> CONFIG_NO_HZ seems fine for me - I've tried it on and off, with 300, 432 and 1000hz - difficult to see a difference,

 

Same here. My understanding is that the greater timer frequency the more efficient NO_HZ should be. Maybe I should test with timer freq > 1000 but... I will not test this before... next winter and... I am not sure about any interest for me in > 1000 values ! 

 *PaulBredbury wrote:*   

> I would recommend NO_HZ at 300hz, personally - it's what I use... and 1000 is extreme, so I hear.

 

A couple of years ago, my midi apps have been complaining that system timer resolution was too low when set to 300. That triggered my rise to 1000. I never went back since.

 *PaulBredbury wrote:*   

> If overheating is a problem for you, then you should improve the passive cooling.

 

 :Very Happy:  I'd better think about migrating to the cellar then !

I had calculated my heatsinks taking a value of 25°C for space temperature.

If I recalculate with 30°C for space temperature then... results are just... crazy !

 *PaulBredbury wrote:*   

> You're using a realtime kernel, right?

 

No longer. The RT_PREEMPT patchset sticks to linux' long term releases. That is to say 2.6.32 at the time I left. Could be available for 2.6.33 though. Anyway I was in a need for in-kernel snd_aloop which is available only from 2.6.37.

This triggered my move from [vanilla + RT_PREEMPT] to [portage's ck-sources], currently 2.6.38-r2.

----------

## kimmie

If I were you, I'd be slightly underclocking rather than overclocking to get the heat down. A 100MHz either way shouldn't make that much difference to your audio work, whereas your machine taking the day off certainly will.

I don't have a good answer about CONFIG_NO_HZ... additional latency would come from the processor being able to reach a deeper C-state and have to wake up, on the other hand without NO_HZ, it might be doing that 1000 times a second. I don't think you can really get a good answer from theory... my advice would be to grab and compare the kernel configs of some of the more more recent linux audio distributions.

----------

## tclover

I'd say CONFIG_NO_HZ=y seems not to be a big deal for any significant power reduction but this come with a few power save combinations. Actually, I can't say regarding the temperatures that I did benefit from it. However it's pretty hot on these days and only CPU core temperature seem to have increased a bit--which could be explained with the hot summer days.

Now, I think enabling it could be of some use as powertop require it to be enabled in order to fine tune a few power saving tweaks--particulary tuning the necessary for USB and soundcard devices. USB devices (EHCI, UHCI) should not be left without a few considerations as those seems to be the main culprit of wake up at idle along with AHCI/SATA/Network drivers. I can't remember exactly what CONFIG_NO_HZ enable when enabled in the kernel. So in the end, I think for a desktop there isn't much that could be done after enabling it than:

 *power save profile (using hprofile) or something similar wrote:*   

> for i in 0 1; do echo powersave > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done
> 
> echo powersave > /sys/module/pcie_aspm/parameters/policy
> 
> echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
> ...

 

in a (maybe hprofile which I do use) powersave profile along with setting the powersave/suspend time for unused USB devices solely to prevent waking up your CPU at idle because you won't save any significant power in a desktop which does the trick--my CPU do stay at the lowest C-state all the time in idle, but then, I did aswell overclock my CPU from 1.8GHz to 2.4GHz with the reference voltage which doesn't help that much and with 3 120mm noctua fans--one at 600-700 rpm for intake and drive enough pressure to a passively cooled 8800GT, one at 800-850 rpm for enough pressure for big CPU heatsink and last one at 900 rpm for out-take,and of course one 700 rpm for PSU (that too many? maybe, my box is maybe cramped, only the PSU turbulence is noticeable in quiet environment at night). But then, in a laptop you can benefit for a slightly improved battery life.

So enable or not? the answer seems straightforward with a few tweaks even if solely enabling it won't do that much difference.

EDIT: I do think one should go for 1000Hz to get a responsive system. 1000Hz doesn't mean the CPU would wake 1000 times per second. That's not it at all. I'd say it's a sort of period that define a minimum wake up time.

EDIT2: Now, I've just set that power profile running on my desktop which is mainly intended to my laptop and I notice some noticale improvment: -2C for GPU and -2C for CPU. Now, I'm going to take a close look about it.Last edited by tclover on Wed Jun 29, 2011 4:43 pm; edited 2 times in total

----------

## PaulBredbury

Ubuntu's realtime 2.6.38 kernel looks worth a try.

----------

