public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: Albert Cahalan <albert@users.sourceforge.net>
Cc: David Ford <david+powerix@blue-labs.org>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: /proc or ps tools bug?  2.6.3, time is off
Date: Wed, 25 Feb 2004 08:28:42 -0800	[thread overview]
Message-ID: <403CCD3A.7080200@mvista.com> (raw)
In-Reply-To: <1077679677.10393.431.camel@cube>

Albert Cahalan wrote:
> On Wed, 2004-02-25 at 00:10, David Ford wrote:
> 
> 
>>I can see if a process long in the past would have a different time set 
>>on it, but shouldn't the entry in /proc coincide with the system clock 
>>that date is accessing?  Or how many different "clocks" does the kernel 
>>have going?
> 
> 
> There are way too many clocks, none of which are good.
> 
> 
>>Actually, it seems that there is a -significant- time difference in this 
>>phantom clock now, I suspended my notebook to bring it home from the 
>>station, and now this time difference is greater than 9 minutes.  I 
>>suspect it's roughly 46 seconds plus the amount of time that my notebook 
>>was suspended.  Yes, I'm running ntpd.
>>
>>root     16894  0.0  0.0  1544  484 pts/3    S    Feb24   0:00 grep grep ps
>>Wed Feb 25 00:09:09 EST 2004
> 
> 
> OK, this is pointing right at the problem.
> 
> Linux does not record process start times at all.
> Instead, it records the number of clock ticks
> from boot until the process starts.
> 
> Either the boot time or current time is real.
> The other may be computed from the uptime, which
> may be measured in clock ticks.

In 2.6.* boot time is captured at boot.  This is then adjusted when ever the 
clock is set.  Up time is the difference between the saved boot time and the 
current wall clock time.
> 
> The clock doesn't tick when your laptop sleeps.

I would guess that the clock adjustment made when the sleep ends is not 
adjusting the boot time as it should.  That code should set the clock by calling 
do_settimeofday() which will do the right thing.

As to small drifts of ~170 PPM, they are caused by code (ps I would guess) that 
assumes that jiffies is exactly 1/HZ whereas it is NOT in the 2.6.* kernel.  The 
size of the jiffie that the kernel uses is returned by:

struct timespec tv;
:
:
clock_res(CLOCK_REALTIME, &tv);

This will be in nanoseconds (and must be as that is what the wall clock is in).
George

> I seem to recall recent changes to the way the
> boot time in /proc/stat gets reported. In any
> case, a sleeping laptop suggests some interesting
> questions about process run times.

> 
> Here's another one to make you scream: Linux does
> not supply real %CPU data.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml


  reply	other threads:[~2004-02-25 16:32 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 [this message]
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
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=403CCD3A.7080200@mvista.com \
    --to=george@mvista.com \
    --cc=albert@users.sourceforge.net \
    --cc=david+powerix@blue-labs.org \
    --cc=linux-kernel@vger.kernel.org \
    /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