[ntp:questions] Slow convergence loopstats (but nice results)
martin.burnicki at meinberg.de
Thu Dec 12 08:59:03 UTC 2013
schmidt.rich at gmail.com wrote:
> My new prototype driver refclock_phc() uses as its clock the PTP
> Hardware Clock (PHC) found on one of the newer LAN NICs which are PTP
> (IEEE 1588) aware. This driver is producing phenomenal results (under
> LINUX 3.12 with linuxPTP): the overlapping Allan deviation computed
> from loopstats phase offsets alone reaches a stability of 6e-12 in
> under 2e5 seconds, and the modified Allan deviation reaches 2e-13.
> This is quite useful, as eventually most all NICs will be
> PTP-enabled, and can be used as slaves as above, or even GrandMasters
> (with GPS, for example).
Some time ago we at Meinberg have made some tests with hardware time
stamping of incoming and outgoing NTP packets on our own NIC, and we saw
that in this case the resulting accuracy with pure NTP is the same as
A major problem was that the standard NTP protocol doesn't support a way
to send the captured time stamp of a previously sent packet to its
client, as done by the so-called followup message in PTP.
I don't know if new standard NIC chips which support PTP timestamping
can also timestamp NTP packets, but even if they do then in practice
there's still the problem with network switches, etc.
There are network switches out there which are PTP-aware and also
timestamp incoming and outgoing PTP packets to compensate the introduced
packet delay in some way, but there are no switches (AFAIK) which can do
this with NTP packets, so even if you used hardware time stamping of NTP
packets on NTP end nodes the resulting accuracy would still be worse
than with PTP.
That's too sad.
More information about the questions