linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Richard Cochran <richardcochran@gmail.com>,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org, linux-api@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
	Arnd Bergmann <arnd@arndb.de>, David Miller <davem@davemloft.net>,
	John Stultz <johnstul@us.ibm.com>,
	Krzysztof Halasa <khc@pm.waw.pl>,
	Peter Zijlstra <peterz@infradead.org>,
	Rodolfo Giometti <giometti@linux.it>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
Date: Thu, 23 Sep 2010 13:36:41 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1009231327000.2962@router.home> (raw)
In-Reply-To: <AANLkTim0JqVTyvrvjLRp1Cg423MdrwmyZG2uN6uSyeLb@mail.gmail.com>

On Thu, 23 Sep 2010, Jacob Keller wrote:

> > There is a reason for not being able to shift posix clocks: The system has
> > one time base. The various clocks are contributing to maintaining that
> > sytem wide time.
> >
> > Adjusting clocks is absolutely essential for proper functioning of the PTP
> protocol. The slave obtains and calculates the offset from master and uses
> that in order to adjust the clock properly, The problem is that the
> timestamps are done via the hardware. We need a method to expose that
> hardware so that the ptp software can properly adjust those clocks.

There is no way to use that clock directly to avoid all the user space
tuning etc? There are already tuning mechanisms in the kernel that do this
with system time based on periodic clocks. If you calculate the
nanoseconds since the epoch then you should be able to use that to tune
system time.

> > I do not understand why you want to maintain different clocks running at
> > different speeds. Certainly interesting for some uses I guess that I
> > do not have the energy to imagine right now. But can we get the PTP killer
> > feature of synchronized accurate system time first?
> >
>
> The problem is maintaining a hardware clock at the correct speed/frequency
> and time. The timestamping is done via hardware, and that hardware clock
> needs to be accurate. We need to be able to modify that clock. Yes, having
> the system time be the same value would be nice, but the problem comes
> because we don't want to jump through hoops to keep that hardware clock
> accurate to the ptp protocol running on the network.

Then allow system time == hardware clock?

> All of the necessary features for microsecond or better accuracy are done
> via the hardware. You can get accuracy to within <10 mircoseconds while only
> sending sync packets and such once per second. The reason is because the
> hardware timestamps are very accurate. But if we can't properly adjust the
> clocks time and frequency, we cannot maintain the accuracy of the
> timestamps.

You can already adjust the system time with the existing APIs. Tuning
hardware clocks is currently done using device specific controls. But I
would think that you do not need to expose this to user space if you can
do it all in kernel.

  reply	other threads:[~2010-09-23 18:36 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-23 17:30 [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support Richard Cochran
2010-09-23 17:31 ` [PATCH 1/8] posix clocks: introduce a syscall for clock tuning Richard Cochran
     [not found]   ` <b94ef1cd9c04ef3ad5964408bd0af7251add78de.1285261534.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
2010-09-23 19:48     ` john stultz
     [not found]       ` <1285271331.2587.56.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-09-24  7:29         ` Richard Cochran
     [not found]           ` <20100924072946.GA5043-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
2010-09-24 17:55             ` john stultz
2010-09-23 22:03     ` Benjamin Herrenschmidt
2010-09-23 22:12       ` Thomas Gleixner
     [not found]         ` <alpine.LFD.2.00.1009240008390.2416-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
2010-09-24  1:20           ` Benjamin Herrenschmidt
2010-09-24  7:55       ` Richard Cochran
     [not found]         ` <20100924075534.GB5043-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
2010-09-24 22:12           ` Benjamin Herrenschmidt
2010-09-23 17:31 ` [PATCH 2/8] posix clocks: dynamic clock ids Richard Cochran
2010-09-23 17:31 ` [PATCH 3/8] posix clocks: introduce a sysfs presence Richard Cochran
     [not found] ` <cover.1285261533.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
2010-09-23 17:32   ` [PATCH 4/8] ptp: Added a brand new class driver for ptp clocks Richard Cochran
2010-09-23 17:32 ` [PATCH 5/8] ptp: Added a simulated PTP hardware clock Richard Cochran
2010-09-23 17:33 ` [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx Richard Cochran
     [not found]   ` <57b64051c816dc9cb856bbb9f38fc901c9d3d651.1285261535.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
2010-09-23 19:17     ` Christoph Lameter
     [not found]       ` <alpine.DEB.2.00.1009231348150.2962-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2010-09-23 20:43         ` Alan Cox
     [not found]           ` <20100923214359.3f287b11-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2010-09-23 20:32             ` Christoph Lameter
2010-09-23 21:26           ` Christian Riesch
2010-09-24 11:52             ` Alan Cox
2010-09-24  8:49         ` Richard Cochran
2010-09-23 17:33 ` [PATCH 7/8] ptp: Added a clock driver for the IXP46x Richard Cochran
2010-09-23 17:34 ` [PATCH 8/8] ptp: Added a clock driver for the National Semiconductor PHYTER Richard Cochran
2010-09-23 17:53 ` [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support Christoph Lameter
2010-09-23 18:21   ` Jacob Keller
2010-09-23 18:36     ` Christoph Lameter [this message]
     [not found]   ` <alpine.DEB.2.00.1009231238170.2962-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2010-09-23 18:59     ` john stultz
     [not found]       ` <1285268380.2587.11.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-09-23 19:15         ` Christoph Lameter
2010-09-23 20:28           ` john stultz
2010-09-23 20:49             ` Christoph Lameter
     [not found]               ` <alpine.DEB.2.00.1009231533040.7522-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2010-09-23 21:34                 ` Alan Cox
2010-09-23 21:34                   ` Christian Riesch
     [not found]                     ` <4C9BC7CE.8020400-U4+xqT1Vg0VeoWH0uzbU5w@public.gmane.org>
2010-09-27 15:37                       ` Christoph Lameter
2010-09-30  3:50                         ` Christian Riesch
2010-10-02  1:44                         ` M. Warner Losh
2010-09-23 21:42                 ` john stultz
     [not found]                   ` <1285278136.2587.154.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-09-27 15:52                     ` Christoph Lameter
2010-09-27 16:14                       ` M. Warner Losh
     [not found]                         ` <20100927.101423.702773873740300798.imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org>
2010-09-28  6:34                           ` Richard Cochran
2010-09-24  8:33     ` Richard Cochran
2010-09-23 19:38 ` john stultz
     [not found]   ` <1285270733.2587.46.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-09-24 13:50     ` Richard Cochran
     [not found]       ` <20100924135001.GB3113-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
2010-09-24 14:57         ` Alan Cox
2010-09-23 20:36 ` Alan Cox
2010-09-23 20:49   ` john stultz
     [not found]     ` <1285274952.2587.113.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-09-23 21:30       ` Alan Cox
2010-09-23 22:03         ` john stultz
     [not found]   ` <20100923213654.0c64b047-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2010-09-24 13:14     ` Richard Cochran
     [not found]       ` <20100924131407.GA3113-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
2010-09-24 14:02         ` Alan Cox
2010-09-24 14:07           ` Alan Cox
2010-09-27 15:56           ` Christoph Lameter
2010-09-27 17:05             ` Alan Cox
2010-09-28  6:47               ` Richard Cochran

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=alpine.DEB.2.00.1009231327000.2962@router.home \
    --to=cl@linux.com \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=giometti@linux.it \
    --cc=jacob.keller@gmail.com \
    --cc=johnstul@us.ibm.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=richardcochran@gmail.com \
    --cc=tglx@linutronix.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).