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
- Follow-Ups:
- Re: time patches by Roman Zippel
- From: Pavel Machek <[email protected]>
- Re: time patches by Roman Zippel
- From: Roman Zippel <[email protected]>
- Re: time patches by Roman Zippel
- Prev by Date: Re: [RFC][PATCH] UDF filesystem uid fix
- Next by Date: Re: [Lhms-devel] [RFC/PATCH: 002/010] Memory hotplug for new nodes with pgdat allocation. (Wait table and zonelists initalization)
- Previous by thread: root=/dev/sda1 fails but root=0x0801 works...
- Next by thread: Re: time patches by Roman Zippel
- Index(es):
 |