mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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





  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®