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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox