path: root/kernel/time/tick-sched.c
diff options
authorRoman Zippel <>2008-03-04 15:14:26 -0800
committerThomas Gleixner <>2008-03-09 08:42:57 +0100
commit10a398d04c4a1fc395840f4d040493375f562302 (patch)
tree02096fe81b70e2baf8db35ebc9d303a1b13029c3 /kernel/time/tick-sched.c
parenta79017660ea4597ec489fab3b5aaf71dd776dfc7 (diff)
time: remove obsolete CLOCK_TICK_ADJUST
The first version of the ntp_interval/tick_length inconsistent usage patch was recently merged as bbe4d18ac2e058c56adb0cd71f49d9ed3216a405;a=commit;h=bbe4d18ac2e058c56adb0cd71f49d9ed3216a405 While the fix did greatly improve the situation, it was correctly pointed out by Roman that it does have a small bug: If the users change clocksources after the system has been running and NTP has made corrections, the correctoins made against the old clocksource will be applied against the new clocksource, causing error. The second attempt, which corrects the issue in the NTP_INTERVAL_LENGTH definition has also made it up-stream as commit e13a2e61dd5152f5499d2003470acf9c838eab84;a=commit;h=e13a2e61dd5152f5499d2003470acf9c838eab84 Roman has correctly pointed out that CLOCK_TICK_ADJUST is calculated based on the PIT's frequency, and isn't really relevant to non-PIT driven clocksources (that is, clocksources other then jiffies and pit). This patch reverts both of those changes, and simply removes CLOCK_TICK_ADJUST. This does remove the granularity error correction for users of PIT and Jiffies clocksource users, but the granularity error but for the majority of users, it should be within the 500ppm range NTP can accommodate for. For systems that have granularity errors greater then 500ppm, the "ntp_tick_adj=" boot option can be used to compensate. [ provided changelog] [ maek ntp_tick_adj static] Signed-off-by: Roman Zippel <> Acked-by: john stultz <> Signed-off-by: Matti Linnanvuori <> Signed-off-by: Andrew Morton <> Cc: Signed-off-by: Thomas Gleixner <>
Diffstat (limited to 'kernel/time/tick-sched.c')
0 files changed, 0 insertions, 0 deletions