public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Tim Schmielau <tim@physik3.uni-rostock.de>
Cc: Andrew Morton <akpm@osdl.org>,
	george@mvista.com, kaukasoi@elektroni.ee.tut.fi,
	linux-kernel@vger.kernel.org, davem@redhat.com
Subject: Re: /proc or ps tools bug?  2.6.3, time is off
Date: Tue, 04 May 2004 07:59:25 -0700	[thread overview]
Message-ID: <1083682764.4324.33.camel@leatherman> (raw)
In-Reply-To: <Pine.LNX.4.53.0405040804180.2215@gockel.physik3.uni-rostock.de>

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@physik3.uni-rostock.de) 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


  reply	other threads:[~2004-05-04 15:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-25  1:58 /proc or ps tools bug? 2.6.3, time is off David Ford
2004-02-25  1:54 ` Albert Cahalan
2004-02-25  5:10   ` David Ford
2004-02-25  3:27     ` Albert Cahalan
2004-02-25 16:28       ` George Anzinger
2004-02-25 16:04         ` Albert Cahalan
2004-02-25 20:45           ` George Anzinger
2004-02-25 19:16             ` Albert Cahalan
2004-02-25 21:10           ` George Anzinger
2004-02-26  1:52             ` john stultz
2004-02-26 23:06               ` George Anzinger
2004-02-26 23:10                 ` john stultz
2004-02-27  0:20                   ` George Anzinger
2004-04-13 22:38                     ` john stultz
2004-04-13 22:59                       ` George Anzinger
2004-04-14 12:10                       ` Tim Schmielau
2004-04-14 17:03                         ` George Anzinger
2004-04-14 18:28                         ` john stultz
2004-04-15 10:37                           ` Petri Kaukasoina
2004-04-15 11:05                             ` Tim Schmielau
2004-04-15 16:14                               ` Petri Kaukasoina
2004-05-01 13:51                                 ` Tim Schmielau
2004-05-02  1:41                                   ` Andrew Morton
2004-05-02  1:59                                     ` Tim Schmielau
2004-05-04  2:40                                       ` john stultz
2004-05-04  6:12                                         ` Tim Schmielau
2004-05-04 14:59                                           ` john stultz [this message]
2004-05-04 16:50                                             ` Tim Schmielau
2004-05-07  0:33                                             ` George Anzinger
2004-05-07  1:21                                               ` john stultz
2004-05-07 20:41                                                 ` George Anzinger
2004-05-07 21:38                                                   ` john stultz
2004-02-26 23:14               ` George Anzinger
2004-02-25  9:14 ` Petri Kaukasoina
2004-02-25  9:18   ` Petri Kaukasoina
2004-02-25 21:39   ` David Ford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1083682764.4324.33.camel@leatherman \
    --to=johnstul@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=davem@redhat.com \
    --cc=george@mvista.com \
    --cc=kaukasoi@elektroni.ee.tut.fi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim@physik3.uni-rostock.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox