Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
snip Three are fine, as long as only one dies or goes nuts. Again, define goes nuts. You don't seem to like the term falseticker, so how do you define goes nuts? If one goes nuts or even goes offline, if the remaining two do not agree then it is like having no server at all. No, it is like having two, with one being out. falseticker is a term with a very specific internal definition. Thus a server whose time is right on UTC could be a falseticker, because the other two servers were both exactly 3 days out, with tiny jitter estimates. I would say then that you had two servers going nuts, and one good, even though ntpd would say there were two good and one false ticker. In fact this does not happen. I just tested the hypothesis. What happens depends on how the two wayward get there exaggerated offset: a) someone,something resets the date: result: ntp on both those servers crashes due to the panic_stop limit. So in this case the client has only one reference and continues using that. It is not flagged as a falsticker. That is normal. b) someone restarts ntp on the servers with the wrong date. Here the servers ntpd has no way of knowing that it has bad time and so continues serving normally. On the client. The running ntp sees immediately a huge offset and huge jitter. Tue Dec 9 13:15:04 CET 2014 remote refid st t when poll reach delay offset jitter == *192.168.1.15.GPS1. 1 u 320 64 3600.5490.040 0.037 +192.168.1.16.GPS2. 1 u 37 64 3770.6060.006 0.028 +192.168.1.17.GPS1. 1 u 309 64 3600.5760.027 0.025 Tue Dec 9 13:16:08 CET 2014 remote refid st t when poll reach delay offset jitter == 192.168.1.15.GPS1. 1 u 55 64 3410.5650.042 9660780 *192.168.1.16.GPS2. 1 u 37 64 3770.6060.006 0.024 192.168.1.17.GPS1. 1 u 42 64 3410.5790.041 9660773 After 5 mins the client is unable to resolve this and declares all clock falsetickers and then panics. I did not have ntpd in debug mode here, but it is reasonable to assume that it panics due to the selected clock being too far out and hitting the panic limit. Tue Dec 9 13:23:37 CET 2014 remote refid st t when poll reach delay offset jitter == 192.168.1.15.GPS1. 1 u 45 64 3770.596 -255600 155.539 *192.168.1.16.GPS2. 1 u 25 64 3770.6140.024 0.008 192.168.1.17.GPS1. 1 u 30 64 3770.583 -255600 52.806 Tue Dec 9 13:24:41 CET 2014 remote refid st t when poll reach delay offset jitter == x192.168.1.15.GPS1. 1 u 43 64 3770.596 -255600 179.609 x192.168.1.16.GPS2. 1 u 23 64 3770.6140.024 0.008 x192.168.1.17.GPS1. 1 u 27 64 3770.618 -255599 6.009 /usr/local/bin/ntpq: read: Connection refused Tue Dec 9 13:25:45 CET 2014 /usr/local/bin/ntpq: read: Connection refused This is exactly what happens if the client is restarted. clock_filter: n 1 off -255599.997967 del 0.000662 dsp 7.937502 jit 0.02 select: endpoint -1 -255600.000806 select: endpoint 1 -255599.995128 select: survivor 192.168.1.17 0.002839 select: combine offset -255599.997967134 jitter 0.0 event at 1 192.168.1.17 903a 8a sys_peer clock_update: at 1 sample 1 associd 18641 event at 1 0.0.0.0 c617 07 panic_stop -255600 s; set clock manually within 1000 s. event at 1 0.0.0.0 c61d 0d kern kernel time sync disabled So ntp does NOT continue in your test case. Your case may be better if the time difference is less than the panic limit. Say if the two servers do not insert a leap second, but the « correct » one does. I’ll try that for my own satisfaction if I can figure how to do it. Like Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Phil W Lee wrote: I believe it is important to allow negative leap seconds again, in order to allow a dignified recovery from erroneous positive leap seconds. I don't think fake negative leap seconds can (and should) be used to undo the effect of an erroneously applied positive leap second. Martin ___ 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-18 14:27, Phil W Lee wrote: Martin Burnicki martin.burni...@meinberg.de considered Wed, 17 Dec 2014 10:35:39 +0100 the perfect time to write: Phil W Lee wrote: Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec 2014 14:23:15 +0100 the perfect time to write: Harlan Stenn wrote: An alternative is that we get enough support to advance NTF's General Timestamp API, and then we can run systems on either TAI or UTC and these conversions will happen automatically. Since timescale files in the GTSAPI are versioned, one could still use an obsolete leapsecond file, and while those UTC timestamps would be wrong if a new leapsecond was added, these timestamps would be correctable when a new version of the UTC timescale file was available. Hm, that may not really help if the API returns a wrong UTC time stamp which is then used to set the system time wrong. The tzdist protocol could also be helpful here to provide the information required to do the conversion correctly. An expiration date could be used for versioning. You don't need an expiry date if you have a version number and/or an authoritative source for any new version that may be available - you just compare the two, and use the newest available. Yes you do. With only a version number consumers like ntpd would not be able to know if the information is outdated, or not. Of course, if leap seconds should be abolished it would be useful to support a pseudo expiration date meaning until further notice. As long as the IERS stays at the same URL, you could just use their file at http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second.dat (although it would be useful if that file was more complete, with a version number and checksum). This is once more a different file format than the format used by tzdata, or NIST/NTP. :-( A service like a tzdist client, or a simple script which might look for and download updated files, could report an error if the URL is not reachable, and thus it can't even *check* if a new version of the file is available. However, similarly as not every tiny NTP client node should query the time directly from NIST and similar servers but should use pool servers instead, not every tiny embedded system should try to download a leap second file directly from the primary server. So make the download dependent on the stratum of the ntp server - mandatory for stratum 1, optional for 2, disabled below that (or some such system - that's only a suggestion, although obviously I think it has merit). If they use secondary servers an older version of the file may me available, but outdated. No way to check this without an expiration date. There are companies with a whole (sub-)network without access to the internet, so it may be required to update DST rules and leap second information manually. An easy way to do this could be to set up a tzdist or FTP (or whatever) server which can provide the internal clients with the update. If no one cares about those updates then applications like ntpd can output a warning if the expiration date has been passed. With only a version information this isn't possible. It would also be useful if they used SSL, and changed the url to https://etc. Agreed. Perhaps NTP V5 could support all current leap second file source types, specification of URIs and file paths for all types; with an optional leap second packet extension, added only to early association establishment packets once a server version is known, or whenever a source update is detected. The leap second packet extension would be optional only for V 5 or stratum 1, and give the last/next leap second time announced, the expiration time, now available in all sources, and source file type, to allow for different expiration times, unless NIST and IERS agree on expiration times. If the leap second and expiration times announced agree, the packet extension returns the same values, otherwise the later leap second time and/or earlier expiration time, if the leap second time agrees, is adopted by the lower stratum system and returned in the reply, indicating adoption, then the extension can be dropped from subsequent packets. Lack of agreement and/or adoption should always be logged by lower stratum systems, could optionally be logged by equal stratum systems acting as clients or peers, and could optionally be logged only once by higher stratum systems. Other requirements will undoubtedly need to be added to cover all possible scenarios, including false-leapers, false-expirers, and dropped packets. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Phil W Lee wrote: Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec 2014 12:56:15 +0100 the perfect time to write: William Unruh wrote: The importance of trades is usually a before/after. And UTC TAI, GPS all have exactly the same definition of before and after. Of course if one time was in UTC and the otehr in TAI, that could well be successfully argued. From a technical point I absolutely agree with you. However, there have been discussions (IIRC on the TZ or leapsecs mailing lists) where folks tried to explain that even though the difference between TAI and UTC is just an integral number of seconds, TAI could not even be used as a replacement for UTC without leap seconds, just due to specific wordings in certain documents. Leap seconds seem to be a real mess in the IT world. It would be useful if the way of inserting a leap-second was set in a standard, in such a way that time continued at a set rate (maybe by slewing at a set percentage or PPM). If that could be achieved, it would remove many of the objections to leap-seconds. It might be difficult to thrash out in practice though. I know that officially at present there is an additional second between 23:59:60 and 00:00:00, but no time recording system that I know of has the ability to record times between 23:59:60 and 00:00:00 correctly (despite such times existing since 1st Jan 1961, which must surely pre-date any software currently in use), which is a necessary requirement if the second is to be inserted exactly as currently specified and time continued forward (so that events are recorded in the correct order). Does anyone know of any software which will record times during that additional second accurately, e.g. as 23:59:60.789? Yes, different software from Meinberg. ;-) The main problem is that the underlying system time (often POSIX, which just counts seconds since an epoch) has the *same* time stamp art the beginning and end of the leap second. In order to do the conversion correctly you need to know if the current second is the leap second, or not, i.e. you need some status flag in addition to the raw (e.g. POSIX) timestamp. This is basically similar to what you have at the end of DST, where (in local time) a whole hour is passed twice. You need to know the DST status to determine unambiguously if it's the first or the second turn. Is there any realistic prospect of forcing software to comply with a time standard which includes times between 23:59:60 and 00:00:00? Now, you can either stipulate that all software including operation systems recognise times during that additional second - which would require re-writing the time functions of most of the worlds software to recognise and record times 23:59:60 00:00:00 (but only if a leap second has been legally notified), or you can agree to insert the additional second more gradually by clock slewing (but at what rate would have to be agreed). Clock slewing would require much more change to international agreements, but would require far less work on re-writing software, and would actually relate better to the real world, which is annoyingly both analogue AND irregular:-) Or the second itself could be redefined to take account of the actual speed the earth rotates - but that might be problematic for the scientists, as we'd likely have to keep doing it as the earth slows. I certainly think we need to deal with the problem better than we do at the moment. A main reason for the problems with leap seconds is that POSIX has just ignored them when they defined their standards on timekeeping. There has been a proposal from David Mills many years ago where the time during an inserted leap second increases only *very* slowly during the leap second, so monotonicity of time stamps is kept. However, most algorithms, or API calls returning a time stamp plus consistent status information require longer execution time than just returning a time stamp, e.g. just a 64 bit number. So the easy way is often preferred over the accurate way. I've collected some information on leap seconds in a paper which you can find here: http://www.meinbergglobal.com/english/info/#whitepaper Especially: Technical Aspects of Leap Second Propagation and Evaluation http://www.meinbergglobal.com/download/burnicki/Technical%20Aspects%20of%20Leap%20Second%20Propagation%20and%20Evaluation.pdf This may not be complete but covers many aspects of leap second handling. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: The main problem is that the underlying system time (often POSIX, which just counts seconds since an epoch) has the *same* time stamp art the beginning and end of the leap second. In order to do the conversion correctly you need to know if the current second is the leap second, or not, i.e. you need some status flag in addition to the raw (e.g. POSIX) timestamp. This is basically similar to what you have at the end of DST, where (in local time) a whole hour is passed twice. You need to know the DST status to determine unambiguously if it's the first or the second turn. Yes, but in situations where you care about that you store just the system time, and the conversion to local time can be repeated later. Thanks to the powerful conversion routines in glibc this can be done even way in the past (because it remembers DST rules from previous years). Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. A main reason for the problems with leap seconds is that POSIX has just ignored them when they defined their standards on timekeeping. That is the problem. And probably also the decision in Unix to count UTC seconds since Jan 1st, 1970 (instead of TAI seconds). Back then it did not matter that much in a timesharing system. The system clock was mainly a convenience feature, not critical to anything. (it usually had to be set on every boot and this was done by typing the time seen on the operator's wristwatch, hence the term wristwatch time) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Phil W Lee wrote: Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec 2014 14:23:15 +0100 the perfect time to write: Harlan Stenn wrote: An alternative is that we get enough support to advance NTF's General Timestamp API, and then we can run systems on either TAI or UTC and these conversions will happen automatically. Since timescale files in the GTSAPI are versioned, one could still use an obsolete leapsecond file, and while those UTC timestamps would be wrong if a new leapsecond was added, these timestamps would be correctable when a new version of the UTC timescale file was available. Hm, that may not really help if the API returns a wrong UTC time stamp which is then used to set the system time wrong. The tzdist protocol could also be helpful here to provide the information required to do the conversion correctly. An expiration date could be used for versioning. Martin You don't need an expiry date if you have a version number and/or an authoritative source for any new version that may be available - you just compare the two, and use the newest available. Yes you do. With only a version number consumers like ntpd would not be able to know if the information is outdated, or not. Of course, if leap seconds should be abolished it would be useful to support a pseudo expiration date meaning until further notice. As long as the IERS stays at the same URL, you could just use their file at http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second.dat (although it would be useful if that file was more complete, with a version number and checksum). This is once more a different file format than the format used by tzdata, or NIST/NTP. :-( A service like a tzdist client, or a simple script which might look for and download updated files, could report an error if the URL is not reachable, and thus it can't even *check* if a new version of the file is available. However, similarly as not every tiny NTP client node should query the time directly from NIST and similar servers but should use pool servers instead, not every tiny embedded system should try to download a leap second file directly from the primary server. If they use secondary servers an older version of the file may me available, but outdated. No way to check this without an expiration date. There are companies with a whole (sub-)network without access to the internet, so it may be required to update DST rules and leap second information manually. An easy way to do this could be to set up a tzdist or FTP (or whatever) server which can provide the internal clients with the update. If no one cares about those updates then applications like ntpd can output a warning if the expiration date has been passed. With only a version information this isn't possible. It would also be useful if they used SSL, and changed the url to https://etc. Agreed. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Harlan Stenn wrote: Martin Burnicki writes: Harlan Stenn wrote: An alternative is that we get enough support to advance NTF's General Timestamp API, and then we can run systems on either TAI or UTC and these conversions will happen automatically. Since timescale files in the GTSAPI are versioned, one could still use an obsolete leapsecond file, and while those UTC timestamps would be wrong if a new leapsecond was added, these timestamps would be correctable when a new version of the UTC timescale file was available. Hm, that may not really help if the API returns a wrong UTC time stamp which is then used to set the system time wrong. Anything on the box that uses UTC in this situation will be using an outdated UTC timescale, and when any newer versions are made available the library API will handle the conversion. Think of the case where you want to set an event for a future time - if you want to tag something with an absolute time of 10am UTC a year in the future, there's no way to know if there will be a leap second in there or not. So as we get closer to the actual date, if the UTC timescale gets updated the absolute UTC timestamp will be properly adjusted as soon as we know. I don't know if you are subscribed to the tzdist mailing list, on which there is actually a similar discussion: Imagine you set up an event for April 2015 today, but you just don't know if DST will be in effect at that time, or not, just because the politicians haven't made the decision today. How will you handle this? It may not be helpful if you get updated DST rules the day *after* the scheduled event. On the other hand, when the event time approaches and you have the chance to get a DST rule update before the event time everything may be fine, if a decision is taken either to keep the UTC time *or* the local time for this event. Since UTC is actually used in most computers to keep the system time and schedule events based on an accurate UTC time it may not be helpful to do this with post-processing. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Phil W Lee wrote: Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec 2014 12:48:57 +0100 the perfect time to write: However, there is an important limitation: the tzdata version of the leap second file is missing an expiration date, so even if a program like ntpd could use this file directly it would never know if no more leap second has been scheduled after the last one mentioned in this file, or if the file just hasn't been updated recently enough. If it compared the file it has with the one available from tzdata, it could see if there was a difference - it's not exactly huge. Even better would be if a checksum or version number was available as well, so that could just be compared to the current one, and a new one only downloaded if required. This presumes you have access to version which is known to be current, but fails if it is not the case. See also my other reply. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: The main problem is that the underlying system time (often POSIX, which just counts seconds since an epoch) has the *same* time stamp art the beginning and end of the leap second. In order to do the conversion correctly you need to know if the current second is the leap second, or not, i.e. you need some status flag in addition to the raw (e.g. POSIX) timestamp. This is basically similar to what you have at the end of DST, where (in local time) a whole hour is passed twice. You need to know the DST status to determine unambiguously if it's the first or the second turn. Yes, but in situations where you care about that you store just the system time, and the conversion to local time can be repeated later. Thanks to the powerful conversion routines in glibc this can be done even way in the past (because it remembers DST rules from previous years). Agreed, for this case it works, due to effort of the tzdata maintainers. Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. Also agreed. However, actually ntpd expects UTC, not TAI. In spite of this it may eventually work if you set up an NTP server where the system time runs on TAI and you use one of the right time zones which are also part of the tzdata package. I haven't tried this. You'd have to take care that ntpd does *not* announce leap seconds in this case, but you'd have to update the leap second information anyway, since otherwise the conversion done according to the right time zone rules would be wrong. ;-) A main reason for the problems with leap seconds is that POSIX has just ignored them when they defined their standards on timekeeping. That is the problem. And probably also the decision in Unix to count UTC seconds since Jan 1st, 1970 (instead of TAI seconds). Back then it did not matter that much in a timesharing system. The system clock was mainly a convenience feature, not critical to anything. (it usually had to be set on every boot and this was done by typing the time seen on the operator's wristwatch, hence the term wristwatch time) Again agreed. Using TAI for sytem time and a current leap second table would allow to convert TAI to UTC unambiguously. I think that's what the conversion routines do for the right timezones. On the other hand, maybe you have seen the discussions elsewhere why you can't use TAI for the system time for hypothetical reasons. Or at least you can't call it TAI. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: Imagine you set up an event for April 2015 today, but you just don't know if DST will be in effect at that time, or not, just because the politicians haven't made the decision today. How will you handle this? It may not be helpful if you get updated DST rules the day *after* the scheduled event. On the other hand, when the event time approaches and you have the chance to get a DST rule update before the event time everything may be fine, if a decision is taken either to keep the UTC time *or* the local time for this event. Since UTC is actually used in most computers to keep the system time and schedule events based on an accurate UTC time it may not be helpful to do this with post-processing. It depends on what kind of event it is. When it is a human event like a meeting, it is customary to plan these events in local time. So they should be stored in local time with a specified timezone. What UTC time this is will depend on the local time rules at the actual event time. It will still be tricky when you plan a meeting at 02:30 on the sunday of the DST change from summer-winter time. You cannot add a DST flag with the event because you cannot know if there will be a DST change at that time. Of course that is why the DST change is done at a moment where such problems are unlikely, and not for example at 12:00 on the first day of the month. Some calendering software gets this wrong, yes. E.g. by converting the specified local time to UTC time and storing that. This has caused problems in the past for well-known calendering software, I don't know if that has been fixed. For technical events it may be different, and storing them at the UTC time could be better. But scheduling software (Windows Scheduler, Unix cron) usually uses local time as well. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. Also agreed. However, actually ntpd expects UTC, not TAI. Of course it is a hypothetical situation. When the Unix developers would have had the foresight to define their clock in TAI rather than UTC, the NTP designer probably would have used TAI as well, and instead of the leap second handling there maybe would have been some field to broadcast the current UTC-TAI offset. GPS actually does it that way. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. Also agreed. However, actually ntpd expects UTC, not TAI. Of course it is a hypothetical situation. When the Unix developers would have had the foresight to define their clock in TAI rather than UTC, the NTP designer probably would have used TAI as well, and instead of the leap second handling there maybe would have been some field to broadcast the current UTC-TAI offset. Agreed. GPS actually does it that way. Yes, I know. I've by myself written a set of routines which decodes and evaluates the data broadcasted by the GPS satellites. IMO the GPS system designers have made quite a number of wise decisions, e.g. letting the GPS time simply increase monotonically, which is, from a technical/usage point of view, similar to TAI. AFAIK the GLONASS satellites use UTC instead, which causes an interruption in the sequence of data frames whenever a leap second occurs. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Phil W Lee writes: Leap seconds seem to be a real mess in the IT world. It would be useful if the way of inserting a leap-second was set in a standard, in such a way that time continued at a set rate (maybe by slewing at a set percentage or PPM). If that could be achieved, it would remove many of the objections to leap-seconds. It might be difficult to thrash out in practice though. NTF's General Timestamp API is ready to address this. We just need to get enough support to get the ball rolling. Some timescales have leapseconds, some do not. If a timescale has leap seconds, there are different ways it can be applied. As long as these choices are defined it's possible to usefully 'map' a timestamp taken in one (version of one) timescale to a timestamp in a different (version of a) timescale. I know that officially at present there is an additional second between 23:59:60 and 00:00:00, but no time recording system that I know of has the ability to record times between 23:59:60 and 00:00:00 correctly (despite such times existing since 1st Jan 1961, which must surely pre-date any software currently in use), which is a necessary requirement if the second is to be inserted exactly as currently specified and time continued forward (so that events are recorded in the correct order). Does anyone know of any software which will record times during that additional second accurately, e.g. as 23:59:60.789? There are implementations of this that can make it impossible. Nothing much can be done about things that occur during that extra second. If the implementation does something more ... accommodating, it is possible to track and map these events. Some systems will slow time by half, so the leap second occurs over 2 seconds. Some will slew it over 2 seconds. Google's leap smear does it unevenly over a 24-hour period. Is there any realistic prospect of forcing software to comply with a time standard which includes times between 23:59:60 and 00:00:00? I think so. And folks can always choose to track time using TAI and then map those events to the appropriate UTC. Now, you can either stipulate that all software including operation systems recognise times during that additional second - which would require re-writing the time functions of most of the worlds software to recognise and record times 23:59:60 00:00:00 (but only if a leap second has been legally notified), or you can agree to insert the additional second more gradually by clock slewing (but at what rate would have to be agreed). Clock slewing would require much more change to international agreements, but would require far less work on re-writing software, and would actually relate better to the real world, which is annoyingly both analogue AND irregular:-) Or the second itself could be redefined to take account of the actual speed the earth rotates - but that might be problematic for the scientists, as we'd likely have to keep doing it as the earth slows. I certainly think we need to deal with the problem better than we do at the moment. Please support/participate in NTF's GTSAPI Consortium. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Phil W Lee writes: Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec 2014 14:23:15 +0100 the perfect time to write: Harlan Stenn wrote: An alternative is that we get enough support to advance NTF's General Timestamp API, and then we can run systems on either TAI or UTC and these conversions will happen automatically. Since timescale files in the GTSAPI are versioned, one could still use an obsolete leapsecond file, and while those UTC timestamps would be wrong if a new leapsecond was added, these timestamps would be correctable when a new version of the UTC timescale file was available. Hm, that may not really help if the API returns a wrong UTC time stamp which is then used to set the system time wrong. While a traditional timestamp would have problems, if the system time uses the GTSAPI structure the wrong UTC timestamp would not be wrong, it would just be using the older timescale version. These can be remapped as needed. This is equivalent to the case where we want to do something in the future with an absolute UTC timestamp. The tzdist protocol could also be helpful here to provide the information required to do the conversion correctly. An expiration date could be used for versioning. Martin You don't need an expiry date if you have a version number and/or an authoritative source for any new version that may be available - you just compare the two, and use the newest available. As long as you have the timescale versions for the timestamps you are tracking, one can do the conversions. As long as the IERS stays at the same URL, you could just use their file at http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second.dat (although it would be useful if that file was more complete, with a version number and checksum). It would also be useful if they used SSL, and changed the url to https://etc. There are several timescales available there. Right now it's looking like we can use TAI as a canonical timescale and map that into different UTC timescales (they version every 6 months' or so) and we can do similarly with IERS-A timescales (which version every week). Then there are folks who will apply leap-seconds differently. This is to be expected, and must be dealt with. From what we've seen, this is doable. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: IMO the GPS system designers have made quite a number of wise decisions, e.g. letting the GPS time simply increase monotonically, which is, from a technical/usage point of view, similar to TAI. That decision was wise. The decision to express date in weeks and put it in a 10-bit field was not so wise. Oh well. AFAIK the GLONASS satellites use UTC instead, which causes an interruption in the sequence of data frames whenever a leap second occurs. I think GLONASS uses Moscow local time. I read that Galileo also has its own time scale (GST) synchronized to TAI and it broadcasts the time offset to GPS time expressed in nanoseconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki writes: Rob wrote: Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. Also agreed. However, actually ntpd expects UTC, not TAI. One of the things I'm thinking about for NTP5 is systems that choose to run in TAI and not UTC. This is a natural tie-in with NTF's General Timestamp API, as we need to know what timescale the remote system is using. This woud also handle the case of maintaining sync with a system that chooses to implement Google's leap smear, or even one that wanted to run on IERS-A time. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: Imagine you set up an event for April 2015 today, but you just don't know if DST will be in effect at that time, or not, just because the politicians haven't made the decision today. How will you handle this? It may not be helpful if you get updated DST rules the day *after* the scheduled event. On the other hand, when the event time approaches and you have the chance to get a DST rule update before the event time everything may be fine, if a decision is taken either to keep the UTC time *or* the local time for this event. Since UTC is actually used in most computers to keep the system time and schedule events based on an accurate UTC time it may not be helpful to do this with post-processing. It depends on what kind of event it is. When it is a human event like a meeting, it is customary to plan these events in local time. It depends even more. The tzdist folks are planning to use a reference to a specific time zone instead of the TZ rules which have been in effect when the event was created. I've recently posted some consideration on the tzdst mailing list: http://www.ietf.org/mail-archive/web/tzdist/current/msg01063.html So they should be stored in local time with a specified timezone. What UTC time this is will depend on the local time rules at the actual event time. It will still be tricky when you plan a meeting at 02:30 on the sunday of the DST change from summer-winter time. You cannot add a DST flag with the event because you cannot know if there will be a DST change at that time. Of course that is why the DST change is done at a moment where such problems are unlikely, and not for example at 12:00 on the first day of the month. That's why IMO they should be stored in UTC time (or even TAI, if that was possible), and only presented to the user in preferred local time zone. I've posted some thoughts for the case that the TZ/DST rules change afterwards in my email behind the link above. Some calendering software gets this wrong, yes. E.g. by converting the specified local time to UTC time and storing that. This has caused problems in the past for well-known calendering software, I don't know if that has been fixed. For technical events it may be different, and storing them at the UTC time could be better. But scheduling software (Windows Scheduler, Unix cron) usually uses local time as well. Unfortunately it seems to be common practice today to write software in a way it is quickly ready and works in most cases, without thinking about different cases or what happens if anything is not as usually expected. See the discussion about the expiration date of the leap second table. It is not hard to implement this, and if it is supported it allows software to be written in a user-friendly way which allows to generate a warning to users or admin saying that interaction may be required, e.g. information (leap second tables, DST rules) need to be updated. Of course you can say a good admin has to take care of this, but I'm sure an admin would be happy if he received a reminder just in case he doesn't remember a specific task. And of course you can say this works perfectly without expiration date if every tiny client gets the current data via an SSL connection directly from NIST, IERS, or IANA, but if you *do* provide an expiration date both this works nevertheless in the same way, but allows for extended usage which is more user-friendly and thus avoids potential risks. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: IMO the GPS system designers have made quite a number of wise decisions, e.g. letting the GPS time simply increase monotonically, which is, from a technical/usage point of view, similar to TAI. That decision was wise. The decision to express date in weeks and put it in a 10-bit field was not so wise. Oh well. Only the 10 bit field wasn't. However, for a pure navigation system this doesn't matter at all. Only if you need the current legal date and time the epoch matters. With regard to this, using only a truncated 8 bit week number to specify the week of a leap second event is also not the best solution. It can only handle a +/-127 week interval, and expanding this to a full date is ambiguous if there was no leap second event for a period exceeding this interval. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: IMO the GPS system designers have made quite a number of wise decisions, e.g. letting the GPS time simply increase monotonically, which is, from a technical/usage point of view, similar to TAI. That decision was wise. The decision to express date in weeks and put it in a 10-bit field was not so wise. Oh well. Only the 10 bit field wasn't. However, for a pure navigation system this doesn't matter at all. Only if you need the current legal date and time the epoch matters. Sure, but when your require the system only for navigation and not to provide time there is no reason whatsoever to sync it with any known time standard or even to tick in units of a second. Apparently the application of providing UTC time was considered in the design phase, but it was never thought the system would be deployed and would remain operational and be widely universally used for more than 19 years. In this regard, it is similar to the Internet. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Harlan Stenn wrote: Martin Burnicki writes: Rob wrote: Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. Also agreed. However, actually ntpd expects UTC, not TAI. One of the things I'm thinking about for NTP5 is systems that choose to run in TAI and not UTC. This is a natural tie-in with NTF's General Timestamp API, as we need to know what timescale the remote system is using. Of course. However, you would anyway need the current rules or algorithms required to do the conversion. This woud also handle the case of maintaining sync with a system that chooses to implement Google's leap smear, Do you know the *exact* algorithm how Google smears a leap second? If you don't know it there will be differences in the time computed by standard ntpd v5 and Google's. ;-) Martin ___ 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-16 10:28, Phil W Lee wrote: Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec 2014 12:48:57 +0100 the perfect time to write: Brian Inglis wrote: It would be interesting to know what percentage of the pool servers even use a leapseconds file, and how many of those have a valid copy. I am certain that very few clients use a leapseconds file. OTOH the timezone/zoneinfo package uses its own leapseconds file (for right time - now zoneinfo-leaps), and distributes that and the original, a script that checks and converts it to their own format, and utilities that use it. As far as I can see the the leap second file shipped with the tzdata package is generated automatically from a leap second file in NIST format. However, there is an important limitation: the tzdata version of the leap second file is missing an expiration date, so even if a program like ntpd could use this file directly it would never know if no more leap second has been scheduled after the last one mentioned in this file, or if the file just hasn't been updated recently enough. If it compared the file it has with the one available from tzdata, it could see if there was a difference - it's not exactly huge. Even better would be if a checksum or version number was available as well, so that could just be compared to the current one, and a new one only downloaded if required. The HTTP modified header does that well if provided by the web server for a file - it is for most files on most web servers, also for FTP files. All my network update scripts use wget -N to timestamp files and check the modified header to see if an update needs downloaded. Update scripts can then check to see if a file timestamp, and internal expiry date, release date, or version number has changed, and checksums are correct, to decide whether to apply the update, or if it can be skipped. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki writes: Harlan Stenn wrote: Martin Burnicki writes: Rob wrote: Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. Also agreed. However, actually ntpd expects UTC, not TAI. One of the things I'm thinking about for NTP5 is systems that choose to run in TAI and not UTC. This is a natural tie-in with NTF's General Timestamp API, as we need to know what timescale the remote system is using. Of course. However, you would anyway need the current rules or algorithms required to do the conversion. This woud also handle the case of maintaining sync with a system that chooses to implement Google's leap smear, Do you know the *exact* algorithm how Google smears a leap second? If you don't know it there will be differences in the time computed by standard ntpd v5 and Google's. ;-) I know what they've published. If we assign unique leap method numbers and folks actually use these properly, at worst we would say Don't sync with Google Leap Smear machines on the day a leap second is being processed. If a system is using an older NTP it will ID as v4, and any ntp5 instances will be able to know to be careful. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Brian Inglis wrote: It would be interesting to know what percentage of the pool servers even use a leapseconds file, and how many of those have a valid copy. I am certain that very few clients use a leapseconds file. OTOH the timezone/zoneinfo package uses its own leapseconds file (for right time - now zoneinfo-leaps), and distributes that and the original, a script that checks and converts it to their own format, and utilities that use it. As far as I can see the the leap second file shipped with the tzdata package is generated automatically from a leap second file in NIST format. However, there is an important limitation: the tzdata version of the leap second file is missing an expiration date, so even if a program like ntpd could use this file directly it would never know if no more leap second has been scheduled after the last one mentioned in this file, or if the file just hasn't been updated recently enough. There is an ongoing discussion about a new tzdist protocol which could be used to deploy updated time zone rules as published by the tzdata package automatically, without the need to pull in a new tzdata package in the form of a software update. This sounds like a very good extension to programs like ntpd: - NTP (or PTP) takes cares that the computer's UTC time is correct - tzdist takes care that the DST rules are updated automatically The latter may not be too important for countries where the DST rules don't change very often, but can be *very* helpful for countries like Morocco, Egypt, or Israel, where these rules are changed every year, and the decisions on the beginning or end of DST are only published a few days before they actually happen. Since the tzdist protocol also provides historical time zone information I have proposed on the tzdist mailing list also to include a list of leap second events in a generic format, which would also allow to compute accurate time intervals across past leap second events. Of course this proposal includes an expiration date. Such leap second table could be used to provide programs like ntpd or ptpd with automatic updates from a tzdist client, without having to copy a file the exact name you may not know from an FTP or HTTP server of which you don't know if you are allowed to access it from your geographic location (there have been such restrictions in the past). Unfortunately most participants in the discussion on the tzdist mailing list don't seem to accept the importance of a generic way to distribute a leap seconds table. Instead, they seem to prefer to accept a way to distribute the leap second file as provided by tzdata (without expiration date) in a binary format. Beside this, IMO the IERS should be the authoritative source for a leap second file since it is the institution deciding whether a leap second is to be scheduled, or not. I've proposed this to the IERS folks, and the replied they would think about this. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
William Unruh wrote: The importance of trades is usually a before/after. And UTC TAI, GPS all have exactly the same definition of before and after. Of course if one time was in UTC and the otehr in TAI, that could well be successfully argued. From a technical point I absolutely agree with you. However, there have been discussions (IIRC on the TZ or leapsecs mailing lists) where folks tried to explain that even though the difference between TAI and UTC is just an integral number of seconds, TAI could not even be used as a replacement for UTC without leap seconds, just due to specific wordings in certain documents. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
An alternative is that we get enough support to advance NTF's General Timestamp API, and then we can run systems on either TAI or UTC and these conversions will happen automatically. Since timescale files in the GTSAPI are versioned, one could still use an obsolete leapsecond file, and while those UTC timestamps would be wrong if a new leapsecond was added, these timestamps would be correctable when a new version of the UTC timescale file was available. Sorry for the long sentence - it's getting close to 0500 for me and I'm getting tired. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki writes: Harlan Stenn wrote: An alternative is that we get enough support to advance NTF's General Timestamp API, and then we can run systems on either TAI or UTC and these conversions will happen automatically. Since timescale files in the GTSAPI are versioned, one could still use an obsolete leapsecond file, and while those UTC timestamps would be wrong if a new leapsecond was added, these timestamps would be correctable when a new version of the UTC timescale file was available. Hm, that may not really help if the API returns a wrong UTC time stamp which is then used to set the system time wrong. Anything on the box that uses UTC in this situation will be using an outdated UTC timescale, and when any newer versions are made available the library API will handle the conversion. Think of the case where you want to set an event for a future time - if you want to tag something with an absolute time of 10am UTC a year in the future, there's no way to know if there will be a leap second in there or not. So as we get closer to the actual date, if the UTC timescale gets updated the absolute UTC timestamp will be properly adjusted as soon as we know. Similar things happen if one is using an IERS timescale, which gets a new version every week. The tzdist protocol could also be helpful here to provide the information required to do the conversion correctly. An expiration date could be used for versioning. I'm sure that will play a factor in this, and the timescale version stuff will be covering a number of different timescales. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
William Unruh wrote:
I for one would trust time from a gps pps a lot lot more
than that from even 3 other servers. And yes, I could be
fooled. Just as you might trust advice from David Mills
much more than any 5 other posters here
( and would probably be very resistant to a majority vote
determination that David is a falseticker) but that does
not give a guarentee that you could not be led astray sometime.
Trusting the GPS (so far) might be the better choice.
However, as governments (Militarys') are occasionally
testing GPS spoofing {As opposed to plain Jamming};
Some day the GPS receiver may be picking up four
or more things it thinks are satellites,
but are really stronger / closer transmitters,
that are providing false data;
Perhaps based on the real data, but e.g. slowly slewing
the positions off from their true positions.
There is no reason they might not e.g. mess with the
L1 C/A PRN Subframe 1 handover word (time)
or GPS time offset, while messing with
the Subframes 2/3 ephemeris data orbital information;
They might even do the same for the L1C (since its on
the same band).
They would have to block the receiver(s) from getting
and real sat data, as it might still get the correct
time (and other data) from e.g. L2C and L5 messages,
e.g. Jamming L2 L5 frequencies ...
I suppose a modern GPS receiver might determine something is wrong,
based on not getting valid L2 /or L5 messages,
and indicate it through a fix quality message
and then NTP might consider how much it trusts that receiver,
based on the fix quality value
(as opposed to just using the fix good / bad)
but that is not yesterdays GPS receiver or NTP.
A Local External PPS Rubidium / Cesium RefClock,
could also make it easier for NTP to sort out.
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Jan Ceuleers writes: On 14/12/14 03:28, Harlan Stenn wrote: Not that easy - unless you are one of the lucky few to have encrypted access to a NIST source, when it may be automatic. http://www.ietf.org/timezones/data/leap-seconds.list Added to the Wiki at http://support.ntp.org/bin/view/Support/ConfiguringNTP The IETF also serve their content over SSL if anyone thinks this increases the level of trust one can have in that content. Awesome, thanks Jan! H ___ 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-13 19:28, Harlan Stenn wrote: Brian Inglis writes: On 2014-12-12 03:25, Harlan Stenn wrote: It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Not that easy - unless you are one of the lucky few to have encrypted access to a NIST source, when it may be automatic. http://www.ietf.org/timezones/data/leap-seconds.list Well aware of that source, as I said, and you trimmed: OTOH the timezone/zoneinfo package uses its own leapseconds file (for right time - now zoneinfo-leaps), and distributes that and the original, a script that checks and converts it to their own format, and utilities that use it. but not exactly widely known as a source, unless one subscribes to that list. Many time server operators outside the US may be unaware of where to find NIST servers and the leap-seconds.list file. When deprecated Autokey is replaced by Network Time Security, there does not seem to be any mention of including leap seconds distribution as part of the new functions, from what I have been able to read so far. This would be a useful addition and may be an essential requirement if times need to be within a second, or legally useful. For something that is critical to correct timekeeping, and puts a proportion of servers over the step threshold every 18-24 months, updating leap seconds should be part of the normal time service protocol, or an adjunct, not just encrypted connections to NIST servers, or a manual or custom process, available from only a few sources, all in the US, which may be blocked in some countries. Global availability and better distribution of leap second information for use by time servers should be considered an essential service and source by anyone who relies on those servers for legal time, such as financial traders. Legal civil time in most countries is defined as mean solar time, where it is not still defined relative to GMT, as it is in most countries in the Commonwealth of Nations deriving their common laws from England, and many allied European and Asian countries. This can be validated from the posts of official time change notices referenced on the timezone list. Any departure of timekeeping from legal civil time will be viewed negatively by the courts, as it has in past precedents. The opinions of astronomers and physicists, who picked a century out of date value by solar standards when they defined the second, along with an incremental update approach that was used for a few years before being discarded in favour of using leapseconds, are insignificant compared to the politicians and courts who change and interpret legal definitions, which require noon to be, in the mean, about the same solar time each day. I am somewhat surprised that no lawyer has, as yet, argued for phone evidence to be discarded because telco equipment uses TAI or GPS time scales which have no legal basis in any country. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Le 14 déc. 2014 à 08:24, Jan Ceuleers jan.ceule...@computer.org a écrit : On 14/12/14 03:28, Harlan Stenn wrote: Not that easy - unless you are one of the lucky few to have encrypted access to a NIST source, when it may be automatic. http://www.ietf.org/timezones/data/leap-seconds.list Or the Navy wget ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.3617308800 not sure where the issue is here. Added to the Wiki at http://support.ntp.org/bin/view/Support/ConfiguringNTP The IETF also serve their content over SSL if anyone thinks this increases the level of trust one can have in that content. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On Sun, 14 Dec 2014 08:02:08 GMT, Mike Cook michael.c...@sfr.fr wrote: Or the Navy wget ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.3617308800 not sure where the issue is here. You can only use wget if you know the file name. The one at NIST is different: ftp://time.nist.gov/pub/leap-seconds.3535228800 The file at NIST is identical to the leap-seconds.list file at IETF referred to by Harlan Stenn. leap-seconds.3617308800 has an _earlier_ expiration date (27 days) and fewer comments. The leap second data is the same. -- Roger ___ 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/14/2014 09:04 AM, Brian Inglis wrote: Legal civil time in most countries is defined as mean solar time, where it is not still defined relative to GMT, as it is in most countries in the Commonwealth of Nations deriving their common laws from England, and many allied European and Asian countries. Hm. Is that really the case? The current German legislation refers to coordinated world time (which might be taken as referring to TAI just as well as to UTC, as far as I can understand) and assigns the task of distributing the legal time to the PTB (which could be construed as ruling anything besides DCF77-based notions of time not the legal thing; BTW, DCF77 announces leap seconds only about an hour before the fact, with no specs *asserting* so that I could find). http://www.gesetze-im-internet.de/me_einhg/__4.html I am somewhat surprised that no lawyer has, as yet, argued for phone evidence to be discarded because telco equipment uses TAI or GPS time scales which have no legal basis in any country. Too easily countered by actual measurements showing that the equipment's notion of time never strayed more than a worst-case total of X ms (or, a la rigeur, X seconds) from the notion mandated by the legalese, I'ld guess. It's not like the courts would turn a blind eye to evidence just because they'ld prefer an official endorsement by the parliament. (Always assuming that the facts needing confirmation allow for that much deviation, of course. But high-speed trades aren't concluded on devices on a GSM network, are they?) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ 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-15, Jochen Bern jochen.b...@linworks.de wrote: On 12/14/2014 09:04 AM, Brian Inglis wrote: Legal civil time in most countries is defined as mean solar time, where it is not still defined relative to GMT, as it is in most countries in the Commonwealth of Nations deriving their common laws from England, and many allied European and Asian countries. That is certainly not true. All places use time zones, which are not mean solar time (except sometimes on one particular latitude in the country, but not even always that). Hm. Is that really the case? The current German legislation refers to coordinated world time (which might be taken as referring to TAI just as well as to UTC, as far as I can understand) and assigns the task of I doubt it. It refers to Middle European Time, and says that is defined by the coordinated world (or universal) time plus an hour (or 2 for summer time). And from Wikipedia, Coordinated Universal Time (French: temps universel coordonné, UTC). And from Wikipedia.de Die koordinierte Weltzeit (englisch Coordinated Universal Time, französisch Temps universel coordonnÃ, kurz UTC (englisch Universal Time, Coordinated) So, while Wikipedia is not German law, the use of the terms seems to be pretty unambiguous. distributing the legal time to the PTB (which could be construed as ruling anything besides DCF77-based notions of time not the legal thing; BTW, DCF77 announces leap seconds only about an hour before the fact, with no specs *asserting* so that I could find). http://www.gesetze-im-internet.de/me_einhg/__4.html I am somewhat surprised that no lawyer has, as yet, argued for phone evidence to be discarded because telco equipment uses TAI or GPS time scales which have no legal basis in any country. Since they differ from UTC by a trivial amount, the lawyer could argue it, but would not get very far. Too easily countered by actual measurements showing that the equipment's notion of time never strayed more than a worst-case total of X ms (or, a la rigeur, X seconds) from the notion mandated by the legalese, I'ld guess. It's not like the courts would turn a blind eye to evidence just because they'ld prefer an official endorsement by the parliament. (Always assuming that the facts needing confirmation allow for that much deviation, of course. But high-speed trades aren't concluded on devices on a GSM network, are they?) The importance of trades is usually a before/after. And UTC TAI, GPS all have exactly the same definition of before and after. Of course if one time was in UTC and the otehr in TAI, that could well be successfully argued. ___ 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-12 03:25, Harlan Stenn wrote: It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Not that easy - unless you are one of the lucky few to have encrypted access to a NIST source, when it may be automatic. You have to use a NIST server, as no other sources provide access to the NIST leapseconds file, find one where FTP access is available and/or works reliably from your system, schedule a download every six months, check the signature, and if all goes well, replace your current file. They also use their own weird approach to checking the file signature from the last century, and source code to build to do so, rather than standard approaches built into utilities available for and on modern systems. You also have to specify in ntp.conf where the leapseconds file is stored, whereas most other external configuration information can be passed on the ntpd command line. It would be interesting to know what percentage of the pool servers even use a leapseconds file, and how many of those have a valid copy. I am certain that very few clients use a leapseconds file. OTOH the timezone/zoneinfo package uses its own leapseconds file (for right time - now zoneinfo-leaps), and distributes that and the original, a script that checks and converts it to their own format, and utilities that use it. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Brian Inglis writes: On 2014-12-12 03:25, Harlan Stenn wrote: It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Not that easy - unless you are one of the lucky few to have encrypted access to a NIST source, when it may be automatic. http://www.ietf.org/timezones/data/leap-seconds.list H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 14/12/14 03:28, Harlan Stenn wrote: Not that easy - unless you are one of the lucky few to have encrypted access to a NIST source, when it may be automatic. http://www.ietf.org/timezones/data/leap-seconds.list Added to the Wiki at http://support.ntp.org/bin/view/Support/ConfiguringNTP The IETF also serve their content over SSL if anyone thinks this increases the level of trust one can have in that content. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
To close this parenthesis I did the test for leap second only being propagated by 1 of three servers and Bill’s hypothesis is confirmed with a couple of precisions that I would like to share as it might just be a real life case. a) To start off , in my test all three servers to my one client are sync’d to the same time. One of them has a leap file modified for my test. As UTC is defined WITH leap seconds, although all servers are sync’d, this is the ONLY one serving UTC. It correctly advertises the upcoming leap. b) When the leap occurs, the server with the leap file correctly inserts the leap, as does the client. The client’s NTP correctly detects the step and after a few polls correctly flags the UTC server as falsticker as the majority are consistently in disagreement with the now updated clock. Thu Jan 1 01:06:05 CET 2015 remote refid st t when poll reach delay offset jitter == *192.168.1.15 .GPS1. 1 u 42 64 377 0.495 999.894 534.506 +192.168.1.17 .GPS1. 1 u 39 64 377 0.564 999.899 654.645 x192.168.1.18 .GPS1. 1 u 66 64 377 0.575 -0.066 0.029 Now we have the full story and the « good » clock has been declared falsticker as not part of the majority but the story doesn't end there. A bit later the clients clock, which is at the time on UTC with leap second, gets stepped forward 1 sec to be in agreement with the majority. This is expected, but we have a client which now has not got good time. Thu Jan 1 01:11:27 CET 2015 remote refid st t when poll reach delay offset jitter == 192.168.1.15 .GPS1. 1 u 14 16 3 0.488 -0.039 0.038 *192.168.1.17 .GPS1. 1 u 22 64 1 0.516 -0.044 0.031 192.168.1.18 .GPS1. 1 u 14 16 3 0.566 -999.99 0.052 Thu Jan 1 01:12:31 CET 2015 remote refid st t when poll reach delay offset jitter == Final status with the UTC server redeclared as a falsticker. Thu Jan 1 01:15:38 CET 2015 remote refid st t when poll reach delay offset jitter == +192.168.1.15 .GPS1. 1 u 46 64 77 0.488 -0.039 0.047 *192.168.1.17 .GPS1. 1 u 17 64 37 0.520 -0.054 0.032 x192.168.1.18 .GPS1. 1 u 47 64 77 0.575 -999.99 0.053 This test was to verify a worst case scenario but shows that when administrators are preparing for a leap, they need to make sure that a majority of servers will be making the leap and propagate that info. This is not always easy as query commands are routinely blocked by some internet servers. Note : There is a possible bug or RFE required somewhere as the clock variable tai is not correctly set on the client. On the server that has the leap file we have the correct update rom 35 to 36 : mike@raspB4 ~ $ ntpq -c rv 0 tai tai=36 But on the client which has no leap file (and probably because of this) tai has been set to 1. So I think that what is happening is that the server notion of tai is not propagated to clients. mike@cubieez2:~$ ntpq -c rv 0 tai tai=1 There will most likely be a leap declared for the end of Jul 1 2015 or latest Jan 1 2016 so we have a bit of time yet to clean up the park. Le 9 déc. 2014 à 14:20, Mike Cook michael.c...@sfr.fr a écrit : snip Three are fine, as long as only one dies or goes nuts. Again, define goes nuts. You don't seem to like the term falseticker, so how do you define goes nuts? If one goes nuts or even goes offline, if the remaining two do not agree then it is like having no server at all. No, it is like having two, with one being out. falseticker is a term with a very specific internal definition. Thus a server whose time is right on UTC could be a falseticker, because the other two servers were both exactly 3 days out, with tiny jitter estimates. I would say then that you had two servers going nuts, and one good, even though ntpd would say there were two good and one false ticker. In fact this does not happen. I just tested the hypothesis. What happens depends on how the two wayward get there exaggerated offset: a) someone,something resets the date: result: ntp on both those servers crashes due to the panic_stop limit. So in this case the client has only one reference and continues using that. It is not flagged as a falsticker. That is normal. b) someone restarts ntp on the servers with the wrong date. Here the servers ntpd has no way of knowing that it has bad time and so continues serving normally. On the client. The running ntp sees immediately a huge offset and huge jitter. Tue Dec 9 13:15:04 CET 2014 remote refid st t when poll reach delay offset jitter == *192.168.1.15.GPS1. 1 u 320 64 3600.5490.040 0.037 +192.168.1.16.GPS2. 1 u
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Mike, I think you are seeing the correct and expected behavior. The root cause here is that the majority of the upstream servers are *incorrectly* not advertising the leap second. There have been problems before where a misconfigured server has incorrectly advertised a non-existent leap-second, and in cases where folks had an adequate number of correctly configured servers, this mistake was properly ignored. I have not been closely following this thread, so I might be missing something. It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Or am I missing something? -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
I agree that it is expected. Just wanted to confirm for myself. Habit from my admin/support days. Agreed that anyone needing the tai delta would load the leap file, but ntpd could propagate that info as well. I haven’t checked the code to see if it is supposed to, but in my test it wasn’t. Le 12 déc. 2014 à 11:25, Harlan Stenn st...@ntp.org a écrit : Mike, I think you are seeing the correct and expected behavior. The root cause here is that the majority of the upstream servers are *incorrectly* not advertising the leap second. There have been problems before where a misconfigured server has incorrectly advertised a non-existent leap-second, and in cases where folks had an adequate number of correctly configured servers, this mistake was properly ignored. I have not been closely following this thread, so I might be missing something. It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Or am I missing something? -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ 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-12, Harlan Stenn st...@ntp.org wrote: Mike, I think you are seeing the correct and expected behavior. The root cause here is that the majority of the upstream servers are *incorrectly* not advertising the leap second. There have been problems before where a misconfigured server has incorrectly advertised a non-existent leap-second, and in cases where folks had an adequate number of correctly configured servers, this mistake was properly ignored. I have not been closely following this thread, so I might be missing something. It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Or am I missing something? Yes, That it was an example of a case in which the correct time server could be declared a falseticker. The answer you give never use sources which might not deliver the correct time does not obviate the point. The concept of falseticker and of bad time are not the same thing. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
William Unruh writes: On 2014-12-12, Harlan Stenn st...@ntp.org wrote: Mike, I think you are seeing the correct and expected behavior. The root cause here is that the majority of the upstream servers are *incorrectly* not advertising the leap second. There have been problems before where a misconfigured server has incorrectly advertised a non-existent leap-second, and in cases where folks had an adequate number of correctly configured servers, this mistake was properly ignored. I have not been closely following this thread, so I might be missing something. It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Or am I missing something? Yes, That it was an example of a case in which the correct time server could be declared a falseticker. The answer you give never use sources which might not deliver the correct time does not obviate the point. The concept of falseticker and of bad time are not the same thing. Nobody is saying never use sources which might not deliver correct time. Aside from that: - what is the effective difference between a falseticker and a server that provides bad time? - Is this difference really significant? - If so, how can ntpd determine the difference between a falseticker and a server that provides bad time? - what real benefits does one get from knowing the difference? I'm sure a few more questions can come up, but I'm more interested in seeing if there might be something useful going on here, other than coming up with more issues that NTF's nascent Certification and Compliance programs should watch for. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ 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-13, Harlan Stenn st...@ntp.org wrote: William Unruh writes: On 2014-12-12, Harlan Stenn st...@ntp.org wrote: Mike, I think you are seeing the correct and expected behavior. The root cause here is that the majority of the upstream servers are *incorrectly* not advertising the leap second. There have been problems before where a misconfigured server has incorrectly advertised a non-existent leap-second, and in cases where folks had an adequate number of correctly configured servers, this mistake was properly ignored. I have not been closely following this thread, so I might be missing something. It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Or am I missing something? Yes, That it was an example of a case in which the correct time server could be declared a falseticker. The answer you give never use sources which might not deliver the correct time does not obviate the point. The concept of falseticker and of bad time are not the same thing. Nobody is saying never use sources which might not deliver correct time. Aside from that: - what is the effective difference between a falseticker and a server that provides bad time? See above. - Is this difference really significant? See above. - If so, how can ntpd determine the difference between a falseticker and a server that provides bad time? It cannot easily. All it can do is decide that something is a falseticker. But noone should think, or say, that that means that the falseticker is a bad time source. It may be the best that ntpd can do. That does not mean that problems cannot arise precisely because of that. One could for example simply use all the time sources and use them all. That has advantages and (as you will be the first to point out) disadvantages. Or you could decide that your own clock is a reasonable flywheel, and test the outside clocks over time against your won. If you find you own, while it freewheels, roughly tracks one of the timesources, you have additional evidence that the one may well be ticking at the right rate. Yes, this both requires long term memory, and can certainly at times lead you astray. I am sure I could think of other possibilities as well. - what real benefits does one get from knowing the difference? Clarity in what one is talking about. Care in setting up one's system. knowledge of what the problems can be. Since the purpose of ntpd is to have your computer track the correct time ( not the majority time) as closely as possible, realising that there may be difference makes you think differently while developing a system. What are the costs and benefits of the various possible ways of trying to disentable the correct time from the various reports delivered by the servers. Maybe majority vote is the best way, but it is certainly not the only way or even the ideal way in all circumstances. I for one would trust time from a gps pps a lot lot more than that from even 3 other servers. And yes, I could be fooled. Just as you might trust advice from David Mills much more than any 5 other posters here ( and would probably be very resistant to a majority vote determination that David is a falseticker) but that does not give a guarentee that you could not be led astray sometime. I'm sure a few more questions can come up, but I'm more interested in seeing if there might be something useful going on here, other than coming up with more issues that NTF's nascent Certification and Compliance programs should watch for. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Bill, I'm done trying to have a productive discussion with you about this. H William Unruh writes: On 2014-12-13, Harlan Stenn st...@ntp.org wrote: William Unruh writes: On 2014-12-12, Harlan Stenn st...@ntp.org wrote: Mike, I think you are seeing the correct and expected behavior. The root cause here is that the majority of the upstream servers are *incorrectly* not advertising the leap second. There have been problems before where a misconfigured server has incorrectly advertised a non-existent leap-second, and in cases where folks had an adequate number of correctly configured servers, this mistake was properly ignored. I have not been closely following this thread, so I might be missing something. It's pretty easy to download and install a leapsecond file, and ntpd will pay attention to that... Or am I missing something? Yes, That it was an example of a case in which the correct time server could be declared a falseticker. The answer you give never use sources which might not deliver the correct time does not obviate the point. The concept of falseticker and of bad time are not the same thing. Nobody is saying never use sources which might not deliver correct time. Aside from that: - what is the effective difference between a falseticker and a server that provides bad time? See above. - Is this difference really significant? See above. - If so, how can ntpd determine the difference between a falseticker and a server that provides bad time? It cannot easily. All it can do is decide that something is a falseticker. Bu t noone should think, or say, that that means that the falseticker is a bad time source. It may be the best that ntpd can do. That does not mean that problems cannot arise precisely because of that. One could for example simply use all the time sources and use them all. That has advantages and (as you will be the first to point out) disadvantages. Or you could decide that your own clock is a reasonable flywheel, and test the outside clocks over time against your won. If you find you own, while it freewheels, roughly tracks one of the timesources, you have additional evidence that the one may well be ticking at the right rate. Yes, this both requires long term memory, and can certainly at times lead you astray. I am sure I could think of other possibilities as well. - what real benefits does one get from knowing the difference? Clarity in what one is talking about. Care in setting up one's system. knowledge of what the problems can be. Since the purpose of ntpd is to have your computer track the correct time ( not the majority time) as closely as possible, realising that there may be difference makes you think differently while developing a system. What are the costs and benefits of the various possible ways of trying to disentable the correct time from the various reports delivered by the servers. Maybe majority vote is the best way, but it is certainly not the only way or even the ideal way in all circumstances. I for one would trust time from a gps pps a lot lot more than that from even 3 other servers. And yes, I could be fooled. Just as you might trust advice from David Mills much more than any 5 other posters here ( and would probably be very resistant to a majority vote determination that David is a falseticker) but that does not give a guarentee that you could not be led astray sometime. I'm sure a few more questions can come up, but I'm more interested in seeing if there might be something useful going on here, other than coming up with more issues that NTF's nascent Certification and Compliance programs should watch for. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 08/12/2014 21:22, E-Mail Sent to this address will be added to the BlackLists wrote: [] I would have thought the WAN's additional delay, and increased jitter (as compared to the LAN) would have mattered more in the cluster algorithm, causing the internet servers to be tagged as outliers, if they were not close enough to make it into the cluster. Was the dispersion from the LAN servers higher than the internet servers, due to auto increasing poll times? I would have thought that as well, but before I ran my own stratum-1 servers I was often surprised at the choices made by NTP - distant servers with more jitter being preferred over local ones. Almost as if the value of jitter/offset was being minimised. But this was some years back -- 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
snip Three are fine, as long as only one dies or goes nuts. Again, define goes nuts. You don't seem to like the term falseticker, so how do you define goes nuts? If one goes nuts or even goes offline, if the remaining two do not agree then it is like having no server at all. No, it is like having two, with one being out. falseticker is a term with a very specific internal definition. Thus a server whose time is right on UTC could be a falseticker, because the other two servers were both exactly 3 days out, with tiny jitter estimates. I would say then that you had two servers going nuts, and one good, even though ntpd would say there were two good and one false ticker. In fact this does not happen. I just tested the hypothesis. What happens depends on how the two wayward get there exaggerated offset: a) someone,something resets the date: result: ntp on both those servers crashes due to the panic_stop limit. So in this case the client has only one reference and continues using that. It is not flagged as a falsticker. That is normal. b) someone restarts ntp on the servers with the wrong date. Here the servers ntpd has no way of knowing that it has bad time and so continues serving normally. On the client. The running ntp sees immediately a huge offset and huge jitter. Tue Dec 9 13:15:04 CET 2014 remote refid st t when poll reach delay offset jitter == *192.168.1.15.GPS1. 1 u 320 64 3600.5490.040 0.037 +192.168.1.16.GPS2. 1 u 37 64 3770.6060.006 0.028 +192.168.1.17.GPS1. 1 u 309 64 3600.5760.027 0.025 Tue Dec 9 13:16:08 CET 2014 remote refid st t when poll reach delay offset jitter == 192.168.1.15.GPS1. 1 u 55 64 3410.5650.042 9660780 *192.168.1.16.GPS2. 1 u 37 64 3770.6060.006 0.024 192.168.1.17.GPS1. 1 u 42 64 3410.5790.041 9660773 After 5 mins the client is unable to resolve this and declares all clock falsetickers and then panics. I did not have ntpd in debug mode here, but it is reasonable to assume that it panics due to the selected clock being too far out and hitting the panic limit. Tue Dec 9 13:23:37 CET 2014 remote refid st t when poll reach delay offset jitter == 192.168.1.15.GPS1. 1 u 45 64 3770.596 -255600 155.539 *192.168.1.16.GPS2. 1 u 25 64 3770.6140.024 0.008 192.168.1.17.GPS1. 1 u 30 64 3770.583 -255600 52.806 Tue Dec 9 13:24:41 CET 2014 remote refid st t when poll reach delay offset jitter == x192.168.1.15.GPS1. 1 u 43 64 3770.596 -255600 179.609 x192.168.1.16.GPS2. 1 u 23 64 3770.6140.024 0.008 x192.168.1.17.GPS1. 1 u 27 64 3770.618 -255599 6.009 /usr/local/bin/ntpq: read: Connection refused Tue Dec 9 13:25:45 CET 2014 /usr/local/bin/ntpq: read: Connection refused This is exactly what happens if the client is restarted. clock_filter: n 1 off -255599.997967 del 0.000662 dsp 7.937502 jit 0.02 select: endpoint -1 -255600.000806 select: endpoint 1 -255599.995128 select: survivor 192.168.1.17 0.002839 select: combine offset -255599.997967134 jitter 0.0 event at 1 192.168.1.17 903a 8a sys_peer clock_update: at 1 sample 1 associd 18641 event at 1 0.0.0.0 c617 07 panic_stop -255600 s; set clock manually within 1000 s. event at 1 0.0.0.0 c61d 0d kern kernel time sync disabled So ntp does NOT continue in your test case. Your case may be better if the time difference is less than the panic limit. Say if the two servers do not insert a leap second, but the « correct » one does. I’ll try that for my own satisfaction if I can figure how to do it. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ 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-09, Mike Cook michael.c...@sfr.fr wrote: snip Three are fine, as long as only one dies or goes nuts. Again, define goes nuts. You don't seem to like the term falseticker, so how do you define goes nuts? If one goes nuts or even goes offline, if the remaining two do not agree then it is like having no server at all. No, it is like having two, with one being out. falseticker is a term with a very specific internal definition. Thus a server whose time is right on UTC could be a falseticker, because the other two servers were both exactly 3 days out, with tiny jitter estimates. I would say then that you had two servers going nuts, and one good, even though ntpd would say there were two good and one false ticker. In fact this does not happen. I just tested the hypothesis. What happens depends on how the two wayward get there exaggerated offset: a) someone,something resets the date: result: ntp on both those servers crashes due to the panic_stop limit. So in this case the client has only one reference and continues using that. It is not flagged as a falsticker. That is normal. I gave an example. The server is set up with the localclock driver, and its gps puck goes down. It gaily keeps delivering the time which drifts off further and further. It goes nuts in other words. b) someone restarts ntp on the servers with the wrong date. Here the servers ntpd has no way of knowing that it has bad time and so continues serving normally. On the client. The running ntp sees immediately a huge offset and huge jitter. Tue Dec 9 13:15:04 CET 2014 remote refid st t when poll reach delay offset jitter == *192.168.1.15.GPS1. 1 u 320 64 3600.5490.040 0.037 +192.168.1.16.GPS2. 1 u 37 64 3770.6060.006 0.028 +192.168.1.17.GPS1. 1 u 309 64 3600.5760.027 0.025 Tue Dec 9 13:16:08 CET 2014 remote refid st t when poll reach delay offset jitter == 192.168.1.15.GPS1. 1 u 55 64 3410.5650.042 9660780 *192.168.1.16.GPS2. 1 u 37 64 3770.6060.006 0.024 192.168.1.17.GPS1. 1 u 42 64 3410.5790.041 9660773 After 5 mins the client is unable to resolve this and declares all clock falsetickers and then panics. I did not have ntpd in debug mode here, but it is reasonable to assume that it panics due to the selected clock being too far out and hitting the panic limit. Ie, clockhopping. It cannot decide. But while the server clock slowly drifts away it gives a terrible time. If you want microsecond accuracy, 128ms is a HUGE distance off, without triggering a complete crisis in the client. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Phil W Lee wrote: Martin Burnicki martin.burni...@meinberg.de considered Fri, 05 Dec 2014 14:15:31 +0100 the perfect time to write: You may run into problems if your WAN connection has asymmetric delays, and thus to 2 servers on the WAN *seem* to have the same offset which differs from the offset provided by the 2 servers on the local network. Martin In a multi-site business, I would set up two on each site, and have each site using the two local ones and two from different remote sites, which should guard against asymmetry on either one of the WAN links to other sites. If the connection from your local site to the internet has the asymmetry then *each* NTP server at a remote site has the same additional systematic offset, so if you use more than 2 they can overvote your local NTP servers. One of our customers had such a case, and I've explained this in more detail in another thread recently. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki wrote: If the connection from your local site to the internet has the asymmetry then *each* NTP server at a remote site has the same additional systematic offset, so if you use more than 2 they can overvote your local NTP servers. One of our customers had such a case, and I've explained this in more detail in another thread recently. I would have thought the WAN's additional delay, and increased jitter (as compared to the LAN) would have mattered more in the cluster algorithm, causing the internet servers to be tagged as outliers, if they were not close enough to make it into the cluster. Was the dispersion from the LAN servers higher than the internet servers, due to auto increasing poll times? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ 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 6:56 PM, William Unruh wrote: One source is fine, unless it either dies or goes nuts. Two are fine, unless on goes nuts. Define goes nuts. Two are not fine if they don't agree on the time, and in my experience the many of the admins that consider using only two servers are unable to get those two servers to agree on the time. Three are fine, as long as only one dies or goes nuts. Again, define goes nuts. You don't seem to like the term falseticker, so how do you define goes nuts? If one goes nuts or even goes offline, if the remaining two do not agree then it is like having no server at all. 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
In article m5jrm9$gje$1...@dont-email.me, David Woolley david@ex.djwhome.demon.invalid wrote: On 02/12/14 01:59, edstu...@gmail.com wrote: At the same time, we want drift less than 1 second. However, over Drift is a pure number. If you ever get a time error of more than 100ms, ntpd is in severe distress. On a computer with a blocked fan, thermal limits kick in and slow the world down. When this happens ntp cannot cope, and refuses to even try and keep any sync. Result, no sync what-so-ever. :-( A nicer failure mode would be to just sync time once every 1024 seconds. Not pretty, but, better than nothing. ___ 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-08, Brian Utterback brian.utterb...@oracle.com wrote: On 12/4/2014 6:56 PM, William Unruh wrote: One source is fine, unless it either dies or goes nuts. Two are fine, unless on goes nuts. Define goes nuts. Two are not fine if they don't agree on the time, and in my experience the many of the admins that consider using only two servers are unable to get those two servers to agree on the time. By go nuts I mean that it does not deliver an approximation to UTC within its jitter bounds. Eg, suddenly decides to deliver times a second late because of GPS/NMEA/PPS problems. Or the server had localclock set and all its sources died but it blithely kept delivering time to anyone who asks. Three are fine, as long as only one dies or goes nuts. Again, define goes nuts. You don't seem to like the term falseticker, so how do you define goes nuts? If one goes nuts or even goes offline, if the remaining two do not agree then it is like having no server at all. No, it is like having two, with one being out. falseticker is a term with a very specific internal definition. Thus a server whose time is right on UTC could be a falseticker, because the other two servers were both exactly 3 days out, with tiny jitter estimates. I would say then that you had two servers going nuts, and one good, even though ntpd would say there were two good and one falseticker. 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 Sun, Dec 7, 2014 at 4:38 AM, Rob nom...@example.com wrote: Your opinion about what's reasonable is just that. You have no more credibility than Bill. In fact use the pool when my two servers are down nom...@example.com has less. I did not write that. It's called paraphrasing but fair enough -- you literally wrote (not that long ago): On Tue, Nov 11, 2014 at 5:32 AM I don't like to load the pool with queries from 7 servers for a setup that only would need them to get the time when both my private servers are down. I could even use a conditional pool entry that it only starts using when *one or both* of the hardwired servers fail. [emphasis mine] It's hard to square this with your more recent assertions and insults. But I'm sure you'll find a way. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Paul tik-...@bodosom.net wrote: On Sun, Dec 7, 2014 at 4:38 AM, Rob nom...@example.com wrote: Your opinion about what's reasonable is just that. You have no more credibility than Bill. In fact use the pool when my two servers are down nom...@example.com has less. I did not write that. It's called paraphrasing but fair enough -- you literally wrote (not that long ago): On Tue, Nov 11, 2014 at 5:32 AM I don't like to load the pool with queries from 7 servers for a setup that only would need them to get the time when both my private servers are down. I could even use a conditional pool entry that it only starts using when *one or both* of the hardwired servers fail. [emphasis mine] It's hard to square this with your more recent assertions and insults. But I'm sure you'll find a way. That is, as I wrote, for a hobby project where I want to set the time on Raspberry Pi and Cubieboard out on the internet that requires it when booting. That pool reference is only used to get any time at all (so the Cubie won't run in 2010 or the Raspberry won't get the time it was last shutdown). The normal reference is our own GPS-locked stratum 1 servers. This is not what I would deploy inside a company, as the topic of this thread is. In a company I deploy two servers and arrange for suitable monitoring. Also there usually are no devices that have no RTC at all and still have a requirement to know the date/time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On Sun, Dec 7, 2014 at 9:47 AM, Rob nom...@example.com wrote: This is not what I would deploy inside a company, as the topic of this thread is. No, your topic of your sub-thread was that your servers like all professionally managed systems are only ever down for short, inconsequential periods of time unless deliberately so and so using more than two professionally managed servers should be unnecessary for finding true time in a clique with possibly missing servers. I don't think anyone here agrees with that sentiment though. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
William Unruh un...@invalid.ca wrote: On 2014-12-05, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) a. that will almost never happen b. that will be caught by the monitoring (e.g. nagios) and an alert will be sent and/or the system will be shut down automatically. Would it not be nicer is the alert is sent, but the system still keeps going and not shutting down? Shutting down a system seems like a pretty heavy price to pay for not having three instead of 2 sources. Not shutting down the client, shutting down the errant timeserver. Or only its NTP service. When you have two NTP servers and one goes nuts, just shut it down and send an alert to the operator so it can be fixed. The clients continue to sync to the other server without problem. That is so much easier than to setup 4 servers and configure them in all clients and let the complicated voting process happen in all clients. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. The monitoring for ntpd servers shipped by default with nagios has no problem detecting this. And when it does, what happens-- the company goes out of business? Noone cares? It also sends out for coffee and doughnuts for the IT team? It becomes clearer and clearer to me that you are an armchair theorist that has never been in touch with a professionally managed IT environment. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 06/12/2014 04:35, William Unruh wrote: [] If you do not care about the time, you can do anything you want. I had the idea that this was about people who do care that their systems have the correct time. How much correct is correct, though? Different application areas, different needs. -- 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
On 2014-12-06, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-12-05, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) a. that will almost never happen b. that will be caught by the monitoring (e.g. nagios) and an alert will be sent and/or the system will be shut down automatically. Would it not be nicer is the alert is sent, but the system still keeps going and not shutting down? Shutting down a system seems like a pretty heavy price to pay for not having three instead of 2 sources. Not shutting down the client, shutting down the errant timeserver. Or only its NTP service. When you have two NTP servers and one goes nuts, just shut it down and send an alert to the operator so it can be fixed. The clients continue to sync to the other server without problem. That is so much easier than to setup 4 servers and configure them in all clients and let the complicated voting process happen in all clients. It is both hard, and somewhat dangeous to allow clients to shut down servers. Imagine the opportunity for nefarious activity. And how in the world is it hard to set up 4 servers rather than 2, and configure them. And the voting is done by the program. How does that make anything harder. You are of course completely free to have however many servers you want. The 4 is not a regulation, it is a suggestion. It depends on how important having accurate time is to you and your company. If your proceedure works well for you, please continue to use it. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. The monitoring for ntpd servers shipped by default with nagios has no problem detecting this. And when it does, what happens-- the company goes out of business? Noone cares? It also sends out for coffee and doughnuts for the IT team? It becomes clearer and clearer to me that you are an armchair theorist that has never been in touch with a professionally managed IT environment. REsorting to attempted personal attacks does not much for your credibility. TO disentangle it for you, I was asking how important keeping time is for you. If it is not, then whatever you want to do is fine. If it is important (eg your company goes out of business) you had better think carefully about your setup. I do manage computers. I also know that everyone has many things on their plates and adding one more urgent issue is not helpful. Having three sources allows a bit of extra time to fix the problem. I have some machines with one source. Why? I donot really care if their time is accurate or not. If I do, I have more. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
William Unruh un...@invalid.ca wrote: On 2014-12-06, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-12-05, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) a. that will almost never happen b. that will be caught by the monitoring (e.g. nagios) and an alert will be sent and/or the system will be shut down automatically. Would it not be nicer is the alert is sent, but the system still keeps going and not shutting down? Shutting down a system seems like a pretty heavy price to pay for not having three instead of 2 sources. Not shutting down the client, shutting down the errant timeserver. Or only its NTP service. When you have two NTP servers and one goes nuts, just shut it down and send an alert to the operator so it can be fixed. The clients continue to sync to the other server without problem. That is so much easier than to setup 4 servers and configure them in all clients and let the complicated voting process happen in all clients. It is both hard, and somewhat dangeous to allow clients to shut down servers. Imagine the opportunity for nefarious activity. Not clients, management stations. Why are you being so dense? And how in the world is it hard to set up 4 servers rather than 2, and configure them. And the voting is done by the program. How does that make anything harder. The 4 is suggested as a minimum with more recommended. That is not reasonable for a company with 100 systems, as the poster brought forward. It becomes clearer and clearer to me that you are an armchair theorist that has never been in touch with a professionally managed IT environment. REsorting to attempted personal attacks does not much for your credibility. You must be referring to yourself? See above, yet another proof that you have never seen a managed network. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On Sat, Dec 6, 2014 at 12:52 PM, Rob nom...@example.com wrote: Not clients, management stations. As opposed to one server dies and the Nagios server has bad time so it shuts down the remaining NTPd. The world is full of crazy things. The 4 is suggested as a minimum with more recommended. That is not reasonable for a company with 100 systems, as the poster brought forward. Actually I'm pretty sure the OP was confused and thought the recommendation was for 8 servers. 4 S1 and 4 S2. Your opinion about what's reasonable is just that. You have no more credibility than Bill. In fact use the pool when my two servers are down nom...@example.com has less. ___ 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 20:03, Rob wrote: [] 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. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, and that's what we tried to set up. These were not time critical systems, though. The on-site servers would at least have pool as a backup. This was before the days of cheap GPS/PPS, though. -- 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 20:03, Rob wrote: [] 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. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. Just two servers is more than adequate for the typical network where of course the servers are being monitored and alerts are being handled in a timely fashion. ___ 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 wrote: On 04/12/2014 20:03, Rob wrote: [] 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. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, and that's what we tried to set up. You may run into problems if your WAN connection has asymmetric delays, and thus to 2 servers on the WAN *seem* to have the same offset which differs from the offset provided by the 2 servers on the local network. Martin ___ 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-05, Rob nom...@example.com wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 04/12/2014 20:03, Rob wrote: [] 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. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) then ntpd may well start jumping between the two, making the time on the client machines very unreliable. Use 3 making sure that they are independent (Ie one of them does not get its time from the other.) This is not too many safeguards. It simply protects against one going bad. Note that they can go bad. Say one of the servers goes down for some reason. That is fine, the other will handle things. But when the first comes up again, it has trouble with its gps pps (using an older Garmin 18x with older firmware where the nmea time could be a second out). Suddenly one of the servers gives a time one second out from the other. The poor client has no idea whichis right, and hops between them. Because of the 128ms rule, it jumps the time -- again and again. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. Just two servers is more than adequate for the typical network where of course the servers are being monitored and alerts are being handled in a timely fashion. It depends on how important time is. If you do not care if the time is days out, then do whatever you want. If you do care, use reasonable safeguards. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
William Unruh un...@invalid.ca wrote: For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) a. that will almost never happen b. that will be caught by the monitoring (e.g. nagios) and an alert will be sent and/or the system will be shut down automatically. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. The monitoring for ntpd servers shipped by default with nagios has no problem detecting this. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 05/12/2014 13:15, Martin Burnicki wrote: [] You may run into problems if your WAN connection has asymmetric delays, and thus to 2 servers on the WAN *seem* to have the same offset which differs from the offset provided by the 2 servers on the local network. Martin Yes, I can see what you mean, but it was never a problem in practice. Likely these would be just for general office PCs, where the nearest minute would be good enough, let alone the nearest second! If something better was needed more care would be taken. -- 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
On 2014-12-05, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) a. that will almost never happen b. that will be caught by the monitoring (e.g. nagios) and an alert will be sent and/or the system will be shut down automatically. Would it not be nicer is the alert is sent, but the system still keeps going and not shutting down? Shutting down a system seems like a pretty heavy price to pay for not having three instead of 2 sources. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. The monitoring for ntpd servers shipped by default with nagios has no problem detecting this. And when it does, what happens-- the company goes out of business? Noone cares? It also sends out for coffee and doughnuts for the IT team? ___ 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-05, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 05/12/2014 13:15, Martin Burnicki wrote: [] You may run into problems if your WAN connection has asymmetric delays, and thus to 2 servers on the WAN *seem* to have the same offset which differs from the offset provided by the 2 servers on the local network. Martin Yes, I can see what you mean, but it was never a problem in practice. Likely these would be just for general office PCs, where the nearest minute would be good enough, let alone the nearest second! If something better was needed more care would be taken. If you do not care about the time, you can do anything you want. I had the idea that this was about people who do care that their systems have the correct time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
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
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] 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] Number of Stratum 1 Stratum 2 Peers
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. 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
Brian Utterback wrote:
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.
While not disagreeing; Several things can be done to minimize
the two NTP servers don't agree issue.
If as Rob pointed out they both get GPS PPS,
and they are peered with each other,
they won't get far apart except when one has issues.
In many cases the TOS mindist would already be increased
from 1ms due to NEMA vs PPS skew from the GPS.
e.g.
# in ntp.conf for ALL Primary Servers
# Start ntpd with -g, the -g will prevent a panic stop if the time needs to be
stepped when started
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict ::1
restrict -4 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict 224.0.1.1 mask 255.255.255.255 nomodify
restrict source nomodify
tos cohort 1 orphan 11 mindist 0.4
keys /etc/ntp.keys # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY ,
...
trustedkey 123 321
broadcastclient
multicastclient 224.0.1.1 key 123 preempt
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
# Corp LAN S1/S2(s)
peer a.ntp.lan.corp.example.com key 321 iburst preempt minpoll 4 # 16sec
peer b.ntp.lan.corp.example.com key 321 iburst preempt minpoll 4 # 16sec
pool pool.ntp.remote.corp.example.com key 321 iburst preempt minpoll 7 # 2min
pool ntp.isp.example.net iburst preempt minpoll 7 # 2min
pool ntp.osvendor.example.net iburst preempt minpoll 8 # 4min
pool ntp.regional.timebase.org iburst preempt minpoll 8 # 4min
pool pool.ntp.org preempt minpoll 8 # 4min
... GPS Config prefer minpoll 4 maxpoll 4 # 16sec prefer only the GPS
If the Clients also had an increased TOS mindist set,
that would increase the clients likelihood of accepting
both servers (when the servers don't have issues).
In addition, if manycast orphan is also configured
on the servers / clients, they will still follow
each other around, instead of drifting apart
if the primary NTP servers have issues;
{which actually makes it more than 2 servers also}.
e.g.
# in ntp.conf for ALL Clients
# Start ntpd with -g, the -g will prevent a panic stop if the time needs to be
stepped when started
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict ::1
restrict -4 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict 224.0.1.1 mask 255.255.255.255 nomodify
restrict source nomodify
tos cohort 1 orphan 11 mindist 0.4
keys /etc/ntp.keys # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY ,
...
trustedkey 123 321
broadcastclient
multicastclient 224.0.1.1 key 123 preempt
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
# Corp LAN S1/S2(s)
server a.ntp.lan.corp.example.com key 321 iburst preempt prefer minpoll 6 # 1min
server b.ntp.lan.corp.example.com key 321 iburst preempt prefer minpoll 6 # 1min
pool pool.ntp.lan.corp.example.com key 321 iburst preempt prefer minpoll 6 #
1min
pool pool.ntp.remote.corp.example.com key 321 iburst preempt minpoll 7 # 2min
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
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/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. ___ 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-03, Brian Utterback brian.utterb...@oracle.com 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. One or three. Three allows two to outvote one rogue time source. One has no idea what the time is except what that one says. Four will often allow 2 to outvote each of two rogue sources, if those two rogues are not going rogue in exactly the same way. (No matter how many GPS time sources you have, they will all go rogue in the same say if the GPS sattelite system goes crazy for example. However if a couple of the receivers develop some harware fault they will probably deliver different times from each other) Five will allow three to outvote two rogue, even if the two collude with each other. etc. So you decide on the level of redundancy you want, and take your choice. 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-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. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 02/12/14 01:59, edstu...@gmail.com wrote: At the same time, we want drift less than 1 second. However, over Drift is a pure number. If you ever get a time error of more than 100ms, ntpd is in severe distress. I think peering is over-rated, and is often associated with time islands (all the answers so far assume you are not running time island, but really are synchronised to sources of true time). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
edstu...@gmail.com edstu...@gmail.com wrote: Hi, I am looking to implement an NTP network and I was reading http://support.ntp.org/bin/view/Support/DesigningYourNTPNetwork. It suggests 4 stratum 1 peers and 4 stratum 2 peers well. I understand, that the document recommends this so that if one of the servers in a stratum dies, there will still be 3 servers from which a majority clique should be found. The problem is that we will be starting out with simply 100 nodes at most. At the same time, we want drift less than 1 second. However, over the next 7 years or so, we should hit ~ 1000 NTP clients. Is the document's recommendation overkill for my situation? The number of servers is (at that scale) not related to the number of clients, i.e. one server can easily serve 1000 clients. If you want more than one server, and how many you want, only depends on the reliability of your server(s) and the reliability you want to get on your clients. A single server works well to keep clients within 1 second, but when it fails of course the clients will start to drift while you are fixing it. The rate at which they drift depends on their operating system, the quality of the hardware, and the stability of the ambient temperature. So depending on your requirements (how hard that 1 second limit is) and the quality of your network management (how quickly can you bring a failed server back up) you may need 2 or more servers to guarantee your specs. 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. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Number of Stratum 1 Stratum 2 Peers
Hi, I am looking to implement an NTP network and I was reading http://support.ntp.org/bin/view/Support/DesigningYourNTPNetwork. It suggests 4 stratum 1 peers and 4 stratum 2 peers well. I understand, that the document recommends this so that if one of the servers in a stratum dies, there will still be 3 servers from which a majority clique should be found. The problem is that we will be starting out with simply 100 nodes at most. At the same time, we want drift less than 1 second. However, over the next 7 years or so, we should hit ~ 1000 NTP clients. Is the document's recommendation overkill for my situation? Thanks, Ed Stuart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
edstu...@gmail.com writes: Hi, I am looking to implement an NTP network and I was reading http://support.ntp .org/bin/view/Support/DesigningYourNTPNetwork. It suggests 4 stratum 1 peers and 4 stratum 2 peers well. I understand, that the document recommends this so that if one of the servers in a stratum dies, there will still be 3 servers from which a majority clique should be found. The problem is that we will be starting out with simply 100 nodes at most. At the same time, we want drift less than 1 second. However, over the next 7 years or so, we should hit ~ 1000 NTP clients. Is the document's recommendation overkill for my situation? It depends. What (and who) will it cost if this design/deployment goes wrong? What will it cost if your machines drift away more than a second? Do you need to keep good time even if no external timesources are available? If so, for how long? How well-synch'd do your clients need to be with each other? You can get a decent S1 source for not a lot of money. It won't keep decent time for long if no external sync source is available. You can do much better if you start spending more (maybe US$3,000 or so). You can do better than that if you spend even more. In 7 years' time it might be much better to be ready for PTP as well. You have a lot of choices. What you should buy really depends on what your actual requirements are (and those requirements might cover a fairly wide area). Please let me know if I can help more. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Le 2 déc. 2014 à 02:59, edstu...@gmail.com a écrit : Hi, I am looking to implement an NTP network and I was reading http://support.ntp.org/bin/view/Support/DesigningYourNTPNetwork. It suggests 4 stratum 1 peers and 4 stratum 2 peers well. I understand, that the document recommends this so that if one of the servers in a stratum dies, there will still be 3 servers from which a majority clique should be found. The problem is that we will be starting out with simply 100 nodes at most. At the same time, we want drift less than 1 second. However, over the next 7 years or so, we should hit ~ 1000 NTP clients. Is the document's recommendation overkill for my situation? The recommendation is really a minimum for whatever the number of clients that you are servicing, 1 or 1000. Fortunately, you don’t need to have all the upstream servers in your shop, unless you don’t allow connections to the internet. If you do, then with the latest versions on NTP you can use the pool for a minimal config in your top level servers, and serve the other clients locally from them. If you have a good view of the sky, then you could use very cheap GPS sync’d stratum 1 servers in your top level. 1 second is not a difficult constraint. Thanks, Ed Stuart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
