From: Kingsley Cheung <kingsley@aurema.com>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [Bug 764] New: btime in /proc/stat wobbles (even over 30 seconds)
Date: Thu, 26 Jun 2003 09:47:02 +1000 [thread overview]
Message-ID: <20030626094702.J15047@aurema.com> (raw)
In-Reply-To: <1056155679.1028.22.camel@w-jstultz2.beaverton.ibm.com>; from johnstul@us.ibm.com on Fri, Jun 20, 2003 at 05:34:39PM -0700
On Fri, Jun 20, 2003 at 05:34:39PM -0700, john stultz wrote:
> On Wed, 2003-06-11 at 18:20, Kingsley Cheung wrote:
>
> > I see that there has been a fix made for this since 2.5.70-bk13 or
> > 2.5.70-bk14 that solves this problem by using the seqlock to ensure
> > that the jiffies and time of day are atomically read.
>
> And further then that, we loose less precision in some of the math so we
> don't have the single second wobbles that were initially seen.
>
>
> > However, wouldn't it be better to have the boottime calculated only
> > once so that it is independent of changes in the system time that may
> > occur later? Even with the fix with seqlock, the boottime can still
> > change back or forwards whenever the system time is set back or
> > forwards. IMHO an unchanging boottime that is independent of the time
> > of day is the best approach. Maybe something like the patch against
> > 2.5.70-bk14 that I've attached.
> >
> > What do people think?
>
> Really, I'm fine with the current semantics. At boot time the system
> clock may not have been correct, and was corrected only after NTP
> started up later in the boot sequence. So you could have some very funky
> btimes.
>
I guess that one of the tradeoffs to be considered for having a fixed
boottime. If after boot time NTP corrects the system time, then the
boot time would not change in accordance with NTP's correction.
> Even the current definition of btime = now - uptime has its own quirks
> (when systems are suspended uptime doesn't increment, etc) but I think
> its more likely to be correct then any other method (assuming the time
> now is more accurate then time at boot thanks to ntp or whatnot).
>
When you mention that quirk above, wouldn't that mean then that the
boottime would be off by the amount of time the system is suspended?
If uptime or jiffies is not updated but 'now' (the system time) is,
then btime would be pushed forward...
> I'm curious, how are people using the btime value? I'd think uptime and
> gettimeofday would be more useful bits of info, so I'd like to hear
> more.
Yes, that would be interesting to know.
Personally, I have been using it to determine when processes started.
Starttime, and some other process data that is recorded and presented
in /proc in jiffies. So to determine when a process started I took
that value, converted to seconds, and added it to btime. I was a bit
surpised to find that btime changed, however. And the way it is now
it'll still change whenever the system time is changed. However, at
least with the fix from 2.5.70, it doesn't wobble anymore due to loss
of precision.
--
Kingsley
prev parent reply other threads:[~2003-06-25 23:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-02 15:02 [Bug 764] New: btime in /proc/stat wobbles (even over 30 seconds) Martin J. Bligh
2003-06-02 15:08 ` Mike Dresser
2003-06-05 7:19 ` Kingsley Cheung
2003-06-06 2:26 ` Kingsley Cheung
2003-06-06 8:32 ` Herbert Xu
2003-06-06 12:08 ` Kingsley Cheung
2003-06-12 1:20 ` Kingsley Cheung
2003-06-21 0:34 ` john stultz
2003-06-25 23:47 ` Kingsley Cheung [this message]
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=20030626094702.J15047@aurema.com \
--to=kingsley@aurema.com \
--cc=johnstul@us.ibm.com \
--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