Hello Patrick,

Patrick Ohly wrote:
quoted text
> This patch series was discussed before on linux-netdev ("hardware
> time stamping + igb example implementation").
(..)

quoted text
> This patch now adds a 8 byte field unconditionally.

This looks really better to me :-)

quoted text
> There's one unsolved problem, though: time synchronization with
> PTP (the use case I'm working on) requires a transformation of
> raw hardware time stamps into system time. Currently this is done
> at the socket level by finding the device which created the time
> stamp and letting it do the transformation. This fails for
> incoming packets because skb->rt points to the "lo" device.
>
> Perhaps the interface number can be used to find the real
> hardware device. Alternatively the conversion could be done when
> generating the time stamp (might also be more accurate), but then
> another 8 byte field is needed. Delta encoding won't help because
> one cannot assume that hardware time stamps track system time
> closely enough.
>   

I still have two questions of understanding regarding these (offset) 
transformations that make it still difficult:

1. As no one has an insight of how the specific hardware generates the 
hw time stamp anyway, why can't you put the already transformed values 
into the hw timestamp field? I won't stick on the fact that the hw time 
stamp is the value that has been read from specific controller registers 
that are very hardware depended.

2. From what i've read in the discussion, i understood that the hardware 
clock and the system clock skew. Assuming both to be strong 
monotonic(?), is there a linear skew observable from your testing 
experiences?

If so i would suggest to have some kind of sysfs entry like e.g.

/sys/class/net/eth0/hwstamp_skew_ns

that gives something like

-86234765@12277656012584334095

as output. In general:

<skew_in_ns>@<systemtime>

So if you would check this sysfs entry two or more times, you would get 
an impression about the hw time stamp behaviour of your hardware by 
simply calculating the linear (timedepended) offset based on several 
'skew-sample-points', right?

I hope these suggestions are not completely damaged ;-)

Best regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html