> ---------- Forwarded message ----------
> Date: Thu, 29 Sep 2011 14:42:45 +0200
> From: Dennis Borgmann <dennis.borgmann@xxxxxxxxxxxxxx>
> To: linux-rt-users@xxxxxxxxxxxxxxx
> Subject: [RT]adjtimex gives wrong number of ticks
>
> Hello RT-users!
>
> I am observing strange behaviour regarding CONFIG_HZ on various machines, while
> trying to adjust the tickrate of some systems. I found, that adjtimex(2) is not
> behaving the way it should. If I write a simple program like this:
>
> #include <stdio.h>
> #include <sys/timex.h>
> int main() {
> struct timex t;
> adjtimex(&t);
> printf("%ld\n",t.tick);
> }
>
> , which simply is to print the time in usec between two kernel ticks, the output
> makes no sense. On a RT-System with CONFIG_HZ=1000, the output is "10000" and on
> a non-RT system with CONFIG_HZ=250 (my desktop-laptop), the output is "9999" -
> almost the same.
>
> If I calculate correctly, it should be 1000 with CONFIG_HZ and 4000 with
> CONFIG_HZ=250.
>
> Am i wrong, or is this an error?
>
> Btw: adjtimex with a tick of of 1000 gives me this:
>
> root@ap:/tmp# adjtimex --tick 1000
> adjtimex: Invalid argument
> for this kernel:
> USER_HZ = 100 (nominally 100 ticks per second)
> 9000 <= tick <= 11000
> -32768000 <= frequency <= 32768000
>
> on the RT-system with CONFIG_HZ=1000. This is also odd - it should print
> "USER_HZ=1000" and not "USER_HZ=100".
>
> Strange... Any ideas?
So USER_HZ is always 100 (atleast on x86 and X86_64 systems).
Its a architecture specific constant that allows the kernel to keep a
consistent ABI to userspace regardless of what the internal
configuration of the kernel is.
So the kernel will take adjustments to the tick value via adjtimex and
scale them appropriately to the internal HZ value before applying it.
So while you may be running with HZ=250 or HZ=1000, the kernel
interfaces that expose "ticks" will always use USER_HZ (100) based
ticks.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
