From: john stultz <johnstul@us.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
George Anzinger <george@mvista.com>,
frank@tuxrocks.com, Anton Blanchard <anton@samba.org>,
benh@kernel.crashing.org, Nishanth Aravamudan <nacc@us.ibm.com>,
Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Subject: Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
Date: Fri, 19 Aug 2005 19:32:31 -0700 [thread overview]
Message-ID: <1124505151.22195.78.camel@cog.beaverton.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0508182213100.3728@scrub.home>
On Fri, 2005-08-19 at 02:27 +0200, Roman Zippel wrote:
> On Tue, 16 Aug 2005, john stultz wrote:
> > Maybe to focus this productively, I'll try to step back and outline the
> > goals at a high level and you can address those.
> >
> > My Assumptions:
> > 1. adjtimex() sets/gets NTP state values
> > 2. Every tick we adjust those state values
> > 3. Every tick we use those values to make a nanosecond adjustment to
> > time.
> > 4. Those state values are otherwise unused.
> >
> > Goals:
> > 1. Isolate NTP code to clean up the tick based timekeeping, reducing the
> > spaghetti-like code interactions.
> > 2. Add interfaces to allow for continuous, rather then tick based,
> > adjustments (much how ppc64 does currently, only shareable).
>
> Cleaning up the code would be nice, but that shouldn't be the priority
> right now, first we should get the math right.
> I looked a bit more on this aspect of your patch and I think it's overly
> complex even for continuous time sources. You can reduce the complexity
> by updating the clock in more regular intervals.
I feel in some ways I do this (inside the second overflow loop), but
maybe I'm misunderstanding you.
> What basically is needed to update in constant intervals (n cycles) a
> reference time controlled via NTP and the system time. The difference
> between those two can be used to adjust the cycle multiplier for the next
> n cycles to speed up or slow down the system clock.
> Calculating the offset in constant intervals makes the math a lot simpler,
> basically the current code is just a special case of that, where it
> directly updates the system time from the reference time at every tick.
> (In the end the differences between tick based and continuous sources may
> be even smaller than your current patches suggest. :) )
That would be great! So, would you mind helping me scratch out some
pseudo code for your idea?
Currently we have something like:
===============================================
do_adjtimex():
set ntp_status/maxerror/esterror/constant values
set ntp_freq
set ntp_tick
if (singleshot_mode):
set ntp_adjtime_offset
else:
set ntp_offset
if appropriate, adjust ntp_freq
timer_interrupt():
if (second_overflow):
adjust ntp_maxerror/status
/* calculate per tick phase adjustment
using ntp_offset and ntp_freq
*/
sub_offset = math(ntp_offset)
ntp_offset -= sub_offset
phase_adj = math(sub_offset)
phase_adj += math(ntp_freq)
leapsecond_stuff()
tick_adjustment = 0;
/* calculate singleshot adjustment */
if (ntp_adjtime_offset):
adj = min(ntp_adjtime_offset, tick_adj)
ntp_adjtime_offset -= adj
tick_adjustment += adj
/* calculate the phase adjustment */
phase += phase_adj
if (phase > UNIT):
phase -= UNIT
tick_adjustment += UNIT
xtime += ntp_tick + tick_adjustment
gettimeofday():
return xtime + hardware_offset()
For continuous timesources, I'd like to see something like:
===============================================
do_adjtimex():
no changes, only the addition of
ntp_tick_ppm = calulate_ppm(ntp_tick)
timekeeping_perioidic_hook():
/* get ntp adjusted interval length*/
interval_length = get_timesource_interval(ppm)
/* accumulate the NTP adjusted interval */
xtime += interval_length
/* inform NTP state machine that we have
applied the last calculated adjustment for
the interval length
*/
ntp_interval += interval_length
while (ntp_interval > SECOND): /* just like second_overflow */
adjust ntp_maxerror/status
/* calculate the offset ppm adjustment */
sub_offset = math(ntp_offset)
ntp_offset -= sub_offset
offset_ppm = math(sub_offset)
/* same thing for single shot ntp_adjtime_offset */
sub_ss_offset = math(ntp_adjtime_offset)
ntp_adjtime_offset -= sub_ss_offset
ss_offset_ppm = math(sub_ss_offset)
/* sum up the ppm adjustments into a single ntp adjustment */
ppm = offset_ppm + ntp_freq + ss_offset_ppm + ntp_tick_ppm
leapsecond_stuff()
do_gettimeofday():
interval = get_timesource_interval(ppm)
return xtime + interval
Now could you adapt this to better show me what you're thinking of?
thanks
-john
next prev parent reply other threads:[~2005-08-20 2:32 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-11 1:21 [RFC - 0/13] NTP cleanup work " john stultz
2005-08-11 1:23 ` [RFC][PATCH - 1/13] NTP cleanup: Move NTP code into ntp.c john stultz
2005-08-11 1:25 ` [RFC][PATCH - 2/13] NTP cleanup: Move arches to new ntp interfaces john stultz
2005-08-11 1:26 ` [RFC][PATCH - 3/13] NTP cleanup: Remove unused NTP PPS code john stultz
2005-08-11 1:27 ` [RFC][PATCH - 4/13] NTP cleanup: Breakup ntp_adjtimex() john stultz
2005-08-11 1:28 ` [RFC][PATCH - 5/13] NTP cleanup: Break out leapsecond processing john stultz
2005-08-11 1:28 ` [RFC][PATCH - 6/13] NTP cleanup: Clean up ntp_adjtimex() arguement checking john stultz
2005-08-11 1:31 ` [RFC][PATCH - 7/13] NTP cleanup: Cleanup signed shifting logic john stultz
2005-08-11 1:31 ` [RFC][PATCH - 8/13] NTP cleanup: Integrate second_overflow() logic john stultz
2005-08-11 1:33 ` [RFC][PATCH - 9/13] NTP cleanup: Improve NTP variable names john stultz
2005-08-11 1:33 ` [RFC][PATCH - 10/13] NTP cleanup: Use ntp_lock instead of xtime_lock john stultz
2005-08-11 1:35 ` [RFC][PATCH - 11/13] NTP cleanup: Introduce PPM adjustment variables john stultz
2005-08-11 1:36 ` [RFC][PATCH - 12/13] NTP cleanup: cleanup ntp_advance() adjtime code john stultz
2005-08-11 1:38 ` [RFC][PATCH - 13/13] NTP cleanup: drop time_phase and time_adj add copyright john stultz
2005-08-16 2:08 ` [RFC][PATCH - 4/13] NTP cleanup: Breakup ntp_adjtimex() john stultz
2005-08-11 2:13 ` [RFC - 0/9] Generic timekeeping subsystem (v. B5) john stultz
2005-08-11 2:14 ` [PATCH 1/9] Timesource management code john stultz
2005-08-11 2:16 ` [PATCH 2/9] Generic timekeeping core subsystem john stultz
2005-08-11 2:18 ` [PATCH 3/9] Generic timekeeping i386 arch specific changes, part 1 john stultz
2005-08-11 2:19 ` [PATCH 4/9] generic timekeeping i386 arch specific changes, part 2 john stultz
2005-08-11 2:20 ` [PATCH 5/9] generic timekeeping i386 arch specific changes, part 3 john stultz
2005-08-11 2:21 ` [PATCH 6/9] generic timekeeping i386 arch specific changes, part 4 john stultz
2005-08-11 2:23 ` [PATCH 7/9] generic timekeeping i386 arch specific changes, part 5 john stultz
2005-08-11 2:24 ` [PATCH 8/9] generic timekeeping i386 arch specific changes, part 6 john stultz
2005-08-11 2:25 ` [PATCH 9/9] generic timekeeping i386 specific timesources john stultz
2005-08-11 2:32 ` [RFC - 0/9] Generic timekeeping subsystem (v. B5) Lee Revell
2005-08-11 2:39 ` john stultz
2005-08-11 2:44 ` Lee Revell
2005-08-11 6:17 ` Ulrich Windl
2005-08-11 2:37 ` [RFC] Cumulative NTP cleanujp and generic timekeeping patch (v B5) john stultz
2005-08-15 22:14 ` [RFC - 0/9] Generic timekeeping subsystem (v. B5) Roman Zippel
2005-08-16 0:10 ` john stultz
2005-08-16 18:25 ` Christoph Lameter
2005-08-16 23:48 ` john stultz
2005-08-17 0:14 ` Christoph Lameter
2005-08-17 0:17 ` john stultz
2005-08-17 0:21 ` Christoph Lameter
2005-08-17 6:08 ` Ulrich Windl
2005-08-17 14:07 ` Christoph Lameter
2005-08-17 0:28 ` Roman Zippel
2005-08-17 1:17 ` john stultz
2005-08-17 7:40 ` Ulrich Windl
2005-08-19 0:27 ` Roman Zippel
2005-08-20 2:32 ` john stultz [this message]
2005-08-21 23:19 ` Roman Zippel
2005-08-22 18:57 ` john stultz
2005-08-23 11:30 ` Roman Zippel
2005-08-23 18:52 ` john stultz
2005-08-23 20:51 ` john stultz
2005-08-23 21:34 ` Roman Zippel
2005-08-23 23:14 ` john stultz
2005-08-23 23:54 ` Roman Zippel
2005-08-24 0:29 ` George Anzinger
2005-08-24 20:36 ` john stultz
2005-08-24 23:46 ` George Anzinger
2005-08-25 0:42 ` john stultz
2005-08-25 1:44 ` George Anzinger
2005-08-25 2:13 ` john stultz
2005-08-24 6:34 ` Ulrich Windl
2005-08-24 9:47 ` Roman Zippel
2005-08-24 18:00 ` john stultz
2005-08-24 18:48 ` Roman Zippel
2005-08-24 19:15 ` john stultz
2005-08-24 19:49 ` Roman Zippel
2005-08-24 22:40 ` john stultz
2005-08-25 0:45 ` Roman Zippel
2005-08-25 18:08 ` john stultz
2005-08-17 19:03 ` George Anzinger
2005-08-15 22:12 ` [RFC - 0/13] NTP cleanup work " Roman Zippel
2005-08-15 22:46 ` john stultz
2005-08-17 0:10 ` Roman Zippel
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=1124505151.22195.78.camel@cog.beaverton.ibm.com \
--to=johnstul@us.ibm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=frank@tuxrocks.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nacc@us.ibm.com \
--cc=ulrich.windl@rz.uni-regensburg.de \
--cc=zippel@linux-m68k.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
all inboxes | Powered by JetHome®