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 _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.