All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Date: Thu, 5 Jun 2003 09:53:48 -0700	[thread overview]
Message-ID: <20030605095348.C25414@mvista.com> (raw)
In-Reply-To: <20030605084852.GA25712@linux-mips.org>; from ralf@linux-mips.org on Thu, Jun 05, 2003 at 10:48:52AM +0200

On Thu, Jun 05, 2003 at 10:48:52AM +0200, Ralf Baechle wrote:
> On Thu, Jun 05, 2003 at 09:09:05AM +0100, Dominic Sweetman wrote:
> 
> > A naive network synchronisation protocol - analogous to your first
> > proposal - would leave clocks differing by a network round-trip time
> > or so: but NTP does a lot better.  So in principle you should be able
> > to scale NTP to create a clock synchronised within some fraction of
> > the time taken by a CPU-to-CPU communication... but compressing the
> > essence of the NTP protocol into something which runs fast enough
> > might be interesting!
> > 
> > My 5-minutes-over-breakfast feeling is that you should be able to
> > figure out a way to get time right enough; try reading up how NTP
> > works and see whether it can be made to work?
> 
> Yes, already been thinking about that.  The essence of NTP is a software
> implementation of a phase locked loop.  The full NTP protocol is way to
> heavy of course but the subset we're talking about would be rather
> lightweight.  I'd expect the phase noise to be in the low ppb range,
> little problems with unlocking.  And it'll be usable for arbitrary
> combinations of clock frequencies.  So an approach to try.
>

OK, I think you all convinced me that it is probably not a good
idea to do the synchronized CPU count registers, at least not until
we take a look of some alternatives.
 
> Enjoy your breakfast :-)
>

What are you eating?  I probably should have that when I was thinking
about this RFC. :)

In response to some other replies:

1) yes, it is always possible to use some external system-wide
timer source, if available, to solve this problem.  However, that could
get tricky too, and I wanted to do something generic which is hopefully 
applicable to more systems.

2) at least from my perspective, I see increasing demand for high
resolution timers that has monotonicity in both kernel space and user space.

Jun

  reply	other threads:[~2003-06-05 16:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-04 22:39 [RFC] synchronized CPU count registers on SMP machines Jun Sun
2003-06-04 22:51 ` Michael Uhler
2003-06-04 22:51   ` Michael Uhler
2003-06-04 23:44   ` Jun Sun
2003-06-04 23:15 ` Ralf Baechle
2003-06-04 23:46   ` Jun Sun
2003-06-05  0:12     ` Ralf Baechle
2003-06-05  1:38       ` Jun Sun
2003-06-05  8:09         ` Dominic Sweetman
2003-06-05  8:48           ` Ralf Baechle
2003-06-05 16:53             ` Jun Sun [this message]
2003-06-05 20:06               ` Greg Lindahl
2003-06-05 10:45       ` Alan Cox
2003-06-05  8:55     ` Kevin D. Kissell
2003-06-05  8:55       ` Kevin D. Kissell
2003-06-05  8:51       ` Ralf Baechle
2003-06-05 11:08       ` Maciej W. Rozycki
2003-06-05  0:18 ` Keith Owens
     [not found] <ralf@linux-mips.org>
2003-06-05  9:23 ` Tor Arntsen

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=20030605095348.C25414@mvista.com \
    --to=jsun@mvista.com \
    --cc=dom@mips.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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 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.