From: Eli Carter <eli.carter@inet.com>
To: Russell King <rmk@arm.linux.org.uk>,
Jamie Lokier <lk@tantalophile.demon.co.uk>,
linux-kernel@vger.kernel.org
Subject: Re: gettimeofday question
Date: Wed, 21 Mar 2001 16:27:13 -0600 [thread overview]
Message-ID: <3AB92AC1.DF054E2E@inet.com> (raw)
In-Reply-To: <200103192134.VAA01785@raistlin.arm.linux.org.uk> <3AB927D0.F152717D@inet.com>
Eli Carter wrote:
>
> Russell King wrote:
> >
> > Eli Carter writes:
> > > What are you seeing that I'm missing?
> >
> > Ok, after sitting down and thinking again about this problem, its not
> > the 9.9999ms case, but the 10.000000001 case:
> [snip]
> > Like I say, this requires good timing to create, so may not be too much of
> > a problem, but it does seem to be a problem that could occur.
>
> It appears that this problem is easier to create than we originally gave
> credit for.... All that is needed is for gettimeoffset() not to be
> called for a _minimum_ of >10ms, and for the timer to wrap during a call
> to do_gettimeofday() or during a period of time where interrupts are
> disabled and do_gettimeofday() is called. Note that there is no upper
> limit to the time...
>
> If we call gettimeoffset() after do_timer() returns (and there-by update
> the internal variables every 10ms), we should reduce the impact of this
> bug dramatically (in theory--in practice, disabling interrupts for long
> periods can also have some bad effects that this won't help, but I think
> that's another issue.)
>
> One of the guys I'm working with did some testing on this, and he was
> seeing this problem (off by 10ms) every 5 to 10 minutes (on a modified
> ARM & kernel). With the additional gettimeoffset() call, he no longer
> saw it (at least within ~3hrs.).
>
> Questions, comments, etc.?
Another thought...
If we pull count_p and jiffies_p out of the various *_gettimeoffset()
functions, and added an updatetimeoffset() that only updated count_p and
jiffies_p, (and called it after every do_timer(),) we'd accomplish the
same thing, but with less overhead.
(This is based on looking at the ARM code; I haven't fully studied the
x86 & others.)
Questions, comments, etc?
Eli
-----------------------. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
eli.carter(at)inet.com `------------------ helps if you know the answer.
next prev parent reply other threads:[~2001-03-21 22:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-03 12:49 gettimeofday question Russell King
2001-03-03 16:24 ` Russell King
2001-03-19 7:33 ` Russell King
2001-03-19 11:39 ` Jamie Lokier
2001-03-19 18:26 ` Eli Carter
2001-03-19 19:06 ` Russell King
2001-03-19 19:49 ` Eli Carter
2001-03-19 21:34 ` Russell King
2001-03-19 22:54 ` Eli Carter
2001-03-19 23:44 ` Russell King
2001-03-20 15:27 ` Eli Carter
2001-03-21 22:14 ` Eli Carter
2001-03-21 22:27 ` Eli Carter [this message]
2001-03-21 23:10 ` Eli Carter
2001-03-21 23:27 ` Question on binutils release to use Anthony Barbachan
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=3AB92AC1.DF054E2E@inet.com \
--to=eli.carter@inet.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lk@tantalophile.demon.co.uk \
--cc=rmk@arm.linux.org.uk \
/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