From: Chad Reese <kreese@cavium.com>
To: Richard Cochran <richardcochran@gmail.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: Mon, 07 Jul 2014 14:03:38 -0700 [thread overview]
Message-ID: <53BB0B2A.3060708@cavium.com> (raw)
In-Reply-To: <20140707201156.GA10265@localhost.localdomain>
On 07/07/2014 01:11 PM, Richard Cochran wrote:
> On Mon, Jul 07, 2014 at 12:44:44PM -0700, Chad Reese wrote:
>>
>> A hardware timer used for ethernet timestamps is completely
>> independent from the kernel's software view of time. Since the
>> hardware timestamps are only exposed in the driver, how can they be
>> correlated with system time? If the driver doesn't do it, then
>> nobody else knows how.
>
> Um, implement a PTP Hardware Clock device?
Octeon does support using the 1588 clock as the kernel's clock source.
Unfortunately most people don't seem to want to use it. I have no idea why.
> 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.
>> For Octeon, you can optionally use the hardware timestamp as the
>> system clock reference. Most people don't, but it is the only way to
>> get the system time to be accurate. 1588 can synchronize two Octeon
>> boards to less than 1ns for the hardware timer. The Linux software
>> timers is always farther off.
>
> 1588 cannot synchronize boards unless you expose the clock to the
> userland PTP stack. Why don't you do that?
I was trying to stick with standard linux userspace APIs. People have no
interest in the PTP clock at all. All they want is for the standard
system time to be correct.
Chad
--
Chad Reese <kreese@cavium.com>
Cavium Networks
Phone: 408 - 943 - 7183
Cell: 321 - 438 - 7753
next prev parent reply other threads:[~2014-07-07 21:03 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 [this message]
2014-07-08 6:04 ` Richard Cochran
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=53BB0B2A.3060708@cavium.com \
--to=kreese@cavium.com \
--cc=davem@davemloft.net \
--cc=david.daney@cavium.com \
--cc=eric.dumazet@gmail.com \
--cc=kreese@caviumnetworks.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--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.