All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Chad Reese <kreese@cavium.com>
Cc: Willem de Bruijn <willemb@google.com>,
	netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Chad Reese <kreese@caviumnetworks.com>,
	David Daney <david.daney@cavium.com>
Subject: Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct
Date: Tue, 8 Jul 2014 08:04:41 +0200	[thread overview]
Message-ID: <20140708060441.GB3977@localhost.localdomain> (raw)
In-Reply-To: <53BB0B2A.3060708@cavium.com>

On Mon, Jul 07, 2014 at 02:03:38PM -0700, Chad Reese wrote:
> On 07/07/2014 01:11 PM, Richard Cochran wrote:
> >Don't reimplement clock servos in your driver. Instead, leave that to
> >the PTP stack (like using linuxptp's phc2sys).
> 
> I obviously did it wrong. The one line comment in
> Documentation/networking/timestamping.txt was not enough for me to
> figure out the proper usage of syststamp.

Sorry about not having clearly deprecated syststamp. We'll do that now.
Next time, putting the PTP maintainer on CC will help catch such things.
 
> I was trying to stick with standard linux userspace APIs.

There is a standard PTP hardware clock subsystem and API, as explained
in Documentation/ptp/ptp.txt.  

> People
> have no interest in the PTP clock at all. All they want is for the
> standard system time to be correct.

You can't have the time correct unless you synchronize it to
something. That is what NTP and PTP are all about. When using a PTP
hardware clock, it is necessary to synchronize the Linux system time
to it. The right way to accomplish this is using a userland PTP
stack, and the wrong way is to implement a servo in every last MAC
driver.

What I don't understand is, how does your device get the PTP time
without running the PTP protocol?

How can your device work without implementing a PTP clock? What am I
missing?

Thanks,
Richard

  reply	other threads:[~2014-07-08  6:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-03 19:39 net-timestamp: MSG_TSTAMP flags and bytestream support Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING ancillary data struct Willem de Bruijn
2014-07-05 20:10   ` Richard Cochran
2014-07-18 15:54     ` Willem de Bruijn
2014-07-05 20:18   ` Richard Cochran
2014-07-07 15:34     ` Willem de Bruijn
2014-07-07 18:47       ` Richard Cochran
2014-07-07 19:14         ` Willem de Bruijn
2014-07-07 19:44           ` Chad Reese
2014-07-07 20:11             ` Richard Cochran
2014-07-07 21:03               ` Chad Reese
2014-07-08  6:04                 ` Richard Cochran [this message]
2014-07-08  7:42                   ` Chad Reese
2014-07-08  9:41                     ` Richard Cochran
2014-07-10 15:36                       ` Willem de Bruijn
2014-07-07 20:18             ` Richard Cochran
2014-07-07 21:08               ` Chad Reese
2014-07-08  5:49                 ` Richard Cochran
2014-07-08  6:08                   ` Richard Cochran
2014-07-03 19:39 ` [PATCH net-next v2 2/8] net-timestamp: MSG_TSTAMP one-shot tx timestamps Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 3/8] net-timestamp: tx timestamp without payload Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 4/8] net-timestamp: TCP timestamping Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 5/8] net-timestamp: ACK timestamp for bytestreams Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 6/8] net-timestamp: ENQ timestamp on enqueue to traffic shaping layer Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 7/8] net-timestamp: expand documentation Willem de Bruijn
2014-07-05 20:14   ` Richard Cochran
2014-07-07 15:40     ` Willem de Bruijn
2014-07-03 19:39 ` [PATCH net-next v2 8/8] net-timestamp: SOCK_RAW and PING timestamping Willem de Bruijn

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=20140708060441.GB3977@localhost.localdomain \
    --to=richardcochran@gmail.com \
    --cc=davem@davemloft.net \
    --cc=david.daney@cavium.com \
    --cc=eric.dumazet@gmail.com \
    --cc=kreese@cavium.com \
    --cc=kreese@caviumnetworks.com \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=willemb@google.com \
    /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.