31 Mar
2017
31 Mar
'17
7:31 p.m.
On Fri, 31 Mar 2017 18:55:45 +0200 (CEST), karl(a)aspodata.se wrote:
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
Btw. in the past, with my old mobo, Qtractor displayed using hrtimer and
it was selectable by the list of sources. Now it displays "default" and
doesn't offer hrtimer in the list. Any explanation for this is welcome.
Regards,
Ralf
--
"Michael" described Floyd as "an idiot savant", and added, "Give
him
any two numbers, and he can multiply them in his head, just like that."
Homer, testing Floyd, said, "Five times nine", and Floyd instantly
responded "Forty-five", which impressed Homer.