From: David Ford <david+powerix@blue-labs.org>
To: Albert Cahalan <albert@users.sourceforge.net>
Cc: 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 00:10:46 -0500 [thread overview]
Message-ID: <403C2E56.2060503@blue-labs.org> (raw)
In-Reply-To: <1077674048.10393.369.camel@cube>
Albert Cahalan wrote:
>On Tue, 2004-02-24 at 20:58, David Ford wrote:
>
>
>>Kernel 2.6.3, procps 3.2.0
>>
>># while [ 1 ]; do (ps aux|grep "grep ps aux" && date) ; sleep 1; done
>>root 20043 0.0 0.0 1504 456 pts/0 R 20:45 0:00 grep grep ps aux
>>Tue Feb 24 20:45:25 EST 2004
>>root 20062 0.0 0.0 1504 460 pts/0 S 20:45 0:00 grep grep ps aux
>>Tue Feb 24 20:45:26 EST 2004
>>root 20081 0.0 0.0 1504 460 pts/0 S 20:46 0:00 grep grep ps aux
>>Tue Feb 24 20:45:27 EST 2004
>>
>>Note the change in the timestamp as reported by 'ps' v.s. the time
>>reported by 'date'.
>>
>>Repeatable every time at 26 seconds after the minute +/- a portion of a
>>second.
>>
>>
>
>I'm not seeing it, with:
>
>procps both 3.1.8 and procps 3.2.0+
>kernel 2.6.0-test11
>library glibc 2.3
>hardware uniprocessor G4 Mac
>ntp none (and you can tell by my email!)
>
>Run "ps --info" to gather much of this data.
>
>Note that time is a very awkward thing. You boot up,
>with some incorrect clock. Then you adjust the time.
>Later, you may discover that your clock has been
>running too slow. So you adjust the frequency, but
>what about the time that has already passed? Should
>you change the boot time to represent what is now
>known about your clock? What if, by doing so, you
>cause some processes to have started before boot?
>Then again, perhaps due to temperature change, you
>discover that your clock frequency is wrong... This
>is without even getting into the concept of leap
>seconds, which are determined a few months in advance.
>
>Two guesses:
>
>1. leap seconds
>2. SMP, with cycle counters out of sync
>
>
I'm seeing it on two machines now, I'm going to test on more machines as
I get access. The second machine is my notebook with procps 3.1.15 on
it, and it does it at the 46 second mark, also 2.6.3.
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?
powerix conf.d # ps --info
BSD j OL_j
BSD l OL_l
BSD s OL_s
BSD u OL_u
BSD v OL_v
SysV -f (none)
SysV -fl (none)
SysV -j (none)
SysV -l (none)
procps version 3.1.15
Linux version 2.6.3
Compiled with: glibc 2.3, gcc 3.3
header_gap=-1 lines_to_next_header=1
screen_cols=91 screen_rows=29
personality=0x00000000 (from "unknown")
EUID=0 TTY=136,3 Hertz=100 PAGE_SIZE=4096 page_size=4096
sizeof(proc_t)=492 sizeof(long)=4 sizeof(KLONG)=4
archdefs: i386
namelist_file="<no System.map file>"
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
David
next prev parent reply other threads:[~2004-02-25 5:11 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 [this message]
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
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=403C2E56.2060503@blue-labs.org \
--to=david+powerix@blue-labs.org \
--cc=albert@users.sourceforge.net \
--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 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.