| ntpd related linux kernel patch | Created: 10.05.2009 19:17 |
|
Recent linux kernels exhibit a problem in combination with ntpd: ntpd takes far
(read: an order of magnitude) longer to get the clock in sync with the
correct time than on other operating systems or older linux kernels.
Up to now, this has been an annoyance, but apparently not annoying enough
for anyone to bother - after all, the clock is only wrong by a few split
seconds, and ntpd will manage to sync it up eventually, although it will
usually take a few hours. The only people really noticing it are probably
the ones having refclocks, as network latency usually is higher than the
error. An excemption to that is when computers are run in an environment where
temperature is unstable, because that results in changing frequencies in
computer parts, meaning: the clock will start to drift notably, and because
ntpd is too slow to correct it in the proper way (by speeding or slowing the
clock a little) some little time jumps like on startup may occour. Luckily, this annoyance should be over soon, because John Stultz was annoyed enough by it to finally track it down. You can read about his findings in this post on the linux kernel mailing list. Bottom line: The misbehaviour is caused by the rewritten time infrastructure in the linux kernel, and a parameter needs to be tweaked to get back to normal behaviour with the nanokernel. This is a one line kernel patch that in my opinion cannot get into the kernel soon enough. Until then, on linux kernel 2.6.19 to 2.6.29 you can do the patch yourself: open include/linux/timex.h in the linux kernel source tree, locate the line that says #define SHIFT_PLL 4 and change it to #define SHIFT_PLL 2. Then (re)compile your kernel. Although I have not done any proper benchmarks, the results I have seen so far were very impressive - ntpd will sync within an quarter of an hour now, instead of the many hours it took without the patch. I really hope this goes into the kernel ASAP. |
|
|
no comments yet |
|