netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).