From: Roman Zippel <zippel@linux-m68k.org>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
George Anzinger <george@mvista.com>,
Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Subject: Re: [RFC][PATCH 2/2] Reduced NTP rework (part 2)
Date: Thu, 29 Sep 2005 20:43:40 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.61.0509291658130.3728@scrub.home> (raw)
In-Reply-To: <1127852362.8195.215.camel@cog.beaverton.ibm.com>
Hi,
On Tue, 27 Sep 2005, john stultz wrote:
> However, with you idea, on some arches we have to keep two timekeeping
> subsystems running at once, with code trying to smoothly synchronize
> them. I got a little frustrated trying to generate a clean
> implementation and decided to skip that idea for now. I'm not ruling it
> out, but I wanted to explore some other ideas I have.
>
> So I started playing with a few different approaches in the short term,
> trying to adapt some of your ideas (such as using fixed interval time
> accumulation to avoid the multiply at tick time) to my existing code.
I don't want to keep you from playing with different ideas, but I would
strongly suggest you do it first with an userspace simulator. If you
change too much, be prepared to do some sort of analysis of these changes.
A simulator would be one way, but plain math would be fine too.
It's really important that you get the math right first and then develop
the kernel model from that. It would also be ok if you do a first
prototype using nsec, but it's important to also look at the long term
stability of the clock and how well it works together with the NTP daemon.
> The idea being:
>
> update_wall_clock():
> ticks = jiffies - wall_jiffies
> while (ticks):
> ticks--
> xtime += tick_nsec + ntp_adjustment
>
>
> isn't that different from:
>
> timekeeping_periodic_hook():
> now = timesource_read(ts)
> delta_cycle = now - last
> while (delta_cycle > interval_cycle):
> delta_cycle -= interval_cycle
> system_time += interval_nsec
BTW that's not what you do in the first part of the patch:
+static void ntp_advance(unsigned long interval_ns)
I'm quite sure that the interval_ns is wrong, it's important to advance
the ntp state in constant intervals (i.e. interval_cycle). Your patch
already includes time adjustments and e.g. the "while (interval_ns >=
tick_nsec)" loop is not executed anymore, once time_adjust_step becomes
negative.
In general I would prefer it if we could finalize the basic design first,
before doing such changes, otherwise I'm afraid we need a cleanup of the
cleanup.
> The only difference between continuous and tick based systems would then
> be in gettimeofday() (which really could be the same with a simple
> #define)
>
> continuous_gettimeofday():
> now = timesource_read(ts)
> delta_cycle = now - last
> delta_nsec = cyc2ns(timesource, delta_cycle)
> return system_time + delta_nsec
>
> tick_gettime():
> now = timesource_read(jiffes_timesource)
> delta_cycle = now - last
> delta_nsec = cyc2ns(timesource, delta_cycle)
> delta_nsec += arch_get_offset()
> return system_time + delta_nsec
The basic idea of gettimeofday is of course always the same: "base +
get_offset() * mult". I can understand the temptation to unify the
implementation, but please accept the current reality that we have
different gettimeofday implementations (for whatever reasons), so unifying
them would be a premature change. If the situation changes later we can
still do that unification.
> Logic seen in the m68k time.c
I know that code and I really want to replace it with something better. :)
Unfortunately I didn't catch the crap introduced by nsec conversion.
bye, Roman
next prev parent reply other threads:[~2005-09-29 18:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-22 19:58 [RFC][PATCH 1/2] Reduced NTP rework (part 1) john stultz
2005-09-22 19:59 ` [RFC][PATCH 2/2] Reduced NTP rework (part 2) john stultz
2005-09-27 16:37 ` Roman Zippel
2005-09-27 20:19 ` john stultz
2005-09-27 21:57 ` Thomas Gleixner
2005-09-29 18:43 ` Roman Zippel [this message]
2005-09-29 19:33 ` john stultz
2005-10-10 12:39 ` Roman Zippel
2005-10-10 20:46 ` john stultz
2005-10-04 7:58 ` Ulrich Windl
2005-10-04 18:30 ` 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=Pine.LNX.4.61.0509291658130.3728@scrub.home \
--to=zippel@linux-m68k.org \
--cc=george@mvista.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.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;
as well as URLs for NNTP newsgroup(s).