From: Octavian Purdila <opurdila@ixiacom.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: netdev@vger.kernel.org, Stephen Hemminger <shemminger@vyatta.com>,
Ingo Oeser <netdev@axxeo.de>, Andi Kleen <ak@linux.intel.com>,
"Ronciak, John" <john.ronciak@intel.com>
Subject: Re: hardware time stamps + existing time stamp usage
Date: Sat, 18 Oct 2008 22:37:01 +0300 [thread overview]
Message-ID: <200810182237.02373.opurdila@ixiacom.com> (raw)
In-Reply-To: <1224253423.17450.211.camel@ecld0pohly>
From: Patrick Ohly <patrick.ohly@intel.com>
Date: Fri, 17 Oct 2008 16:23:43 +0200
> The only solution that I see is to use one bit as flag to distinguish
> between hardware and software time stamps, as Octavian originally
> suggested.
There is one more approach that I think it could work.
Once hardware times-tamping has been enabled, the driver will:
a) compute the delta between the system time and the hardware time
b) store in the skb the hardware timestamp + delta (thus effectively using an
approximation of system time which I think it should be OK since system time
is not that precise anyway)
This is the approach that Stephen used in his patch for sky2. But we need
more, we need to get the "untainted" hardware timestamps to userspace.
And we can to that through a driver specific ioctl (or maybe via a new ethtool
method?):
hwtimestamp htimestamp_ioctl(timestamp)
{
return timestamp - delta;
}
There are some corner cases with this approach:
1. Reseting hardware timestamps. Our devices do that when the hardware
timestamps are synchronized across different cards, in which case hardware
timestamps are all reseted to zero.
We can easily detect this condition (current hardware timestamp < hardware
timestamp at the moment at which we computed the delta) and update the delta.
2. When the hardware is unable to generate a hardware timestamps (Patrick
mentioned that this may occur with certain hardware).
In that case the driver should generate a system time timestamp.
The problem here is that we want to distinguish between system and hardware
timestamps. A possible approach would be to use a slightly coarser precision
(say Xns instead of 1ns) and then use the modulo X to encode state into the
timestamp.
For example, we could say that hardware timestamp = (hwtimestamp/X)*X and
software timestamp = ((system time/X)*X) +1
Than, in the hwtimestamp_ioctl we can check if a received time is software or
hardware, and we can let the application know.
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).
Thanks,
tavi
next prev parent reply other threads:[~2008-10-18 19:57 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 [this message]
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
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=200810182237.02373.opurdila@ixiacom.com \
--to=opurdila@ixiacom.com \
--cc=ak@linux.intel.com \
--cc=john.ronciak@intel.com \
--cc=netdev@axxeo.de \
--cc=netdev@vger.kernel.org \
--cc=patrick.ohly@intel.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;
as well as URLs for NNTP newsgroup(s).