Re: /proc or ps tools bug? 2.6.3, time is off

From: john stultz
Date: Tue May 04 2004 - 10:01:57 EST


On Mon, 2004-05-03 at 23:12, Tim Schmielau wrote:
> On Mon, 3 May 2004, john stultz wrote:
> > This patch polishes up Tim Schmielau's (tim@xxxxxxxxxxxxxxxxxxxxxx) fix
> > for jiffies_to_clock_t() and jiffies_64_to_clock_t(). The issues
> > observed was w/ /proc output not matching up to wall time due to
> > accumulated error caused by HZ not being exactly 1000 on i386 systems.
> > The solution is to correct that error by using the more accurate
> > TICK_NSEC in our calculation.
>
> I wonder whether it's conceptually correct to use jiffies for accurate
> long-time measurements at all. ntpd is there for a reason. Using both
> corrected, accurate and freely running clocks IMHO is calling for trouble.
> This might be something to think about for 2.7.

Indeed. Moving away from jiffies as a time counter and more of an
interrupt counter is important. That allows for implementations of
variable HZ and other things the high-res timer folks want without
affecting the time keeping code.

Roughly, I'd like to see the time code for all arches in 2.7 to look
like:

u64 system_time /* NTP adjusted nanosecs since boot */
u64 wall_time_offset /* offset to system_time for time of day */
u64 offset_base /* last read raw hw value */

ts_read():
returns the raw cycle value from the hardware timesource
(TSC/ACPI PM/HPET)
ts_delta(now, then):
returns the difference between two raw cycle values
ts_cyc2ns(cycles):
converts a cycle value to ns

monotonic_clock():
returns NTP adjusted nanoseconds since boot
ie: system_time +
NTP_GUNK(ts_cyc2ns(ts_delta(ts_read(),offset_base)))
gettimeofday():
returns monotonic_clock() + sys_time_offset
settimeofday():
adjusts only sys_time_offset
time_interrupt_hook():
updates system_time. called by timer interrupt atleast once
every hardware cycle (ie: before the hardware counter
overflows), but otherwise unaffected by lost interrupts, etc.
ie:
then = offset_base
now = ts_read()
system_time += NTP_GUNK(ts_cyc2ns(ts_delta(now, then)));
DO_MORE_NTP_GUNK()

And ignoring the magic NTP_GUNK macros, that's all there is to it
(Although don't kid your self, the NTP_GUNK is nasty).

Of course, with this approach, we actually have to be able to trust the
hardware 100%. With the current state of i386 hw having serious problems
w/ reliable timesources, this may be difficult.

I've got a bigger proposal (with proper credits to Keith Mannthey and
George Anzinger for reviews and corrections) that I wrote up awhile
back, and I'll likely send it out if this sketch gathers any interest.

thanks
-john

-
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/