The standard rule is that you need 2n + 1 upstream time sources to protect against n falsetickers, but this falls down for the case of n=1. If you want to prote

The standard rule is that you need 2n + 1 upstream time sources to protect against n falsetickers, but this falls down for the case of n=1. If you want to protect yourself against just one falseticker, you need at least four upstream time sources, to handle the case of what you do after you kick the one falseticker off the island. We explain this at http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3 http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPS.... PTP is great for high resolution time synchronization on the local LAN, but doesn’t leave the local lan segment without special network support in the switches and hubs. It is not designed for good stable time sync over the long term. If you’re running a High Frequency Trading operation and it’s really important to know precisely which nanosecond or which picosecond a particular transaction occurred, then you want PTP. If you’re concerned about keeping all your servers in good enough time sync that you can debug the order of operations as they might show up in the log files on different servers, then you want NTP. And NTP can be configured to use PTP as a good quality Stratum 0 refclock. If you wish to learn more about PTP, the Network Time Foundation supports the Linux PTP project, see https://www.nwtime.org/projects/linuxptp/ https://www.nwtime.org/projects/linuxptp/ Disclaimer: I have been involved in supporting the Public NTP Project since 2003, and related projects like the NTF, the nwtime.org site, etc….