[ntp:questions] Slow convergence loopstats (but nice results)

Martin Burnicki 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 
with NTP.

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.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list