[PATCH] fix rounding problem during clock update

So I had assumed this was picked up already, but apparently it somehow
got lost in the early 2.6.26 time-frame.

Anyway, I pinged Roman about it, but he hasn't responded, so I wanted to
send this on for inclusion into -mm (I've not had much time to test with
it, so it probably could use some wider testing) and then hopefully
2.6.27.

thanks
-john


From: Roman Zippel <zippel@xxxxxxxxxxxxxx>

Due to a rounding problem during a clock update it's possible for
readers to observe the clock jumping back by 1nsec. The following
simplified example demonstrates the problem:

cycle xtime
0 0
1000 999999.6
2000 1999999.2
3000 2999998.8
...

1500 = 1499999.4
= 0.0 + 1499999.4
= 999999.6 + 499999.8

When reading the clock only the full nanosecond part is used, while
timekeeping internally keeps nanosecond fractions. If the clock is now
updated at cycle 1500 here, a nanosecond is missing due to the
truncation.
The simple fix is to round up the xtime value during the update, this
also changes the distance to the reference time, but the adjustment will
automatically take care that it stays under control.

Signed-off-by: Roman Zippel <zippel@xxxxxxxxxxxxxx>
Signed-off-by: John Stultz <johnstul@xxxxxxxxxx>

---
kernel/time/timekeeping.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

Index: linux-2.6-mm/kernel/time/timekeeping.c
===================================================================
--- linux-2.6-mm.orig/kernel/time/timekeeping.c
+++ linux-2.6-mm/kernel/time/timekeeping.c
@@ -484,7 +484,7 @@ void update_wall_time(void)
#else
offset = clock->cycle_interval;
#endif
- clock->xtime_nsec += (s64)xtime.tv_nsec << clock->shift;
+ clock->xtime_nsec = (s64)xtime.tv_nsec << clock->shift;

/* normally this loop will run just once, however in the
* case of lost or late ticks, it will accumulate correctly.
@@ -515,9 +515,12 @@ void update_wall_time(void)
/* correct the clock when NTP error is too big */
clocksource_adjust(offset);

- /* store full nanoseconds into xtime */
- xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift;
+ /* store full nanoseconds into xtime after rounding it up and
+ * add the remainder to the error difference.
+ */
+ xtime.tv_nsec = ((s64)clock->xtime_nsec >> clock->shift) + 1;
clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift;
+ clock->error += clock->xtime_nsec << (NTP_SCALE_SHIFT - clock->shift);

update_xtime_cache(cyc2ns(clock, offset));


--



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Chaos feared after UNIX time-zone database nuked
    ... this one has lost its focus. ... terms AM (ante meridiem, before noon), PM ... GMT/UTC and 24-hour clock values should be adopted universally for IT use. ... confounding of local display/print values and formats with network ...
    (bit.listserv.ibm-main)
  • Re: ethical question
    ... >> Dragging out a match in the forlorn hope your opponent might lose on ... > so enforcement of this rule is practically impossible. ... US clock rules). ... If the player's dispute the 100% lost situation, ...
    (rec.games.backgammon)
  • Re: Can a clock drift be too big for ntpd?
    ... My relative frequency is stable at about -148 ppm, so my system clock runs too fast due to 1000 Hz setting as I understand. ... lost interrupts problem and pre-compensating will not be enough. ...
    (comp.protocols.time.ntp)
  • Re: Idiot Proof Aether Drift Experiment (OWLS)
    ... >> Esteemed David, ... Getting you all esteemed up is a lost ... clock should always read half the round trip time no matter what the ... and a reflector at the reciever to establish the TWLS distance ...
    (sci.physics.relativity)
  • Re: very accurate timer
    ... However a nanosecond is also fine by me;P ... Just waiting for Bill S to jump in with an ECL problem solver ... ECL will get you a 500MHz clock. ... - the jitter on our clock was about 60psec so the 10psec was entirely ...
    (sci.electronics.design)