[time-nuts] A (slightly) different apu2 question

Martin Burnicki martin.burnicki at burnicki.net
Fri Nov 18 04:21:03 EST 2016


Wojciech Owczarek wrote:
>>
>>
>> NTP does not require softstamps.  NTP can be (and I believe it has been in
>> a product) modified to use "PTP" hardware (hardstamps) and  reasonably
>> current releases can run with "drivestamps" (sampled in the NIC driver)
>> between cooperating endpoints.
> 
> 
> Of course it does not *require* software timestamps, I never said that, it
> is just the fact that most people use it with software timestamps, even if
> the NIC permits hardware timestamps. You need a secondary servo to sync the
> NIC to O/S clock if you want to serve that (or consume that) - or sync the
> NIC to external 1PPS. What you call a "drivestamp", I call a software
> timestamp. If it's not a function of the silicon, it's software. All I
> meant was that there is some unexploited potential.

Just a few thoughts regarding NTP vs. PTP:

IMO NTP can yield pretty good results even over WAN connections
*without* the requirement of special hardware which supports
timestamping of network packets, including special switches and routers,
even over WAN connections, and in the presence of network jitter. For
example from one of my workstation running Linux, here in Germany:

   remote        refid     st t when poll reach   delay   offset  jitter
========================================================================
*SHM(0)          .shm0.     0 l    4    8  377    0.000   -0.001   0.000
 lt-martin.py.me .MRS.      1 u    9   64  377    0.095   -0.005   0.020
 ntp-master-1.py .PPS.      1 u   58   64  377    0.191   -0.019   0.013
 ptbtime1.ptb.de .PTB.      1 u   11  128  377   11.927    0.256  74.533
 ptbtime2.ptb.de .PTB.      1 u   16  128  377   11.706    0.085  79.565
 ptbtime3.ptb.de .PTB.      1 u   35  128  377   11.590    0.058  74.049
 time-b.timefreq .ACTS.     1 u  103  128  377  198.358   -1.377  91.992

where

- SHM is a local GPS PCI card

- lt-martin and ntp-master-1 are GPS controlled NTP servers on the local
network

- ptbtime{1,2,3} are the public NTP servers operated by the German
metrology institute PTB, reached via 7 network hops

- time-b.timefreq is a public server in the U.S., reached via 9 network
hops, including a trans-atlantic connection.


Of course, PTP can do *much* better if special hardware is being used.

We have made tests here at Meinberg where we could demonstrate that NTP
yields the same level of accuracy as PTP with a patched ntpd which
supports hardware time stamping of NTP packets. We used an own time
stamp unit which can also time stamp NTP packets.

There are 2 problems with this, though:

1.) While the PTP folks have been requesting support for time stamping
PTP packets in NIC chips as well as specific PTP support by switches and
routers for a long time, this hasn't happened for NTP.

So today we have indeed NIC chips which time stamp PTP packets, and
switches which are PTP-aware and measure the propagation delay of PTP
packets (in transparent clock mode) so that the PTP daemon can
compensate this delay and eliminate the network jitter.

There's no such thing for NTP.

2.) In the original approach introduced by PTP an outgoing packet is
time stamped by the NIC, and then a "followup" packet is sent which
contains that time stamp ("twostep" mode). This eliminates the
processing delay between the time a packet is sent out by the daemon
until it goes onto the network cable.

NTP doesn't support this feature, and introduction of this feature would
either break compatibility of the existing NTP protocol, or would
require the definition of a new protocol version, e.g. NTPv5.
(BTW, I'm aware of ntpd's "interleave" mode, but IMO that's just a hack,
and doesn't even work with normal client/server packet exchanges).

Of course PTP has a "onestep" mode today where a time stamp is taken as
soon as the packet goes out on the wire, and that time stamp is inserted
into the same packet on the fly, so no followup packet is required.

However, this requires even more sophisticated hardware which explicitly
supports this, and even if this was available for NTP this still
wouldn't solve problem of NTP time stamping support missing in NICs and
switches.

So I think NTP still meets the requirements of many users, without
requirement for specific hardware, while PTP can be used to yield a much
higher level of accuracy if you have dedicated hardware available.

Martin



More information about the time-nuts mailing list