Hi Richard,
Thanks a lot the reply.
# 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.
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?
Since the 1-PPS just trains the internal oscillator of the capture and its
timestamp only ticks forward based on the 1-PPS.
I am not sure whether my understanding is correct or not.
Below is the feedback I got from the Endace support (DAG is the capture
card):
Hi Hao,
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. If
for some reason the delta between the DAG and the host clock becomes too
great (1 second in older drivers, 0.5 seconds in newer drivers) the DAG
card will automatically reset the TOD to the new value and resync. Other
than that, the DAG will always maintain TOD based off of the initial start,
with the PPS as it’s tick corrector.
However, if the ToD does matter, then the result should be totally
different when using NTP and PTP.
That is a bit strange...
# The ~1 usec difference is probably just the sum of the GPS device's
# egress latency and the capture card's ingress latency. The number is
# perfectly reasonable, if one or both of the devices has MAC time
# stamping.
As far as I know, the GPS clock might already did something about the
egress and ingress latency.
Therefore, I guess most of the latency might be introduced by the capture
card.
It is also interesting that when I use the capture card under Windows 7, it
gave me the time difference in the range of 3.4 - 3.7 us.
Best regards,
Hao
On 29 August 2015 at 19:09, Richard Cochran <[email protected]>
wrote:
> On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote:
> > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay
> > 825
> >
> > Does this mean the clock offset between the 82574 NIC and the Master
> Clock
> > is in the range less than 100 ns?
>
> Yes.
>
> > Does that mean the system time is synchronized to the ptp hardware clock
> on
> > the 82574 NIC?
>
> Yes, but remember that there is probably some offset in the low
> microseconds range. The "delay" tells you that reading the PHC time
> over the PCIe bus takes about 13 microseconds.
>
> > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu:
> >
> > root@Hao-Ubuntu:~# service ptp4l start
> > ptp4l: unrecognized service
> > root@Hao-Ubuntu:~#
> >
> > Any idea on this?
>
> Just start the programs by hand. To start them automatically, one
> easy way is to put the commands into /etc/rc.local.
>
> > Therefore, I doubt whether there is a inherent delay between the point
> when
> > the Ethernet capture card request for the ToD and point the Ethernet
> > capture card really gets the information or the system time is not
> > synchronized by the hardware clock of the 82574 NIC.
>
> But you said,
>
> the Ethernet capture card gets the 1-PPS from the same GPS clock.
>
> 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.
>
> The ~1 usec difference is probably just the sum of the GPS device's
> egress latency and the capture card's ingress latency. The number is
> perfectly reasonable, if one or both of the devices has MAC time
> stamping.
>
> HTH,
> Richard
>
>
------------------------------------------------------------------------------
_______________________________________________
Linuxptp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
