[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5B860B0D7BC1B74498C0C6D8C6E39A4F1E2FFA1E@irsmsx503.ger.corp.intel.com>
Date: Thu, 13 Nov 2008 16:05:21 +0000
From: "Ohly, Patrick" <patrick.ohly@...el.com>
To: Oliver Hartkopp <oliver@...tkopp.net>
CC: Andi Kleen <ak@...ux.intel.com>,
Eric Dumazet <dada1@...mosbay.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Octavian Purdila <opurdila@...acom.com>,
Stephen Hemminger <shemminger@...tta.com>,
Ingo Oeser <netdev@...eo.de>,
"Ronciak, John" <john.ronciak@...el.com>
Subject: RE: [RFC PATCH 00/13] hardware time stamping + igb example
implementation
Oliver Hartkopp wrote:
> one question about a new crazy idea:
>
> If we would tend to add new space in the skb, won't 4 bytes enough then?
>
> A 32 bit value gives a nsec resolution of 4.294967296 seconds or +/-
> 2.147483648 seconds.
>
> If we make a 'full qualified' 64 bit sys-timestamp available anyway, the
> new 32 bit value could be used as an offest (or it could be given to the
> userspace directly) to calculate the hw timestamp within the
> sys-timestamp context, right?
The sys-timestamp is normally not generated. The offset scheme would
add a call to gettimeofdayns() even if there is no other use for the
value. This might be acceptable; the bigger problem IMHO is that without
tracking system time in the hardware, hardware and system time will quickly
(~ a few days with the hardware I was looking at, if I remember correctly)
diverge more than can be stored in the 32 bit offset.
I'd prefer to spend 64 bits and be done without the need for further
encoding hacks.
Bye, Patrick
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists