> On Apr 22, Ulrich Windl wrote:
>
> > Hello,
> >
> > I don´t know what the initial reasoning for "500/HZ" was, but I think
> > the value for tickadj is way too small in the Linux kernels.
> >
> > (tickadj limits the speed of a adjtime() system call)
> >
> > The current rate is 0.5ms per second. Thus a correction of 128ms
> > needs 256s, almost 5 minutes. A correction of one second (not unusual
> > if the computer was powered down for a day) almost needs half an hour.
>
> IMHO 128ms is a pretty huge difference and should almost never happen.
> and if it happens, waiting 1/2 hour shouldn't be a problem (as it
> never happens anywy -- per definition;)
>
> and at powerup you first should use ntpdate or similar to step the clock then.
>
>
> > The current rate of 0.05% (500PPM) is too slow in most cases. Many
> > systems use much larger values.
> >
> > I'm suggesting to boost the value of tickadj by a factor of 100.
> > Therefore tickadj will be 50000/HZ, 500 for i386. This will result in
> > a correction of 50ms per second (5%).
>
> NO, that's _WAY_ too large! if you're trying to do some timing/benchmark
> in this period you'd get 5% error just because of tickadj.
If the benchmark is long enough, the result will be the same. Despite
of that I'd prefer a rather short adjust after boot over an
adjustment the next hour after boot.
In addition NTP get's confused when the adjtime() remainder is still
processed when precision time adjustments (MOD_OFFSET, STA_PPSTIME)
is in effect, especially as the granularity of adjtime is 1µs while
the other algorithms work with sub-microsecond resolution.
Yesterday's experiment with the nanokernel showed that the frequency
settles down quicker and without the "micro-sawtooth" if adtime()
finishes quickly.
I think HP-UX uses a tickadj around 600µs...
> IMHO that's completely out of range! waiting a bit longer to get clocks
> in sync is much preferable than to risk 5% errors in timing/sleep intervals
> etc.
As indicated to someone else, sleeps and delays work with jiffies and
are unaffected by adjtime().
[...]
Regards,
Ulrich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/