schmidt.r...@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
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
