From: john stultz <johnstul@us.ibm.com>
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: lkml <linux-kernel@vger.kernel.org>,
tim@physik3.uni-rostock.de, george anzinger <george@mvista.com>,
albert@users.sourceforge.net, Len Brown <len.brown@intel.com>,
linux@dominikbrodowski.de, David Mosberger <davidm@hpl.hp.com>,
Andi Kleen <ak@suse.de>,
paulus@samba.org, schwidefsky@de.ibm.com,
keith maanthey <kmannth@us.ibm.com>, greg kh <greg@kroah.com>,
Patricia Gaughen <gone@us.ibm.com>,
Chris McDermott <lcm@us.ibm.com>, Max Asbock <amax@us.ibm.com>,
mahuja@us.ibm.com
Subject: Re: [RFC] New timeofday proposal (v.A1)
Date: Thu, 09 Dec 2004 00:29:52 -0800 [thread overview]
Message-ID: <1102580992.7511.10.camel@leatherman> (raw)
In-Reply-To: <41B81364.5446.EEE6E75@rkdvmks1.ngate.uni-regensburg.de>
On Thu, 2004-12-09 at 08:57 +0100, Ulrich Windl wrote:
> On 8 Dec 2004 at 15:36, john stultz wrote:
>
> [...]
> > Take a look at the adjtimex man page as well as the ntp.c file from the
> > timeofday core patch. There are number of different types of adjustments
> > that are made, possibly at the same time. Briefly, they are (to my
> > understanding - I'm going off my notes from awhile ago):
> > o tick adjustments
> > how much time should pass in a _user_ tick
>
> tick adjustments are considered obsolete, because if a lcok implementation (or
> hardware) is severly broken, users should reject using that stuff. Meaning: tick
> adjustments are ment to be set once in the life of a computer system. No
> continuous tuning.
>
> > o frequency adjustments
> > long term adjustment to correct for constant drift),
>
> Actually, you are compensating for a "tick problem" on a smaller scale (constant
> part), and variations caused by temperature, voltage, and others (variable part).
>
> > o offset adjustments
> > additional ppm adjustment to correct for current offset from the ntp
> > server
> > o single shot offset adjustments
> > old style adjtime functionality
> >
> > Tick, frequency and offset adjustments can be precalculated and summed
> > to a single ppm adjustment. This is similar to the style of adjustment
> > you propose directly onto the time source frequency values.
> >
> > However, there is also this short term single shot adjustments. These
> > adjustments are made by applying the MAX_SINGLESHOT_ADJ (500ppm) scaling
> > for an amount of time (offset_len) which would compensate for the
> > offset. This style is difficult because we cannot precompute it and
> > apply it to an entire tick. Instead it needs to be applied for just a
> > specific amount of time which may be only a fraction of a tick. When we
>
> Yes, that's the "precise" variant of implementing it. Poor implementations are
> just accurate to one tick.
Thanks for your knowledgeable clarifications. Its good to know someone
out there deeply understands this stuff more then at a "this is what the
code is doing, and I have my own interpretation as to why" level. :)
thanks again,
-john
next prev parent reply other threads:[~2004-12-09 8:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-08 1:55 [RFC] New timeofday proposal (v.A1) john stultz
2004-12-08 1:56 ` [RFC] new timeofday core subsystem (v.A1) john stultz
2004-12-08 1:57 ` [RFC] new timeofday arch specific hooks (v.A1) john stultz
2004-12-08 1:58 ` [RFC] new timeofday timesources (v.A1) john stultz
2004-12-08 2:02 ` john stultz
2004-12-08 9:17 ` [RFC] new timeofday core subsystem (v.A1) Pavel Machek
2004-12-08 18:44 ` Christoph Lameter
2004-12-08 19:22 ` john stultz
2004-12-08 18:53 ` Christoph Lameter
2004-12-08 20:27 ` Martin Waitz
[not found] ` <1102555933.1281.301.camel@cog.beaverton.ibm.com>
2004-12-09 7:32 ` Martin Waitz
2004-12-08 18:25 ` [RFC] New timeofday proposal (v.A1) Christoph Lameter
2004-12-08 19:11 ` john stultz
2004-12-08 19:20 ` Christoph Lameter
2004-12-08 19:58 ` john stultz
2004-12-08 20:14 ` Christoph Lameter
2004-12-08 21:25 ` George Anzinger
2004-12-08 23:47 ` Christoph Lameter
2004-12-08 23:36 ` john stultz
2004-12-08 23:53 ` Christoph Lameter
2004-12-09 0:17 ` john stultz
2004-12-09 0:40 ` Christoph Lameter
2004-12-09 0:51 ` john stultz
2004-12-09 1:24 ` Christoph Lameter
2004-12-09 7:57 ` Ulrich Windl
2004-12-09 8:29 ` john stultz [this message]
2004-12-09 7:47 ` Ulrich Windl
2004-12-08 18:43 ` Nicolas Pitre
2004-12-08 18:57 ` john stultz
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=1102580992.7511.10.camel@leatherman \
--to=johnstul@us.ibm.com \
--cc=ak@suse.de \
--cc=albert@users.sourceforge.net \
--cc=amax@us.ibm.com \
--cc=davidm@hpl.hp.com \
--cc=george@mvista.com \
--cc=gone@us.ibm.com \
--cc=greg@kroah.com \
--cc=kmannth@us.ibm.com \
--cc=lcm@us.ibm.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.de \
--cc=mahuja@us.ibm.com \
--cc=paulus@samba.org \
--cc=schwidefsky@de.ibm.com \
--cc=tim@physik3.uni-rostock.de \
--cc=ulrich.windl@rz.uni-regensburg.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.