31 Mar
2017
31 Mar
'17
9:26 p.m.
Ralf:
On Fri, 31 Mar 2017 18:55:45 +0200 (CEST),
karl(a)aspodata.se wrote:
...
Why then don't you just state, for the benefit of the curious pro, that
to test if CONFIG_HZ matter, just do something like the above. You
don't have to survey motherboards/cpus, give the user a test they can
perform and they can decide for themselves.
To test if the latency matter, do something like ..., etc.
Then the user can decide for themselves if said property matters for
them.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
I don't think most people have done testing
that, and since I'm no pro.
in the audio field, I havn't tested that either. Personally I don't
believe that CONFIG_HZ matter at all. CONFIG_HZ is about the kernel
ordinary scheduling, the RT patch in some ways throws that away, so
why should CONFIG_HZ matter.
Now the question is how instrument a test to verify that and what do
we want to measure ?
There's no need for measurements.
If you want to compare system timer 300 Hz with system timer 1000 Hz
you e.g. could check if one or the other increases MIDI jitter by using
https://github.com/koppi/alsa-midi-latency-test , but since by default
usually hpet (hrtimer) is used, it doesn't matter. The question is, if
for some reason hpet (hrtimer) shouldn't be used on some machines or
by some software. There are also the tickless options.
[rocketmouse@archlinux ~]$ cat
/sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
[rocketmouse@archlinux ~]$ cat
/sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
[rocketmouse@archlinux ~]$ zgrep NO_HZ /proc/config.gz
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set