Pretty much everything is centered around that 1sec, so the closer the
update frequency is to it the better.
The error accumulates and there is no good reason to do this for the
common case.
clock->cycle_interval
CLOCK_TICK_ADJUST
If you change the frequency of acpi_pm to 3579000 you'll get this:
HZ=1000 CLOCK_TICK_ADJUST=0
jiffies 153000 ppb error
jiffies NOHZ 153000 ppb error
pit 152533 ppb error
pit NOHZ 0 ppb error
acpi_pm 0 ppb error
acpi_pm NOHZ 0 ppb error
HZ=1000 CLOCK_TICK_ADJUST=-152533
jiffies 0 ppb error
jiffies NOHZ 466 ppb error
pit -467 ppb error
pit NOHZ -1 ppb error
acpi_pm 126407 ppb error
acpi_pm NOHZ 22 ppb error
CLOCK_TICK_ADJUST has only any meaning for PIT (and indirectly for
jiffies). For every other clock you just add some random value, where
it doesn't do _any_ good.
The worst case error there will always be (ntp_hz/freq/2*10^9nsec), all
you do with CLOCK_TICK_ADJUST is to do shift it around, but it doesn't
actually fix the error - it's still there.
jiffies depends on the timer resolution, so it will practically produce
the same results as PIT (assuming it's used to generate the timer tick).
What exactly does it help with?
All you are doing is number cosmetics, it has _no_ practically value and
only decreases the quality of timekeeping.
The error at least is real, the use value of CLOCK_TICK_ADJUST for the
common case is not existent.
Part of the error is caused by CLOCK_TICK_ADJUST, but the other part of
the error is real, all you do is hiding it.
To be precise: CLOCK_TICK_ADJUST doesn't compensate anything, it only
hides the error for jiffies/PIT. In any other case it's just some random
value added to it.
The maximum is not that trivial, e.g. alpha has a CLOCK_TICK_RATE value of
32768 and has two possible HZ values 1024/1200. Everything is fine with
1024, but with 1200 you create an error of ~11230ppm.
In the alpha case you have the interesting problem, that the timer tick is
generated by the RTC (if I see it correctly). If the alpha used clock
sources, what value should CLOCK_TICK_RATE have? Which of the three
possible clocks do you want to adjust - the jiffies, the PIT or the cpu
cycle clock?
That's the other big problem with CLOCK_TICK_RATE, for many archs it's
just some random value and in some unlucky configuration it now may do
more harm than it does any good. It had some value when process timer were
jiffies based, but since hrtimer that reason is gone and in the NTP code
it does more harm than good.
bye, Roman
--
