All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.