From: Patrick Ohly <patrick.ohly@intel.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Octavian Purdila <opurdila@ixiacom.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Stephen Hemminger <shemminger@vyatta.com>,
Ingo Oeser <netdev@axxeo.de>,
"Ronciak, John" <john.ronciak@intel.com>
Subject: Re: hardware time stamps + existing time stamp usage
Date: Tue, 21 Oct 2008 09:40:39 +0200 [thread overview]
Message-ID: <1224574839.17450.332.camel@ecld0pohly> (raw)
In-Reply-To: <48FD7EF5.6050805@linux.intel.com>
On Tue, 2008-10-21 at 01:04 -0600, Andi Kleen wrote:
> > We can even compute the delta periodically now, to maintain better system -
> > hardware timestamps synchronization, as we can keep and multiple deltas (each
> > one associated with a modulo number).
>
> The problem with this scheme is that it's unlikely to be precise enough to guarantee
> monoticity (that is that your delta clock compared to the system clock never goes
> backwards). And that tends to be a common requirements in system time stamps.
> Not having that would risk breaking existing applications.
Agreed. But even those users who need absolute monoticity would be able
to use PTP: at least the Intel hardware would be configured to only time
stamp PTP packets while the application packets that the user cares
about are still time stamped in software, as before.
> My recommendation would be to find some way to use a separate field and also
> use a separate API. That would also allow you to extend it (e.g. pass down
> the interface number), so that different time stamps from different interfaces
> are supported.
The latest proposal already uses such a separate API for HW time stamps,
so we are fine in that regard. In my opinion the API should only return
information which isn't available otherwise (currently the original HW
time stamp); the interface number should be returned with the existing
IP_PKTINFO.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
prev parent reply other threads:[~2008-10-21 7:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-17 14:23 hardware time stamps + existing time stamp usage Patrick Ohly
2008-10-18 5:02 ` Eric Dumazet
2008-10-18 7:38 ` Oliver Hartkopp
2008-10-18 8:54 ` Eric Dumazet
2008-10-18 10:10 ` Oliver Hartkopp
2008-10-20 7:35 ` Patrick Ohly
2008-10-20 18:01 ` Oliver Hartkopp
2008-10-21 7:29 ` Patrick Ohly
2008-10-18 19:37 ` Octavian Purdila
2008-10-20 12:27 ` Patrick Ohly
2008-10-20 13:07 ` Octavian Purdila
2008-10-20 13:37 ` Patrick Ohly
2008-10-21 7:04 ` Andi Kleen
2008-10-21 7:40 ` Patrick Ohly [this message]
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=1224574839.17450.332.camel@ecld0pohly \
--to=patrick.ohly@intel.com \
--cc=ak@linux.intel.com \
--cc=john.ronciak@intel.com \
--cc=netdev@axxeo.de \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
--cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox