time patches by Roman Zippel

["Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de>]

Hello,

Roman had asked me to look at his recent set of time patches. So I did have a
quick look.

Generally I think removing code that proved to work for about 10 years or more
without having a replacement is to be avoided. What Roman did implement is a move
towards the new NTP kernel algorithms, but it's "neither fish nor meat": In part
it changes the semantics of syscalls, and it changes constants in an incompatible
way.

Specifically when considering that there exists a proven kernel code replacement
for some years now (which I'm at integrating to 2.6.15), I wonder whether it's a
wise decision to start hacking the code in such a way.

Roman may know more than I about how to make efficient 64-bit math on 32-bit
archs, but AFAIK he broke a few things:

15_time_offset and 18_time_freq change some well-known constants (like MAXPHASE)
by three orders of magnitude.

the new adjtime() (16_time_adjust, 12_time_adj) changes the semantics: Since about
Linux 0.99, adjtime() had the adjtime_is_accurate property, i.e. on the long term
it behaved like an addition.

Currently, unless I'm wrong, adjtime() for 1µs with HZ == 1024 would correct the
clock by nothing, while an adjtime() for 2µs would correct the clock by 1024ns on
the same system. For HZ == 100 things seem OK however.

My philosophy is "do it correct first, then optimize".  Some test with the code
from last weekend (measure the time of an external "Pulse per Second" (plus the
first two derivations of it)) gave results like this (virtual nanosecond
granularity, i.e. get_offset() still has microsecond resolution, ntpd trying to
calibrate the clock):

assert 1120 time 1139767167.000402394 delta 1.000000030 jitter 1535064674
assert 1121 time 1139767168.000402457 delta 1.000000063 jitter 33
assert 1122 time 1139767169.000402521 delta 1.000000064 jitter 1
assert 1123 time 1139767170.000402586 delta 1.000000065 jitter 1
assert 1124 time 1139767171.000402635 delta 1.000000049 jitter -16
assert 1125 time 1139767172.000402667 delta 1.000000032 jitter -17
assert 1126 time 1139767173.000402684 delta 1.000000017 jitter -15
assert 1127 time 1139767174.000402688 delta 1.000000004 jitter -13
assert 1128 time 1139767175.000402684 delta 0.999999996 jitter -8
assert 1129 time 1139767176.000402676 delta 0.999999992 jitter -4
assert 1130 time 1139767177.000402668 delta 0.999999992 jitter 0
assert 1131 time 1139767178.000402660 delta 0.999999992 jitter 0
assert 1132 time 1139767179.000402654 delta 0.999999994 jitter 2
assert 1133 time 1139767180.000402650 delta 0.999999996 jitter 2
assert 1134 time 1139767181.000402648 delta 0.999999998 jitter 2
assert 1135 time 1139767182.000402648 delta 1.000000000 jitter 2
assert 1136 time 1139767183.000402648 delta 1.000000000 jitter 0

(The last released patch snapshot is named "PPSkit-light-alpha-2955m-
2.6.15.1.diff.gz" and can be found in the directory /pub/linux/daemons/ntp/PPS of
your favourite Linux mirror. At the moment there exist two uncommitted change sets
that have to be tested first)

So personally I'd suggest to consider that code base. Options are eiher
1) to optimize/streamline what you think is too ugly
2) make the whole NTP lcok calibration optional if you think it's computationally
too heavy (however, both GNOME and KDE hit the CPU much more than any of these
changes)

Regards,
Ulrich
P.S. I'll attach a longer sample (12kB) of my timing test.

Attachment: jitter.log
Description: Binary data