Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Brian Utterback wrote: On 12/2/2014 4:00 AM, Rob wrote: The whole have 3 servers to select a majority thing is absolutely not required when your servers are accurately synchronized themselves and your requirements are only within-a-second. It is true that when you have two servers the clients cannot know which one is right, but it is trivial to keep servers within a millisecond of eachother with GPS and within 10 milliseconds using only network peering. To that is two orders of magnitude better than you require. Be careful with this generalization. While it may be trivial, it isn't automatic. I deal with customers all the time that have configured exactly two servers on their clients and then are surprised later when all of the clients become unsynchronized and start free drifting. I always recommend against it. I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. The ntp html docs on selection state that four are needed to guarantee a majority and give an example of this case. David Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
David Lord sn...@lordynet.org wrote: Brian Utterback wrote: On 12/2/2014 4:00 AM, Rob wrote: The whole have 3 servers to select a majority thing is absolutely not required when your servers are accurately synchronized themselves and your requirements are only within-a-second. It is true that when you have two servers the clients cannot know which one is right, but it is trivial to keep servers within a millisecond of eachother with GPS and within 10 milliseconds using only network peering. To that is two orders of magnitude better than you require. Be careful with this generalization. While it may be trivial, it isn't automatic. I deal with customers all the time that have configured exactly two servers on their clients and then are surprised later when all of the clients become unsynchronized and start free drifting. I always recommend against it. I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. The ntp html docs on selection state that four are needed to guarantee a majority and give an example of this case. In practice this problem does not occur when you use only your own servers that you monitor and trust, and it confuses people that want to setup NTP on their company network. They get sent away with you need to configure and maintain 4 servers or better even more. When the servers either are synced correctly or are down, this is not required. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 12/3/2014 5:33 PM, William Unruh wrote: On 2014-12-03, Jan Ceuleers jan.ceule...@computer.org wrote: On 12/03/2014 02:58 PM, Brian Utterback wrote: I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. It takes three servers *at all times* to enable clients to use majority voting. So if you want to guard against a single failure (i.e. not a single falseticker, a single server that goes offline), then you need four. Offline IS a false ticker. And no, you need three. In fact to gaurd against offline, you only need two. Guarding against falseticking is harder than guarding against offline. Just as it is harder to guard against a liar than a dead man. I remain unconvinced. I believe that it takes three correct servers to outvote a single falseticker, meaning that if you want to be safe against one of your servers becoming a falseticker and still being accepted as the system server by a client, the client needs at least four servers. Remember that a vote is not for a single offset, it is for a single offset plus or minus the error, which in our case is the dispersion. Be definition a truechimer is a server whose range of offset-disp to offset+disp includes the actual time, while a falseticker is a server whose range does not include the actual time. Now suppose you have three servers, two truechimers and one falseticker, call them T1, T2 and F. The actual time is a bit above the T1 offset, meaning it is in the interval between T1off and T1off+T1disp. The actual time is also in the interval T2off-T2disp and T2off, which is to say that they both overlap with the real time but neither overlaps the other's offset. Now imagine that the falseticker has a similar overlap with T1, but on the interval T1off-T1disp to T1off. That interval does not include the real time, so F is indeed a falseticker. So, we have a completely symmetric situation, with T1 and F voting for an interval that does not include the real time and T1 and T2 voting for an interval that does include the real time. By what mechanism are we to presume that the client will choose the interval that includes the real time? -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-04, David Lord sn...@lordynet.org wrote: Brian Utterback wrote: On 12/2/2014 4:00 AM, Rob wrote: The whole have 3 servers to select a majority thing is absolutely not required when your servers are accurately synchronized themselves and your requirements are only within-a-second. It is true that when you have two servers the clients cannot know which one is right, but it is trivial to keep servers within a millisecond of eachother with GPS and within 10 milliseconds using only network peering. To that is two orders of magnitude better than you require. Be careful with this generalization. While it may be trivial, it isn't automatic. I deal with customers all the time that have configured exactly two servers on their clients and then are surprised later when all of the clients become unsynchronized and start free drifting. I always recommend against it. I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. The ntp html docs on selection state that four are needed to guarantee a majority and give an example of this case. Under what circumstances? Nothing can guarentee a majority. 11 cannot guarentee a majority. Except 1 I guess. As long as it is working it is the majority. Of course if it stops working all together, then not either. 3 guarentees a majority if only one stops or stops sending out correct time. etc. David Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-04, Rob nom...@example.com wrote: David Lord sn...@lordynet.org wrote: Brian Utterback wrote: On 12/2/2014 4:00 AM, Rob wrote: The whole have 3 servers to select a majority thing is absolutely not required when your servers are accurately synchronized themselves and your requirements are only within-a-second. It is true that when you have two servers the clients cannot know which one is right, but it is trivial to keep servers within a millisecond of eachother with GPS and within 10 milliseconds using only network peering. To that is two orders of magnitude better than you require. Be careful with this generalization. While it may be trivial, it isn't automatic. I deal with customers all the time that have configured exactly two servers on their clients and then are surprised later when all of the clients become unsynchronized and start free drifting. I always recommend against it. I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. The ntp html docs on selection state that four are needed to guarantee a majority and give an example of this case. In practice this problem does not occur when you use only your own servers that you monitor and trust, and it confuses people that want to setup NTP on their company network. They get sent away with you need to configure and maintain 4 servers or better even more. When the servers either are synced correctly or are down, this is not required. People love to either read or make rules, no matter how senseless. That way you do not have to think. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On Thu, Dec 04, 2014 at 10:46:17AM -0500, brian utterback wrote: I remain unconvinced. I believe that it takes three correct servers to outvote a single falseticker, meaning that if you want to be safe against one of your servers becoming a falseticker and still being accepted as the system server by a client, the client needs at least four servers. Four (or any larger number) of servers still doesn't guarantee the source selection algorithm will mark one bad source as a falseticker. There was a very similar discussion about this few years ago, including an example: http://lists.ntp.org/pipermail/questions/2011-January/028313.html Now imagine that the falseticker has a similar overlap with T1, but on the interval T1off-T1disp to T1off. That interval does not include the real time, so F is indeed a falseticker. So, we have a completely symmetric situation, with T1 and F voting for an interval that does not include the real time and T1 and T2 voting for an interval that does include the real time. By what mechanism are we to presume that the client will choose the interval that includes the real time? The intersection interval determined in the source selection algorithm will be equal to the interval of T1 and all three servers will pass as truechimers. Adding a third good server may not be enough to change the result. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-04, brian utterback brian.utterb...@oracle.com wrote: On 12/3/2014 5:33 PM, William Unruh wrote: On 2014-12-03, Jan Ceuleers jan.ceule...@computer.org wrote: On 12/03/2014 02:58 PM, Brian Utterback wrote: I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. It takes three servers *at all times* to enable clients to use majority voting. So if you want to guard against a single failure (i.e. not a single falseticker, a single server that goes offline), then you need four. Offline IS a false ticker. And no, you need three. In fact to gaurd against offline, you only need two. Guarding against falseticking is harder than guarding against offline. Just as it is harder to guard against a liar than a dead man. I remain unconvinced. I believe that it takes three correct servers to outvote a single falseticker, meaning that if you want to be safe against one of your servers becoming a falseticker and still being accepted as the system server by a client, the client needs at least four servers. Remember that a vote is not for a single offset, it is for a single offset plus or minus the error, which in our case is the dispersion. Be definition a truechimer is a server whose range of offset-disp to offset+disp includes the actual time, while a falseticker is a server whose range does not include the actual time. Now suppose you have three servers, two truechimers and one falseticker, call them T1, T2 and F. The actual time is a bit above the T1 offset, meaning it is in the interval between T1off and T1off+T1disp. The actual time is also in the interval T2off-T2disp and T2off, which is to say that they both overlap with the real time but neither overlaps the other's offset. Now imagine that the falseticker has a similar overlap with T1, but on the interval T1off-T1disp to T1off. That interval does not include the real time, so F is indeed a falseticker. So, we have a completely symmetric situation, with T1 and F voting for an interval that does not include the real time and T1 and T2 voting for an interval that does include the real time. By what mechanism are we to presume that the client will choose the interval that includes the real time? No. A false ticker is NOT something whose range does not overlap the true time. the system has absolutely no way of knowing what the true time is. All it has is the reports from the remote clocks and their dispersion. As I understand it, ntpd looks for islands-- groups of remote clocks whose ranges overlap each other. The island with a majority of members is by definition the island of truechimers. All others are false tickers. Now, it could be that the majority is way off -- 400 days off from the true time. They are still the truechimers, because the system has no way of knowing what the true time is. In your example, if T1 and T2 are in one island, and F1 and F2 are in another, what waydoes the system have of determining which is the true time? And in your case if T3 has exactly the same time and dispersion as T1, how does the system decide? There is simply no way of deciding which will be robust against all scenarios. It is impossible (It is basically like Arrow's theorem on voting that no voting system can have all of the attributes one would like a real voting system to have.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 04/12/2014 11:53, Rob wrote: [] In practice this problem does not occur when you use only your own servers that you monitor and trust, and it confuses people that want to setup NTP on their company network. They get sent away with you need to configure and maintain 4 servers or better even more. When the servers either are synced correctly or are down, this is not required. These days, perhaps the best simple advice is to encourage the use of the pool directive and let NTP choose as many servers as it thinks are appropriate. Yes, I did say simple advice. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 04/12/2014 11:53, Rob wrote: [] In practice this problem does not occur when you use only your own servers that you monitor and trust, and it confuses people that want to setup NTP on their company network. They get sent away with you need to configure and maintain 4 servers or better even more. When the servers either are synced correctly or are down, this is not required. These days, perhaps the best simple advice is to encourage the use of the pool directive and let NTP choose as many servers as it thinks are appropriate. Yes, I did say simple advice. It is not good practice to use pool on 100-1000 internal systems, presumably via NAT, to poll time from internet. Simple advice is: setup 1 NTP server when you are always monitoring, or 2 servers when you cannot always be on watch to fix the one server, and keep them mutually synchronized. That will work OK in a company. Maybe not in the head of a thought experimenter, but that is normally not what companies are after. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Red Hat vote for chrony
I've been reading the migration guidance document for RHEL 7 and it seems that Chrony has replaced ntpd as their default NTP based time synchonisation package. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Migration_Planning_Guide/Red_Hat_Enterprise_Linux-7-Migration_Planning_Guide-en-US.pdf They quote a list of benefits, but I think that is just quoting the upstream claims, and it took them a long time to disable the local clock, so they are not exactly experts. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 12/4/2014 12:13 PM, Miroslav Lichvar wrote: On Thu, Dec 04, 2014 at 10:46:17AM -0500, brian utterback wrote: I remain unconvinced. I believe that it takes three correct servers to outvote a single falseticker, meaning that if you want to be safe against one of your servers becoming a falseticker and still being accepted as the system server by a client, the client needs at least four servers. Four (or any larger number) of servers still doesn't guarantee the source selection algorithm will mark one bad source as a falseticker. There was a very similar discussion about this few years ago, including an example: http://lists.ntp.org/pipermail/questions/2011-January/028313.html Now imagine that the falseticker has a similar overlap with T1, but on the interval T1off-T1disp to T1off. That interval does not include the real time, so F is indeed a falseticker. So, we have a completely symmetric situation, with T1 and F voting for an interval that does not include the real time and T1 and T2 voting for an interval that does include the real time. By what mechanism are we to presume that the client will choose the interval that includes the real time? The intersection interval determined in the source selection algorithm will be equal to the interval of T1 and all three servers will pass as truechimers. Adding a third good server may not be enough to change the result. I think we are in violent agreement. The point I am trying to make is that for a long time we recommended four servers then started saying that three was enough but four is better. I think that we should stick with recommending four, at least if you actually care about the time on your systems. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-04, Brian Utterback brian.utterb...@oracle.com wrote: On 12/4/2014 12:36 PM, William Unruh wrote: On 2014-12-04, brian utterback brian.utterb...@oracle.com wrote: On 12/3/2014 5:33 PM, William Unruh wrote: On 2014-12-03, Jan Ceuleers jan.ceule...@computer.org wrote: On 12/03/2014 02:58 PM, Brian Utterback wrote: I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. It takes three servers *at all times* to enable clients to use majority voting. So if you want to guard against a single failure (i.e. not a single falseticker, a single server that goes offline), then you need four. Offline IS a false ticker. And no, you need three. In fact to gaurd against offline, you only need two. Guarding against falseticking is harder than guarding against offline. Just as it is harder to guard against a liar than a dead man. I remain unconvinced. I believe that it takes three correct servers to outvote a single falseticker, meaning that if you want to be safe against one of your servers becoming a falseticker and still being accepted as the system server by a client, the client needs at least four servers. Remember that a vote is not for a single offset, it is for a single offset plus or minus the error, which in our case is the dispersion. Be definition a truechimer is a server whose range of offset-disp to offset+disp includes the actual time, while a falseticker is a server whose range does not include the actual time. Now suppose you have three servers, two truechimers and one falseticker, call them T1, T2 and F. The actual time is a bit above the T1 offset, meaning it is in the interval between T1off and T1off+T1disp. The actual time is also in the interval T2off-T2disp and T2off, which is to say that they both overlap with the real time but neither overlaps the other's offset. Now imagine that the falseticker has a similar overlap with T1, but on the interval T1off-T1disp to T1off. That interval does not include the real time, so F is indeed a falseticker. So, we have a completely symmetric situation, with T1 and F voting for an interval that does not include the real time and T1 and T2 voting for an interval that does include the real time. By what mechanism are we to presume that the client will choose the interval that includes the real time? No. A false ticker is NOT something whose range does not overlap the true time. I stand by my definition of a falseticker. It is the *detection* of a falseticker that you are describing. Indeed it is a hard problem if you do not know what the true time is, which is the case for all NTP servers. But my definition fits what it is that the server is trying to detect. That may be your definition of a falseticker. It is not that of ntpd, which cannot know what the true time is, and yet the docs talks all over the place about falsetickers and how ntpd does not use them. In your example, if T1 and T2 are in one island, and F1 and F2 are in another, what waydoes the system have of determining which is the true time? And in your case if T3 has exactly the same time and dispersion as T1, how does the system decide? My example didn't have a F1 and F2, only an F, but I think you are saying exactly the same thing that I said. The system has no way to decide and is as likely to get it wrong as right. Agreed that you did not have an F1 and F2. that was my postulate, just as T3 was my postulate. Ie, having 4 sources does not mean that the system can decide properly. Nor does having 11 sources. (at that point the problem of getting many of the sources all depending on single other sources becomes a problem.) There is no way of gauranteeing anything, no matter what the number of sources is. One source is fine, unless it either dies or goes nuts. Two are fine, unless on goes nuts. Three are fine, as long as only one dies or goes nuts. Four are fine, as long as fewer than three die, or one goes nuts, or two go nuts in different ways. Etc. You understand the limitations and you makes your choices. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On 2014-12-04, David Woolley david@ex.djwhome.demon.invalid wrote: I've been reading the migration guidance document for RHEL 7 and it seems that Chrony has replaced ntpd as their default NTP based time synchonisation package. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Migration_Planning_Guide/Red_Hat_Enterprise_Linux-7-Migration_Planning_Guide-en-US.pdf They quote a list of benefits, but I think that is just quoting the upstream claims, and it took them a long time to disable the local clock, so they are not exactly experts. Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has done a lot of testing comparing chrony to ntpd ( which showed that chrony controlled the clock a factor of 2 to 20 times better than ntpd did), and is with Redhat. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-04 08:58, William Unruh wrote: On 2014-12-04, David Lord sn...@lordynet.org wrote: The ntp html docs on selection state that four are needed to guarantee a majority and give an example of this case. Under what circumstances? Nothing can guarentee a majority. 11 cannot guarentee a majority. Except 1 I guess. As long as it is working it is the majority. Of course if it stops working all together, then not either. 3 guarentees a majority if only one stops or stops sending out correct time. etc. There must be a strict majority clique #truechimers #falsetickers. I had a bunch of backup servers configured when the DRDoS attacks started, and a lot of academic servers disappeared from the net for a few weeks. I had to deconfigure them and restart, as even with a preferred ref clock, ntpd will not discipline the time without Byzantine agreement. For a corporate environment, recommend 2n+1 servers, where n is the number of local servers you will allow to be down at one time, plus network sources which should be fewer than the number of local servers, and preemptable, so they will be dropped if they become unreachable. For example, you could run three peered local servers and two good diverse network sources each, allowing only one local server to be down at any time for updates or patches. Each of the peers needs to have a different pair of network sources, to avoid any common mode failures, or rejection from sync loops. More local servers would allow more good diverse network sources, and more simultaneous local and remote outages. The diverse network sources are necessary so congestion or maintenance on a single downstream router or backbone connection does not make all your sources unreachable at once. This will happen occasionally during maintenance outage windows if you use a single ISP or a single outward path from your network. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca wrote: [ ... ] Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has done a lot of testing comparing chrony to ntpd ( which showed that chrony controlled the clock a factor of 2 to 20 times better than ntpd did), and is with Redhat. The data I've seen for chrony suggests it handles broken clocks such as commonly found in VMs better than ntpd does. The tradeoff is that chrony prioritizes chasing the reference time over first trying to ensure that the local clock frequency is stable, whereas ntpd really wants to make sure that the local clock counts 3600 seconds in each hour of wall-clock time and then worries about slewing the local time to match up with the reference time. It's informative to note that the chrony docs (section 5.3.4) recommend using minpoll=2 and maxpoll=4! With those settings chrony will send 225 polls per hour, versus 3.5 polls per hour for ntpd with its maxpoll=10. Assuming arguendo the claim of a factor of 20 times better is true, I still don't care to pay the price of a factor of 64 times more network polls. Furthermore-- unfortunately-- I have yet to see data on the accuracy of chrony measured against high-quality TCXO or Rb/Cs reference clocks, such as the PRS-10 that PHK used: http://www.thinksrs.com/products/PRS10.htm ...the current version of which claims to have a +/- 10 ns accuracy for the PPS signal. Instead, most of the data I've seen provided for chrony has involved comparing local clock timestamps to the reference timesource or to some other network timesource, without detailed information as to the accuracy of those references. Of course you're not going to see much delta between the local clock and the reference that you're polling every 16 seconds. Without measuring the local clock against some other clock or oscillator which is known to be accurate to sub-microsecond levels, one doesn't have the data needed to draw conclusions about the actual timekeeping precision. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
