[questions] New Yorker article on NTP
https://www.newyorker.com/tech/annals-of-technology/the-thorny-problem-of-keeping-the-internets-time -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
[questions] S200/S250/S300/S350 SyncServers will experience GPS Rollover on 2022-09-18
FYI From: Field Service Bulletin (FSB) No: 098-50620-106 Rev. A [Microchip/Microsemi/Symmetricom] "S200/S250/S300/S350 SyncServers manufactured in 2007 and later will experience a date change on September 18, 2022 due to an internal GPS week number rollover event specific to the Furuno GPS receiver chip used in these models. This date change will affect NTP service." -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
[questions] Archive of ntp.org mailing lists
Are the ntp.org mailing lists archived? They used to be available on http://lists.ntp.org
Re: [ntp:questions] Local Time NTP Server
Facebook (time.facebook.com) and Google (time.google.com) NTP services use anycast ( https://en.wikipedia.org/wiki/Anycast ) and have a number of NTP servers in unpublished locations. If all goes well NTP requests reach a nearby server. There is no guarantee. Microsoft (time.windows.com) NTP servers use unicast. The IP addresses and locations of these servers have varied over time and are unpublished, as far as I know. The NTP pool ( https://www.ntppool.org/en/ ) may help find a nearby NTP server, but the locations are not guaranteed. IP pings (ICMP echo request/response) travel from the client to the terrestrial NTP server, not to the satellites. On Mon, Aug 24, 2020 at 6:39 AM Jakob Bohm wrote: > On 2020-08-24 12:51, Beth Connell wrote: > > Hi, > > I'm struggling to find any information on where the free NTP servers are > geographically based. In particular, I'm wondering where Facebook, Google, > Microsoft, etc are based within the UK. Just for curiousity, I'm wondering > how this affects any interference to my location. > > > > Thanks > > > > All NTP time is GMT (now named UTC, after HM government dropped the > ball). The only geographic factor is the "ping time" to the time > server, the servers that are the most distant (longest ping) are the > GPS and Galileo satellites, that are hundreds or thousands of km from > the receiver, and use their own (non-NTP) protocols to correct for the > delay. > > Another problem is if the NTP server is one of those that deliberately > return slightly wrong time before and after each leap second to "smooth > out" the leap, some of the companies you mention reportedly do that. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > ___ > 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] ntpd - gpsd communication
Gary, Sounds sort of plausible. However if the GPS doesn't have the almanac, how can it get a fix?If this is a known issue, shouldn't the GPS delay sending validity="A" or otherwise signal that the UTC offset may be incorrect? This should be reproducible, correct? What kind of reset will cause the GPS to lose the almanac information? Many Rpi boards have batteries or supercaps for power backup. khronos.mikieboy.net is a Rpi+Uputronics board Steve On Mon, Jun 8, 2020 at 5:25 PM Gary E. Miller wrote: > Yo Steven! > > On Mon, 8 Jun 2020 17:06:55 -0500 > Steven Sommars wrote: > > > The off by N-second errors are often seen soon after NTP server > > initialization. > > This is common to all GPS based NTP servers. It is distinct from > long lasting off-by one errors that one version of gpsd could fall > victimm to. > > When a GPS starts up, it often uses the value for the current leap > second stored in the firmware. By "leap second" I mean the correction > from GPS tim to UTC time which is always in integer seconds. > > This stored leap second is often off by one or two seconds, or more, > for a while. > > After receiving the Almanac, which can take up to 25 minutes on some > older GPS, the current leap second offset is known. But now ntpd is > set in its ways, and will take a while to slew to the correct time. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can't measure it, you can't improve it." - Lord Kelvin > ___ > 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] ntpd - gpsd communication
I monitor many NTP servers and have observed off-by-N second errors (N often 1, 2, 3) for years. Some of these errors are understood: fuzzing errors in ntpd, late NMEA arrival times. But many of these errors have unknown causes. These errors can recur on a given server with the same offset. On May 22 I noticed a system running ntpsec + GPSD ( khronos.mikieboy.net,) was in error by two seconds. The same system was also off by two seconds on January 15. I asked about this on the ntpsec mailing list, which happens to include several GPSD folks. Their answer was that a GPSD error caused the problem, but was fixed in GPSD 2.0 No bug description seems to exist, so I'm uncertain whether the errors I saw were related. The off by N-second errors are often seen soon after NTP server initialization. I lack detailed configuration information for many of the affected systems, unfortunately. On Mon, Jun 8, 2020 at 5:02 AM Miroslav Lichvar wrote: > On 2020-06-08, a...@avtodoria.ru wrote: > > понедельник, 8 июня 2020 г., 10:52:36 UTC+3 пользователь Miroslav > > Lichvar написал: > >> If you need something to report a large offset to ntpd via SHM, you > >> could try this program for testing leap seconds: > >> > >> https://github.com/mlichvar/leapshm > > > Thank you ver much. Please can you explain the params program uses. > > Second can be path to unix socket or something else starting not with > > "/" to use SHM. What about third param ? > > It's the number of seconds before the hardcoded leap second time (1 Jul > 2015 00:00:00 UTC) where the time fed by the program should start. E.g. > if it was 600, it would start 10 minutes before the midnight of the leap > second. You would probably want to start with a larger number (if you > don't want to test a leap second) and also change the LEAP_TIME constant > to a current date. > > -- > Miroslav Lichvar > > ___ > 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] Garmin LVC 18x jitter problem
David Taylor kindly added one of my old graphs to his Garmin LVC18 pages: https://www.satsignal.eu/ntp/Garmin-GSP18x-LVC-firmware-issue.htm#3.60 The graph is from an email exchange with Garmin ~seven years ago and shows timing of the NMEA version 3.60 firmware. This version suffered from drift and high jitter, see below. The change log mentions: Changes made from version 3.60 to 3.70: Improved NMEA output timing stability. Version 3.64 (unreleased) had an offset of around 600 msec, with no significant drift. ntpd was happy with 3.70, I haven't looked at later firmware version. (Garmin is up to version 4.20 now.) The graph shown in http://www.moria.de/~michael/tmp/offset.svg also shows high drift & jitter, though not as severe as the old release I used. Some of the later firmware versions may have NMEA timings that are poor fits for NTP usage. On Fri, Jul 12, 2019 at 9:31 AM Michael Haardt wrote: > Hello David, > > I trust the clock, because with constant temperature crystals perform > pretty good. The clock is disciplined with PPS, but no adjustments > happened during the measurement, so it runs with a constant frequency > offset. It took a few days to reach that state. > > My point is that NMEA on this device does not jitter with a gauss > distribution or similar, but in a way that causes the reasonable jitter > calculation to give too low values. > > The jitter diagram shows why 0.1 as minimum distance suffices. > The problem is, that this is only a workaround, as it effects the root > dispersion. What I need is to bypass the NMEA jitter calculation only, > or give a minimal value for that, to prevent it becoming a false ticker > when the actual jitter is larger than the estimated jitter. > > In the diagrams that happens if the estimated jitter does not cover > zero, because zero is the PPS/crystal clock with 4 us jitter (both > estimated and actual). > > GPS reception was fine with good average SNR and a reasonable of used > and visible satellites. TDOP was fine. > > I had this behavior before the upgrade from firmware 4.00 to 4.20, > which is recommended due to the GPS week rollover. I did not have it > when the GPS reception was worse and I had a lower average SNR and > an overall higher NMEA jitter and worse TDOP. > > Michael > > ___ > 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] Some servers returning the wrong time
206.108.0.131 >From what I saw the problem started ~2019-07-03 04:05:03 UTC and ended about 2019-07-03 08:45:00 UTC The time offset was about 123335 seconds at the onset and gradually decreased. Reference ID was PTP0 Root dispersion was about 3 seconds at onset, but never reflected the actual error. Steve Sommars On Wed, Jul 3, 2019 at 8:49 AM David Taylor wrote: > On 03/07/2019 10:52, Roger wrote: > > On Wed, 3 Jul 2019 00:56:08 -0700 (PDT), rickylje...@gmail.com > > wrote: > > > >> Server 206.108.0.131 which is part of 0.pool.ntp.org is returning a > date and time that is off around 11 hours. Trying to find any details of > why this would be happening. > > > > The change was very sudden > > > > https://www.pool.ntp.org/scores/206.108.0.131 > > Yes! It makes you wonder how many servers they have, doesn't it? Mike > Cook also confirmed that it is now OK - thanks. > > -- > Cheers, > David > Web: http://www.satsignal.eu > > ___ > 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] empty refid in ntpq output
See NTP bug 3484, http://bugs.ntp.org/show_bug.cgi?id=3484,
"ntpq response from ntpd is incorrect when REFID is null"
On Fri, May 3, 2019 at 4:21 AM wrote:
> I have seen this myself. IIRC, when the input for refid ID is exactly
> \0\0\0\0 then it is displayed as "blank" in ntpq output. And maybe only if
> it is stratum 1? Anything else gets at least a . char in the string
> conversion routine. And if it is s2 or higher, I think it is parsed
> differently with an addr string for 4 and a hash print for 6. NTPd is
> fine, this is only the string formatting code for ntpq where this is
> introduced. You might be able to count fields and stuff, or used fixed
> length parse, or you could change that 1 piece of code around line 1707 in
> ntpq-subs.c
> } else if (!strcmp("refid", name)) {
> if ( (pvl == peervarlist)
> && (drefid == REFID_IPV4)) {
> have_da_rid = TRUE;
> drlen = strlen(value);
> if (0 == drlen) {
> dstadr_refid = "";
> } else if (drlen <= 4) {
> ZERO(u32);
> memcpy(, value, drlen);
> dstadr_refid = refid_str(u32, 1);
>
> Greg Dowd
> Principal Engineering Technologist, FTD
> Microsemi
> 3870 N. First St. | San Jose | CA 95134 | USA
> Office: 408.964.7643
> Email: greg.d...@microchip.com
> Company Website: www.microsemi.com
>
>
>
> -Original Message-
> From: questions [mailto:questions-bounces+greg.dowd=
> microsemi@lists.ntp.org] On Behalf Of Daniel Nelson
> Sent: Tuesday, April 30, 2019 10:43 AM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] empty refid in ntpq output
>
> External E-Mail
>
>
> I'm working on a project that attempts to parse the output of `ntpq -p`,
> and have heard a report that sometimes the refid is empty. Here is the
> output I'm seeing, the indention was mangled by the logging system, so I've
> attempted to realign things below:
>
> remoterefid st t when poll reach delay offset jitter
>
> ==
> 0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
> +198.1.1.1 16 u 1048 1024 376 15.384 -0.538 0.943
>
> My question is, what does an empty refid indicate and are there any tips
> for machine parsing the output correctly given that the lines may have a
> differing number of columns.
> ___
> 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
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Issues trying to sync to NIST public servers
Between Jan 30 00:00:00 and Jan 31 21:26:29 UTC 2019 all public NIST servers had good reachability from my primary monitoring client (suburban Chicago). There could have been problems between CenturyLink, provider of the NIST NTP Internet, and your ISP. When my clients experience NTP connectivity problems I capture all ICMP traffic using tcpdump or Wireshark. Later I'll examine the packet capture using the Wireshark display filter: icmp and ntp This may expose a problem such as administrative blockage. Often I've found that the problem lies with my ISP or local IT group, where someone decided to block external NTP traffic. For testing purposes you might try syncing to several non-NIST servers. On Thu, Jan 31, 2019 at 2:22 PM Jason Rabel wrote: > Have you checked for possible packet loss somewhere between you & the > NIST servers? That's the usual problem. > > Are you querying at an excessive rate? That's another possibility. > ___ > 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] Legitimate Source Ports for NTP traffic?
I looked at a sample of NTP queries sent to a busy European server. Many queries had precision of -6, few were -7. UDP source ports ranged from 1 to 65535. The most common UDP source ports were 123, 1026, 1027, 1028, 1025. A NIST paper, https://tf.nist.gov/general/pdf/2818.pdf , may be of interest. The UDP source port distribution shown in figure 5a is similar to my observations. On Wed, Nov 28, 2018 at 1:53 AM Miroslav Lichvar wrote: > On Tue, Nov 20, 2018 at 11:19:24AM -0600, Jason Rabel wrote: > > In response to my own question I looked a little deeper into the odd > > traffic using tcpdump. Best I can tell they are indeed properly > > formatted NTP requests, the curious bit is seeing most of these > > requests having a precision of -6 or -7. While I know some older MS OS > > set their internal time update to around that, they also use the > > microsoft time servers by default. > > Precision of -6 seems to be common. It's used by ntpdate for example. > Not sure about -7. > > I suspect the number one reason for getting requests from privileged > ports different than 123 is NAT. If there are two NTP clients behind > NAT using port 123, one of them will have to get a different port. > > -- > Miroslav Lichvar > ___ > 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] Conflicting information on packet field types
On the poll field. Earlier RFCs are obsoleted by RFC5905, plus there are some terminology changes/errors when comparing documents. Even staying within RFC5905 terminology can be inconsistent: it contains a mixture of "on-the-wire" data field definitions, algorithms, and code. My interpretation: Looking at an "on-the-wire" NTP packet the "poll" field should be interpreted as signed: Poll: 8-bit signed integer representing the maximum interval between successive messages, in log2 seconds. Suggested default limits for minimum and maximum poll intervals are 6 and 10, respectively. A poll value of 6 corresponds to a "poll interval" of 64 seconds (log2(64) is 6); poll interval is unsigned and can be larger than 8 bits. I don't believe the reference NTP software (ntp.org) supports negative values of poll, so signed versus unsigned issues don't arise. Chrony, another NTP implementation, does support negative values of poll. On Thu, Nov 1, 2018 at 3:40 AM Jason Rabel wrote: > I was mainly reading RFC 5905 since it's the latest, but it does make > some references back to the older RFC 4330 (SNTP). I believe it is > that document (and others) that seem to flip-flop on what is signed / > unsigned. i.e. 5905 says poll interval is signed, 4330 says poll > interval is unsigned. > > I dug around in the NTP source (4.2.8p12), specifically in the > include/ntp.h file there seems to be the various structures... > > In the peer struct, which the comment says, "The peer structure. Holds > state information relating to the guys we are peering with. Most of > this stuff is from section 3.2 of the spec." > > u_char ppoll; /* remote poll interval */ > double rootdelay; /* roundtrip delay to primary source */ > double rootdisp; /* dispersion to primary source */ > > But further down in the pkt struct, which the comment says, "NTP packet > format." > > u_char ppoll; /* peer poll interval */ > u_fp rootdelay; /* roundtrip delay to primary source */ > u_fp rootdisp; /* dispersion to primary source*/ > > Poll interval is unsigned in both instances, even though the RFC says > it should (could) be signed? Again, nothing in the standard NTP > distribution would lead me to believe any negative number would ever > be sent, but with other time packages out there, who knows? TBH, I'm > not really sure what purpose sending the 'poll interval' really serves > in a client/server scenario (probably none). Maybe in a peer setup it > might hint something? I'm curious how NTP handles it, just not curious > enough to go digging through thousands of lines of code, lol. > > Jumping now from Root Dispersion (which we seem to agree on is > unsigned) to Root Delay RFC 5905 is pretty vague on "Root Delay", > only saying it is "NTP Short Format", and like you quoted below it > *should* be unsigned. > > However, RFC 4330 goes a little more in-depth saying, "This is a > 32-bit signed fixed-point number indicating the total roundtrip delay > to the primary reference source, in seconds with the fraction point > between bits 15 and 16. Note that this variable can take on both > positive and negative values, depending on the relative time and > frequency offsets. This field is significant only in server messages, > where the values range from negative values of a few milliseconds to > positive values of several hundred milliseconds." > > But to contradict even that, later in RFC 4330 there is a blurb about, > "A truly paranoid client can check that the Root Delay and Root > Dispersion fields are each greater than or equal to 0 and less than > infinity, where infinity is currently a cozy number like one second." > > I found this blurb about the delay computation, "In some scenarios > where the initial frequency offset of the client is relatively large > and the actual propagation time small, it is possible for the delay > computation to become negative. For instance, if the frequency > difference is 100 ppm and the interval T4-T1 is 64 s, the apparent > delay is -6.4 ms. Since negative values are misleading in subsequent > computations, the value of delta should be clamped not less than > s.rho, where s.rho is the system precision described in Section 11.1, > expressed in seconds." > > I know this is all a bunch of 'what if' scenarios that probably will > never happen... Especially with the packet NTP sends out apparently is > unsigned for root delay. But again my thoughts are about other time > programs out there. I'm going to take a wild guess and say that (under > normal circumstances) if NTP (or any time program) is calculating a > negative delay (and likely a huge time offset), it's probably also > considering itself unsynced and won't send out time to any clients > that request it until things normalize. > > Jason > > > > The RFC 5905 (NTPv4) should be the authoritative source here. For the > > poll field it has: > > > > 8-bit signed integer representing the maximum interval between > > successive messages, in log2 seconds. >
Re: [ntp:questions] does this make sense?
Search for: CDMA shutdown CDMA NTP servers lack an automated leap second mechanism, as far as I can tell. On Thu, Apr 5, 2018 at 7:25 AM, Thomas Laus wrote: > On 2018-04-04, Maria Iano wrote: > > I'm purchasing ntp appliances to put into three datacenters. Does it > make sense to purchase two that use GPS and two that use WWVB, and > configure them as peers? > The USA Bureau of Time Standards has a link for timing receiver > vendors: > https://www.nist.gov/pml/time-and-frequency-division/time- > services/manufacturers-time-and-frequency-receivers > > There are a few manufacturers of CDMA systems that receive the timing > signals from the USA cellphone systems. They have a high degree of > accuracy and are a better choice than WWVB in most cases. > > Tom > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > > ___ > 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] what is refid in ntpq -pn
RFC5905 Reference ID (refid) ... If using the IPv4 address family, the identifier is the four- octet IPv4 address. If using the IPv6 address family, it is the first four octets of the MD5 hash of the IPv6 address. Has this been changed? In any case the Refid field size, 4 bytes, is too small to contain an IPv6 address. On Sat, May 6, 2017 at 4:39 PM, David Woolley < david@ex.djwhome.demon.invalid> wrote: > On 06/05/17 22:24, Hans Mayer wrote: > > >> I always thought "refid" for command "ntpq -pn" shows the next upstream >> server for the remote server listed below "remote". But now I have my >> concerns. >> >> > Officially, it is an opaque 32 bit identifier for the selected upstream > peer of the peer. You are not supposed to assume it has any more meaning, > even though, on pure IPv4 systems, it is derived in the way you describe. > > Note that the selected peer is not the only source of time; it is just the > one used for the quality parameters. > > > ___ > 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] Shared PPS source/Multiple PPS sources
https://groups.google.com/forum/#!topic/comp.protocols.time.ntp/P7qY3gBvHTM On Friday, April 25, 2014 1:09:45 AM UTC-5, Evandro Menezes wrote: The NTP ST1 server at the University of Houston has been offline for about a month. Any information about its demise? Yet another victim of a DOS attack? Alan Pfeiffer-Traum from UH was kind enough to explain: tick.uh.edu has been offline to the internet since mid-February. About that time we saw a sudden sharp increase in traffic from many sources. The high level of traffic overwhelmed tick and made it unusable. We hope that this event will eventually fade away so we can allow access to the service again. On Fri, Feb 6, 2015 at 5:37 PM, walter.preunin...@gmail.com wrote: On Friday, February 6, 2015 at 3:38:14 PM UTC-6, William Unruh wrote: Is there any reason why I could not share the PPS output of say, my u-blox 7 GPS module on multiple computers? Would it be good or bad to peer these 2 systems with each other? By share you mean run the PPS output to each of the computers? The main thing you would need to do is make sure that the gps is able to handle the current load, and that the signals had the appropriate level at each of the computers. Yes, exactly what I mean. On the opposite end of the spectrum, would it be reasonable to have a PPS output from said module on a computer, with a second PPS (from another GPS module) on that same computer? Sure. you need to have two differnt interrupt lines available (GPIO, serial ports, parallel ports) Awesome! The Chronodot/DS323X chips have 1 Hz sqaure wave output and they have +/- 2ppm. It seems that the ATOM clock driver could be used, but would it be better to write a driver specifically for this chip? 2PPM is not that great. That is one second out per 6 day. A minute out per year. What is that chip. I was thinking more as a worst case, offline for hours situation. Perhaps a new driver could 'sync' the Dallas Semiconductor/Maxim DS3231 OXCO Real Time Chip periodically. What is the ppm error of the RTC in a pc or my MacBook? Does someone know the admin of tick.uh.edu? I am not getting a response from them or the server. What reponse do you want? Why should they respond to you? I would like to use tick.uh.edu as one of my 'local' Stratum 1's. I have 1 from Oklahoma, but I'm in Texas... and the server is either down, or the name has changed on Pulic Strat 1's list hasnt been updated. ___ 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] Quality vs. Quantity
Background: NIST operates a DNS load balancer for NTP: time.nist.gov See http://tf.nist.gov/tf-cgi/servers.cgi USNO operates a server load balancer for NTP. See for example: http://tycho.usno.navy.mil/ptti/2010papers/paper9.pdf On Sun, Mar 23, 2014 at 2:43 AM, Terje Mathisen terje.mathi...@tmsw.nowrote: Daniel Quick wrote: While this should be obvious, I always have to ask how and why... While considering that the number of requests to our time servers will grow over time since the client decides which server to sync with. Do we want a Netspeed setting that assists with taking the load off some of the more heavily, higher-speed servers? or do we want to keep a setting where we serve fewer clients with the highest resolution of time given specific setup and let the client queries grow from there? I suppose this also takes into the smart dns load-balancing that goes on in the background. You really do NOT want load-balancing of ntp servers!!! Put them all in a pool and let the clients connect to all, distributing the load automatically. Terje Any input would be appreciated. Thanks, Daniel -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ 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] NIST vs. pool.ntp.org ?
A report on UTC(NIST) - UTC(USNO) can be found at http://tf.boulder.nist.gov/general/pdf/2663.pdf On Thu, Mar 28, 2013 at 7:22 AM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 03/27/2013 10:45 PM, David Woolley wrote: Robert Scott wrote: I am confused about the proper usage of pool.ntp.org and NIST. pool.ntp.org seems to be a collection of private sector time servers offered for all to use, but with registration expected for regular The pool system has no provision for enforcing registration. It wouldn't make sense to hand out a random server address if most of them then refused to serve you because you hadn't registered. users. And NIST has a government run set of time servers. Neither group (NIST or pool.ntp.org) seems to include or referece the other. I would hope all the pool servers ultimately reference their national equivalent of NIST and therefore what becomes, after the fact, UTC. I think you will find that Navstar (GPS) and WWV times are traceable to NIST. Yes and no. GPS is traceable to USNO. USNO and NIST have traceability between each other within the BIPM framework. MSF times are traceable to NPL. NPL is traceable to both USNO and NIST within the BIPM framework. Are they in competition? Who normally uses the NIST servers and who uses pool.ntp.org? The open NIST servers are heavily overloaded, so probably don't serve the highest quality time, but they are likely to be around for a long time. I would setup a local server under your control. It will help both from debugging and noise perspective. Cheers, Magnus __**_ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/**questionshttp://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New years glitch?
For the past 6 months a number of NTP servers have been reporting leap=01. When 2013 began I saw a 1 second jump from NTP servers at University of Minnesota, Apple, and a few other sites. To my knowledge the underlying issue in ntpd has not been addressed. On Tue, Jan 1, 2013 at 12:29 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 01/01/2013 06:12, s.schaefer.at@gmail.com wrote: I'm using [0123].ntp.pool.org with my two internet accessing NTP servers. I missed the ball drop on new years because I was trying to figure out why Nagios was complaining about my NTP servers dropping the two internet accessing daemons and prefering each other, resulting in higher and higher strata numbers. My first reaction was to restart all these non-internet accessing daemons, assuming they'd reset to the two internet-accessing daemons, then honor the low stratum numbers and be sane. Then I noticed my two internet accessing daemons were reporting that they were within milliseconds of their internet peers (multiple cnames sending them to a non-overlapping set of real servers), BUT almost exactly one second different from each other. I first noticed this at a little after midnight, but it went away by about 00:40 - I don't have status logs to say exactly when. Huh? My own plots show no glitch: http://www.satsignal.eu/mrtg/**performance_ntp.phphttp://www.satsignal.eu/mrtg/performance_ntp.php Was something sending a Leap Second flag? You could check with my program here: http://www.satsignal.eu/**software/net.htm#NTPLeapTracehttp://www.satsignal.eu/software/net.htm#NTPLeapTrace Recent versions of NTP should ignore a single leap-second flag, earlier versions may set a leap second even if only one of the upstream servers is indicating thus. Happy New Year and thanks to all those who have helped me in the past! -- Cheers, David Web: http://www.satsignal.eu __**_ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/**questionshttp://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] WARNING: someone's faking a leap second tonight
One root cause involves a group of stratum one's peering each other. A leap indicator can continue to circulate until the peering changes, or the entire group is simultaneously reinitialized. This affects multiple commercial server brands. Is this a problem with some/all versions of ntpd? On Thu, Aug 2, 2012 at 4:04 AM, Martin Burnicki martin.burni...@meinberg.de wrote: E-Mail Sent to this address will be added to the BlackLists wrote: Martin Burnicki wrote: It turned out this happened with some older versions of ntpd when the customers had installed e.g. 3 or 4 servers for redundancy, and each NTP server had the other ones configured as upstream server (personally I know this is not a good configuration, but they did it anyway). What kind of association were they, Peer, Server, AnyCast, ...? I remember at least one setup with 4 identical servers, where each server had a local GPS refclock configured (which for sure didn't send the leap warning anymore after the real leap second had passed) and in addition had simple server entries for the other 3 servers. Unfortunately this was mostly handled on the phone, so I don't have any records with details. Anyway, I'll see if we can install a similar setup here to see if we can duplicate this behaviour. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany __**_ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/**questionshttp://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] WARNING: someone's faking a leap second tonight
I've seen no evidence of a denial of service attack, bugs are more likely. Several stratum one servers have been advertising LI=1 continuously for the past month. Others alternate between LI=0 and LI=1. Most servers claim to run ntpd. There are over 10 stratum one's that advertise LI=1 as of Wed Aug 1 14:18:51 UTC 2012. Unless this changes another false leap second could occur on August 31, 2012 On Wed, Aug 1, 2012 at 7:58 AM, Marco Marongiu brontoli...@gmail.comwrote: On 01/08/12 10:28, Marco Marongiu wrote: I tried to collect some information around the globe, but with scarce/no feedback. I am *suspecting* that this could be a rather imaginative attempt to DOS worldwide. Anyway, a colleague of mine is now hunting down some upstreams that faked the leap second. If we get something out of his research, I'll let you know. While my colleague is working with a stratum 1 timekeeper to investigate this better, I called the people at INRiM in Italy -- INRiM is the institution responsible for the official Italian time (http://www.inrim.it/index.shtml). Mr.Pettiti confirmed there was *no* leap second scheduled yesterday (as we all suspected, right?), so that is definitely a fake. It may well be a DOS attempt, but as another colleague of mine suggests, it could also be a bug in some upstream servers, which didn't disarm the leap second after June 30th, and propagated it again yesterday. Question now is: assuming those servers were running ntpd, was such a bug reported at some point? Ciao -- bronto ___ 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] WARNING: someone's faking a leap second tonight
The main standard says a leap second is allowed in any month. That's what the reference ntpd does. See ITU-R, TF460, STANDARD-FREQUENCY AND TIME-SIGNAL EMISSIONS. This link may work: http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf On the other hand Bulletin C ( ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat) says December or June. Take your pick. On Wed, Aug 1, 2012 at 10:54 AM, Rob nom...@example.com wrote: steven Sommars stevesommars...@gmail.com wrote: I've seen no evidence of a denial of service attack, bugs are more likely. Several stratum one servers have been advertising LI=1 continuously for the past month. Others alternate between LI=0 and LI=1. Most servers claim to run ntpd. There are over 10 stratum one's that advertise LI=1 as of Wed Aug 1 14:18:51 UTC 2012. Unless this changes another false leap second could occur on August 31, 2012 When a leapsecond occurs as a result of these bits that is a bug on its own, because leapseconds can only occur at the end of a quarter. ___ 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] ntpd 4.2.7p230 defaults to ignoring ntpdc queries
Dave, How do you see the ntpdc (/ntpd/ntpdc) transition happening? [I expect most post 4.2.7p230 ntpd builds to use the default options] http://www.eecis.udel.edu/~mills/ntp/html/ntpdc.html makes no mention of an upcoming obsolescence/deprecation and likely few ntpdc users have planned for it. Was there an announcement or web page? ntpdate is covered in https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate . https://support.ntp.org/bin/view/Dev/DeprecatingNtpdc is only a placeholder. To query a mix of ntpd server versions will now require use of a new ntpq and a (deprecated) ntpdc and logic to determine which to use.Smoother transition schemes are possible but may run counter to the simplification goals. With its smaller user base deprecating ntpdc should be less contentious than ntpdate was. I don't object to the changes(mode 7 is ugly), but believe that some documentation work (e.g,. in DeprecatingNtpdc) may be worthwhile. Steve Sommars On Thu, Nov 3, 2011 at 4:14 PM, Dave Hart h...@ntp.org wrote: For a long time, ntpq and its mostly text-based mode 6 (control) protocol have been preferred over ntpdc and its mode 7 (private request) protocol for runtime queries and configuration. There has been a goal of deprecating ntpdc, previously held back by numerous capabilities exposed by ntpdc with no ntpq equivalent. I have been adding commands to ntpq to cover these cases, and I believe I've covered them all, though I've not compared command-by-command recently. As I've said previously, the binary mode 7 protocol involves a lot of hand-rolled structure layout and byte-swapping code in both ntpd and ntpdc which is hard to get right. As ntpd grows and changes, the changes are difficult to expose via ntpdc while maintaining forward and backward compatibility between ntpdc and ntpd. In contrast, ntpq's text-based, label=value approach involves more code reuse and allows compatible changes without extra work in most cases. Mode 7 has always been defined as vendor/implementation-specific while mode 6 is described in RFC 1305 and intended to be open to interop with other implementations. There is an early draft of an updated mode 6 description that likely will join the other NTPv4 RFCs eventually. [1] For these reasons, ntpd 4.2.7p230 by default disables processing of ntpdc queries, reducing ntpd's attack surface and functionally deprecating ntpdc. If you are in the habit of using ntpdc for certain operations, please try the ntpq equivalent. If there's no equivalent, please open a bug report at http://bugs.ntp.org./ Thanks, Dave Hart [1] http://tools.ietf.org/html/draft-odonoghue-ntpv4-control-01 ___ 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] garmin 18x and linux
I monitored Garmin LVC (corrected firmware) NMEA time and saw variance of up to 50msec. I wonder if the variation in NMEA time depends on GPS signal quality. On Fri, Sep 2, 2011 at 11:19 PM, unruh un...@wormhole.physics.ubc.cawrote: On 2011-09-02, David Woolley david@ex.djwhome.demon.invalid wrote: Rob wrote: You will find (you have found) that by posting on this group, your message falls into the hands of a small group of people that will either base all their solutions on much more stringent requirements than you actually have (e.g. they don't consider using GPS serial messages because it is not possible to have millisecond precision with that), or they go on an on about how the requirements you post cannot be achieved at all and should be relaxed or be realized with atom clocks etc. NTP isn't designed to work at accuracies worse than a few 10s of milliseconds. ?? Where does this come from? While it is true that there is the 128ms rule ( which I believe can be adjusted) but where is this coming from? And besides, Garmin GPS nmea can control to better than 10ms. ___ 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] Garmin firmware update - GPS 18x 5Hz software version 3.20
You may want to watch for several days. Previous 18x LVC firmware (3.60) drifted on my system from 0.5 to 1.4 seconds over a span of 6 days. I've been running a beta version of 3.70 for several weeks with no problems. On Wed, Jun 15, 2011 at 4:09 PM, Kasper Pedersen ngfil...@kasperkp.dkwrote: On 06/15/2011 08:10 AM, David J Taylor wrote: http://www8.garmin.com/support/agree.jsp?id=4065utm_source=feedburnerutm_medium=feedutm_campaign=Feed%3A+garmin%2FVKiE+%28Garmin+|+Software+Updates%29 Although for the 5Hz model, GPS 18x 5Hz, this firmware update includes: * Improved NMEA output timing stability I tested 18x-LVC 3.70 The NMEA message starts at ~0.5s, and this time contains the correct second value. So it appears to be good. (running 115200 if this matters) /Kasper Pedersen ___ 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
