[ntp:questions] Mixed maxpoll values for mixed LAN/Internet servers - sensible?
Folks, It's been suggested that if I have a mixture of a "known-good" (i.e. GPS/PPS-based) LAN server, and some Internet-based backup servers, I could use an ntp configuration file with different maxpolls, with the idea that syncing more often to a good source will produce even lower offsets. Something like: server lan-gps-pps prefer iburst maxpoll 6 server 0.uk.pool.ntp.org iburst server 1.uk.pool.ntp.org iburst server 2.uk.pool.ntp.org iburst If I do this, is the maxpoll for the Internet servers also clamped at 6, or will it gradually up to 1024s (10). Is this a sensible thing to do for a client without a refclock? Thanks, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] question on leap second insertion in syslog
ManI, Manikandan D wrote: > Hello to the great brainy(s) out there.. > > Quick question about the logging of leap second in the syslog... we have > few number of Linux boxes, last year December 2008 23:59:59 when there was > a leap second inserted, all the systems reported "Clock: inserting leap > second..." If the kernel supports leap seconds (this is the case for Linux) then the NTP daemon just passes the leap second announcement to the kernel. The kernel then handles the leap second and generates the appropriate log message. > But in our local testing for leap second inserting we noticed that the > syslog reported "discipline status change 0010" at times "discipline > status change 0011" > > Can someone please explain me the difference here? I understand there are > no issues, but for documenting purpose I need the information, your inputs > will be highly appreciated.. The NTP daemon does a plausibility check, i.e. it accepts leap seconds only at the end of June or December. >From what you've written above it looks like you have chosen some other date to test a leap second. In this case ntpd does not pass the leap second announcement to the kernel. Instead, if ntpd's configured time source inserts a leap second at a non-supported date then ntpd will observe a sudden time step of 1 second, and will step the system time some time later, which may result in the status change you've observed (I haven't checked the meaning of the status codes, though). Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Mixed maxpoll values for mixed LAN/Internet servers - sensible?
"David J Taylor" wrote in message news:qctpl.13$lc...@text.news.virginmedia.com... > It's been suggested that if I have a mixture of a "known-good" (i.e. > GPS/PPS-based) LAN server, and some Internet-based backup servers, I > could use an ntp configuration file with different maxpolls, with the > idea that syncing more often to a good source will produce even lower > offsets. Polling more often will produce lower offsets, yes, but mostly because it doesn't allow time for larger errors to grow. Once phase error is no longer dominant, the poll interval is lengthened to better correct frequency error. Not an idle pursuit. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Is the use of the leap seconds mechanism mandatory?
Hi, The primary reason why I need NTP is the synchronization of the systems, not the accuracy of time. I need to simplify the maintenance of the systems as much as possible. I would like to know if it is mandatory to use the leap seconds mechanism and installing the up to date leap file in order to have ntpd working smoothly. Thanks for your answers. Alain BARTHOLOMÉ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is the use of the leap seconds mechanism mandatory?
Hi Alain, Bartholome, Alain wrote: > Hi, > > The primary reason why I need NTP is the synchronization of the systems, > not the accuracy of time. > > I need to simplify the maintenance of the systems as much as possible. > > I would like to know if it is mandatory to use the leap seconds mechanism > and installing the up to date leap file in order to have ntpd working > smoothly. Basically the time used by NTP is assumed to be UTC. However, in fact it is just the time provided by the top level reference time source, so in a closed network you can distribute any time instead of UTC, with or without leap seconds, if you control the top level time source. In order to have NTP handle leap seconds correctly it is important that the leap second is announced properly. Once the top level NTP server is aware of the leap second it passes the announcement to its clients. In turn the clients can also act as NTP servers and cann pass the announcement on to their clients, after they have receive the announcement from their upstream server. You have to take care that the last client in the hierarchy receives the announcement before the leap second occurs. For examples, if there are 2 levels of clients below the top level server which are polling at long intervals of 1024 seconds then the top level server has to start to announce the leap second more then 2048 seconds before it occurs. Otherwise the last clients will miss it. If you have a GPS receiver as top level ref time source for the top level NTP daemon then the GPS receiver is internally aware of the upcoming leap second. The question is which protocol is used to pass the time string to the NTP daemon. E.g., AFAIK, the NMEA protocol does not support leap second announcements, so the server will not become aware of an upcoming leap second. In this case the leap second file (of course the current version) can make sure the top level server is aware of the leap second and starts to announce it down the client chain early enough. So if you use the file you're on the safe side, and the the effort to supply the file to the top level server should not be too hard. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Mixed maxpoll values for mixed LAN/Internet servers - sensible?
"David J Taylor" writes: >Folks, >It's been suggested that if I have a mixture of a "known-good" (i.e. >GPS/PPS-based) LAN server, and some Internet-based backup servers, I could >use an ntp configuration file with different maxpolls, with the idea that >syncing more often to a good source will produce even lower offsets. >Something like: > server lan-gps-pps prefer iburst maxpoll 6 > server 0.uk.pool.ntp.org iburst > server 1.uk.pool.ntp.org iburst > server 2.uk.pool.ntp.org iburst >If I do this, is the maxpoll for the Internet servers also clamped at 6, >or will it gradually up to 1024s (10). No, not clamped. Maxpoll refers to the specific server it is referenced to . In your case lan-gps-pps. Because of the way ntp disciplines the clock, the disadvantage of low poll intervals is that the rate discipline of the clock is poorer. Now, if you remain attached to the source, that is not critical, since the more frequency polling makes up for it. But if you ever get disconnected from that source, your clock will drift off correct time faster. Actually your poll interval should be tuned to your particular computer's clock. If your computer receives a lot of variable use ( big high cpu programs for 15 min and then nothing for the next 15 min) poll 10 is too long. If it sits there chugging along doing exactly the same stuff all the time, It could even be too short. ntp has no way of measuring the real "Allan intercept" for your machine. chrony does that automatically, and as a result actually controlls the clock better than does ntp. But that is another topic. >Is this a sensible thing to do for a client without a refclock? It depends. Note that it also depends on who owns that refclock. They may not want people querying it so often. Certainly Mills would get annoyed if you clamped the poll interval to the udel servers at maxpoll 6 Of course if you own it, you can do as you wish. >Thanks, >David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is the use of the leap seconds mechanism mandatory?
alain.barthol...@eads.com (Bartholome, Alain) writes: >Hi, >The primary reason why I need NTP is the synchronization of the systems, >not the accuracy of time. >I need to simplify the maintenance of the systems as much as possible. >I would like to know if it is mandatory to use the leap seconds mechanism >and installing the up to date leap file in order to have ntpd working >smoothly. If you do not care what time it is then no, you do not need to do leap seconds ( or days). >Thanks for your answers. >Alain BARTHOLOMÉ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] ntpd and hw clock
Hello All; I just wanted to verify that ntpd is NOT attempting to directly set hardware clock. It just uses system calls such as settimeofday to set the time to the Kernel and the time has to be sent to rtc, if so desired, by the Kernel itself or separately using e.g. hwclock. Thanks. Wayne ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
Danny, Judah, There might be some misunderstanding here. The current KoD scheme is part of a larger strategy for rate managment. The input packet rate and rsponse rate including KoD are components in an overall strategy. The input rate is monitored and packets dropped to achieve an overall fairness strategy. If a KoD reponse is enabled by configuration, the KoD rate is itself policed not to exceed the target rate. This means that not every packet will be accepted and not every accepted packet will result in a response or KoD. Just to remind folks, the current behavior when a rate exceeded situation is found is to return the packe with all fields unchanged. Thus, whatever packets do get ruturned are not useful for timekeeping purposes. Frankly, the KoD was never intended as a quick fix, only a strategy that might help in a few cases where a responsible but possibly misguided implementor was at fault. On the other hand, the rate management/crafted discard policy has been a real help with our busy public servers. These don't get even close to the NIST/USNO servers in volume, but then indeed the rate management strategy does kick in. Dave Danny Mayer wrote: >jlevine wrote: > > >>Thanks to all of you who responded to my initial post regarding very >>rapid >>polling. I have fixed this particular instance with some cooperation >>from the >>ISP. However, the generic problem remains and is likely to re-appear. >>I don't know of a good general solution to this problem because: >> >> 1. the KOD packets are generally not effective. Either the remote >>software >>does not recognize them or it chooses to ignore them. The KOD method >>obviously would not work against an attack. >> 2. Sending any reply at all doubles the network traffic and makes >>an >>attack more effective. Therefore, all of the NIST servers log the >>event and >>the source ip but do not respond. I think it is not appropriate for a >>national >>timing laboratory to knowingly send the wrong time. >> 3. This sort of stuff is really more general than NTP -- denial of >>service >>attacks can use many different protocols and a more general network >>solution is going to be needed. >> 4. A serious denial-of-service attack probably requires a botnet to >>cause >>real trouble, and fixing that problem might reduce the impact of all >>denial >>of service attacks. >> >>Judah Levine >>Time and Frequency Division >>NIST Boulder >> >> >> > >We should go through BCP 38 (RFC 2827) and see if there is something >that we can do on the basis of that document. It will take time for >review. Did you discover anything specific about the abusive clients? > >Danny > > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd and hw clock
wayne@impinj.com (Wayne Liu) writes: >Hello All; >I just wanted to verify that ntpd is NOT attempting to directly set >hardware clock. It just uses system calls such as settimeofday to set >the time to the Kernel and the time has to be sent to rtc, if so >desired, by the Kernel itself or separately using e.g. hwclock. Well, there is that silly 11min setting of the kernel, which tried to reset the rtc every 11 min if it decides that the kernel is synchronized. >Thanks. >Wayne ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd and hw clock
Wayne Liu wrote: > > I just wanted to verify that ntpd is NOT attempting to directly set > hardware clock. It just uses system calls such as settimeofday to set I am not aware of any platform on which ntpd directly manipulates the hardware clock, although the only real requirements are that it sets the same one it reads and that it can read and modify it with fairly high resolution (precision, in ntpd jargon). However, even on machines with settimeofday, it only uses that as a last resort, and should never use it after the startup transients. The preferred option for Unix is to tell the kernel how much the time differs from its measurement, and rely on the kernel to use this to adjust the clock in the way that ntpd expects (which does not mean that the kernel will apply anything like that full difference before the next update). The fallback for Unix type systems is to periodically send a time delta (in which case, ntpd does the smoothing, so the corrections are less than the measured offset; it also interpolates between measurements). For NT, it varies the assumed frequency of the clock used to convert ticks to time of day. > the time to the Kernel and the time has to be sent to rtc, if so > desired, by the Kernel itself or separately using e.g. hwclock. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Mixed maxpoll values for mixed LAN/Internet servers - sensible?
Unruh wrote: > "David J Taylor" >> server lan-gps-pps prefer iburst maxpoll 6 >> server 0.uk.pool.ntp.org iburst >> server 1.uk.pool.ntp.org iburst >> server 2.uk.pool.ntp.org iburst > >> If I do this, is the maxpoll for the Internet servers also clamped >> at 6, or will it gradually up to 1024s (10). > > No, not clamped. Maxpoll refers to the specific server it is > referenced to . In your case lan-gps-pps. Well, by observation, /all/ the servers are polled at 64s intervals, and not just the lan-gps-pps server. [Caveat, I actually tested maxpoll=7, and all the servers show a poll of 128s. Tested with Meinberg's "vegas" ntpd 4@p6] [] > It depends. Note that it also depends on who owns that refclock. They > may > not want people querying it so often. > Certainly Mills would get annoyed if you clamped the poll interval to > the > udel servers at maxpoll 6 > Of course if you own it, you can do as you wish. Yes, I own it, but I don't want to hit on the Internet servers any more than necessary, of course. Thanks for your reply, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] improving ntpd performance on Windows
I figured I hadn't blown enough hot air, so I'll add that the 200920226 version is available at: http://davehart.net/ntp/refclock/ specifically http://davehart.net/ntp/refclock/ntp-4.2.4p6-DLH-QPC-20090226-bin.zip http://tinyurl.com/bjd6rg http://davehart.net/ntp/refclock/ntp-4.2.4p6-DLH-QPC-20090226-debug-bin.zip http://tinyurl.com/cqkqsc Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] improving ntpd performance on Windows
If you're using ntpd on Windows synchonizing to a stable local source (whether refclock or simply ntpd on a heretofore more-stable platform for timekeeping) I would appreciate your help testing my 20090226 test version. The approach to interpolating time using a high-frequency counter has been reworked and on my machines with a precision source, has taken roughly 500us of jitter away. I'm particularly interested in how it works on systems with 100 Hz system clock interrupts (10 msec period). All my test flock are 64 Hz. This version (and my prior test versions going back weeks) tells you your system clock period in the event log or configured log file: ntpd[30396]: Clock interrupt period 15.600 msec (startup slew 0.2 usec/ period) I'm hoping someone will try the 20090226 version of my code on a system that reports 10.000 msec clock interrupt period. If the new interpolation code falls down on such a system, setting environment variable NTPD_INT_INT=26 or some other value in the range of about 20-50 (milliseconds between counter samples) might tame it. If it works well you should see ntpq report jitter below 0.100 relative to your source after it settles down. ntpd[30396]: System time precision 1.000 msec, min. slew 6.410 ppm/s ntpd[30396]: using native clock directly Note the last line indicates your system will not use interpolation. If you are running on Vista or Windows 7, make sure you use -M (default with Meinberg's installer). That will ensure ntpd detects the fine-grained system time precision at startup and disables interpolation. This is different than 4.2.4p6 and seems to improve performance. See my prior thread mentioning a blunt object. I would have preferred to find an interpolation scheme that works on Vista/Win 7 as well, but neither my tweaks to the old interpolation approach nor experiments with the new one have yet worked at all on Vista. Compared to the released 4.2.4p6, my test version has substantial improvements for serial reference clocks on Windows, including support for PPS on the CD pin, with or without the use of the interrupt-time timestamps available with my patched serial.sys (serialpps.sys). I'm able to keep jitter of a Garmin GPS 18x LVC connected to a dual 400Mhz PII system typically under 20 usec, and probably at worst +/- 200 usec. The reduction in local clock jitter also helps LAN clients stay in better sync with a local server, though to measure how much better it helps if the server is stable. As a test I fiddled with the set of internet servers carefully to minimize clockhopping to generally cause 1 msec or less steps and overall manage to stay within +/- msec of the changing sources. With that machine (running my ntpd) as the relatively stable source, I installed the released 4.2.4p6 using Meinberg's convenient installer on a machine which had not previously run ntpd, and configured it to use only the (somewhat) stable source with maxpoll 6. Just before 1300 UTC I switched in my 20090226 build ntpd.exe and restarted. Take a look at the loopstats graph: http://davehart.net/ntp/refclock/loopstats-20090226-LAN-64s-vegasv2-vs-DLH-QPC-20090226.jpg shorter, equivalent URL: http://tinyurl.com/ao8bhm There's a 15 msec step when 4.2.4p6 is shut down caused by it setting the hardware clock by reading then setting the software clock as part of ntpd shutdown. My version improves on this by only setting the hardware clock when ntpd is stopping due to a computer shutdown when synchronized, so in the case of restarting to upgrade or change configuration, the clock is left finely-tuned. Ongoing slew is also left alone in my version rather than turned off at ntpd shutdown. There's a clear reduction in jitter visible on the right half of that chart. Zooming in on the transition at 1300 UTC makes the scale clearer: http://davehart.net/ntp/refclock/loopstats-20090226-LAN-64s-vegasv2-vs-DLH-QPC-20090226-zoom.jpg http://tinyurl.com/cx7d7l Peter Rosin originally discovered the 1 msec jitter bug in ntpd on Windows in 2003. Details available behind a certificate warning (unless you have the cacert.org root cert installed) at: https://support.ntp.org/bugs/show_bug.cgi?id=216 Enjoy, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd and hw clock
Unruh schreef: > Well, there is that silly 11min setting of the kernel, which tried to reset > the rtc every 11 min if it decides that the kernel is synchronized. Silly indeed, but rather Linux-specific. No such kludge in FreeBSD afaik. N ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
