[Linuxptp-users] Fwd: Installation of Linuxptp on Ubuntu PC

[Guo H. <gh...@gm...>]

Hi Richard,

Thanks a lot for the clarification.

#The ToD is really only telling your endace card the *approximate* date
#and time.  Your endace card phase locks (not just frequency locks) to
#the PPS.

Hence the working principle would be as:
1. The Endace card might get the ToD second (from NTP or PTP) before the
accurate 1-PPS or after the 1-PPS
2. If the ToD second comes first then 1-PPS comes later, Endace card would
record the ToD second and match that second to the moment when it really
receives the 1-PPS.
3. If the 1-PPS comes first and ToD second comes later, Endace card would
add some offset to the ToD second to make that align to the 1-PPS.

Is my understanding correct or not?
Still not that clear on how the Endace card coordinate NTP ToD with PPS and
can you give more clues?


> As far as I know, the GPS clock might already did something about the
> egress and ingress latency.

# And just how do you know that?

# It cannot possibly know the ingress latency of the Endace card.)

Sorry to confuse you.
What I want to say is that the GPS clock would have already compensate the
egress latency of the PTP messages introduced by itself as well as the
ingress latency of the PTP messages introduced by itself.
It is for sure that the GPS clock does not know the ingress latency of the
Endace card.
According to the one of the GPS clock manufacturer, their egress latency
should be less than 100 ns.


To sum up the installation of Linuxptp on Ubuntu:
1. Check the kernel version of Ubuntu by command "uname -a". Ubuntu 14.04
kernel version 3.16 has already supported PTP features and there is no need
to compile own kernel.
2. Check whether the Network Interface Card (NIC) supports hardware
timestamping by command "ethtool -T eth0 (NIC name)". Intel 82574 NIC
supports hardware timestamping.
3. Download Linuxptp source code (tarball) from
http://linuxptp.sourceforge.net/
4. Untar the tarball and change to the directory; then type command "make"
to compile the source code
5. Check whether the program works by command "./ptp4l -E -2 -H -i eth0 -m
-q"; for help menu of ptp4l, type "./ptp4l -h"
6. Install the the source code by "make install"
7. After successful installation of Linuxptp, could run program ptp4l, pmc
and phc2sys directly from terminal / command line.
8. "ptp4l -h", "pmc -h", "pmc help" and "phc2sys -h" for help of the
programs ptp4l, pmc and phc2sys


Best regards,
     Hao



On 30 August 2015 at 15:01, Richard Cochran <ric...@gm...>
wrote:

> On Sat, Aug 29, 2015 at 08:35:56PM +0100, Guo Hao wrote:
> > But what if there is certain time offset between GPS clock's ToD and host
> > PC's ToD, say 3 us when the capture card gets its initial ToD from the
> PC.
> > Then even the capture has 1-PPS from the GPS clock, the timestamp
> > difference would be in the range of 3 us?
>
> The ToD is really only telling your endace card the *approximate* date
> and time.  Your endace card phase locks (not just frequency locks) to
> the PPS.
>
> Endace said:
>
> > Yes, your understanding is correct: the host clock sets the DAG’s initial
> > TOD for time stamping and the PPS keeps the oscillator on the DAG from
> > drifting. This way once the initial TOD is established if the DAG has
> > proper sync the largest possible timing skew would be a few
> > nanoseconds.
>
> and I said:
>
> > # so the ToD from the host is irrelevant.  The capture has the GPS's
> > # 1-PPS, and so the phase of its time stamps should be correct to a few
> > # hundred nanoseconds.
>
> See how you got the same answer twice?
>
> > As far as I know, the GPS clock might already did something about the
> > egress and ingress latency.
>
> And just how do you know that?
>
> (It cannot possibly know the ingress latency of the Endace card.)
>
> > Therefore, I guess most of the latency might be introduced by the capture
> > card.
>
> Could be.
>
> Cheers,
> Richard
>