Re: [ntp:questions] Keeping NTP Honest Redux
Evandro Menezes evan...@mailinator.com wrote in message news:d9a76148-a9c9-45d5-ac72-4e7588c61...@m7g2000prd.googlegroups.com... I've come to the conclusion that since NTP doesn't correct for temperature variations, it's long-term compensation is counter- productive. Therefore, instead of letting the poll period increase to the default 1024s, perhaps it'd be best to limit it to 64s. However, this requires that each server has the option maxpoll attached to it. It'd be more convenient to have set this parameter for all servers from a single place, such as the old tinker maxpoll option. So, why was tinker maxpoll removed? Any chance to get it back in? TIA What sort of accuracy are you wanting, and what OS are you running? You could add a local stratum-1 server with a GPS source if you are after really good performance, or you could lock your PCs to one local system with 64s poll and have that system sync over the Internet with the default automatic poll. Some public servers may consider excessive polling to be an attack and disconnect you. Here is what you can get with a Garmin GPS 18x LVC puck and Windows-7 (an OS not known for its timekeeping). Use FreeBSD and you would likely get at least ten times better: http://www.satsignal.eu/mrtg/stamsund_ntp_2.html A Windows XP system synced to that stratum-1 PC shows these temperature- and load-related variations: http://www.satsignal.eu/mrtg/narvik_ntp-b.html Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] NTP 4.2.5p241-RC Released
Redwood City, CA - 2009/11/07 - The NTP Public Services Project (http://support.ntp.org/) is pleased to announce that NTP 4.2.5p241-RC, a Release Candidate of the NTP Reference Implementation from the NTP Project, is now available at http://www.ntp.org/downloads.html and http://support.ntp.org/download. File-size: 4261671 bytes MD5 sum: b27c7446b4542ab0042adde07ae14771 Changes: * Remove unused file from sntp/Makefile.am's distribution list. * new crypto signature cleanup. * html/authopt.html update from Dave Mills. Please report any bugs, issues, or desired enhancements at http://bugs.ntp.org/. The NTP (Network Time Protocol) Public Services Project, which is hosted by Internet Systems Consortium, Inc. (http://www.isc.org/), provides support and additional development resources for the Reference Implementation of NTP produced by the NTP Project (http://www.ntp.org/). ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest Redux
Evandro Menezes wrote: On Nov 6, 3:10 pm, Terje Mathisenterje.mathi...@tmsw.no wrote: Making it more convenient to lock polling at 64s isn't a good idea, imho. What do you suggest to mitigate the wild swings between daytime and nighttime, sunny and cloudy, cold-front and warm-front, etc, of both the offset and the frequency? If this in fact a real problem, I'd suggest wrapping some insulation around the clock crystal. This would make temperature swings much slower, right? Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest Redux
Terje Mathisen wrote: Evandro Menezes wrote: On Nov 6, 3:10 pm, Terje Mathisenterje.mathi...@tmsw.no wrote: Making it more convenient to lock polling at 64s isn't a good idea, imho. What do you suggest to mitigate the wild swings between daytime and nighttime, sunny and cloudy, cold-front and warm-front, etc, of both the offset and the frequency? If this in fact a real problem, I'd suggest wrapping some insulation around the clock crystal. This would make temperature swings much slower, right? If you REALLY care, use an Oven Controlled crystal oscillator. Most servers live in a data center in which the temperature is controlled to within +/- two degrees F. I suspect that an OCXO will not buy you much in the way of greater stability but if you are scrambling in pursuit of the one true time. . . . ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest Redux
Richard, It's amazing how much bullshit is spread by others without checking the documentation, the code, the loopstats data and for that matter the papers and the book. You correctly observe the poll interval does change in response to measured system jitter and oscillator wander. As confirmed by experience and the data, the dynamics are quick to respond to increasing wander and slow to respond to decreasing wander. Dave Richard B. Gilbert wrote: Unruh wrote: Richard B. Gilbert rgilber...@comcast.net writes: Terje Mathisen wrote: Evandro Menezes wrote: I've come to the conclusion that since NTP doesn't correct for temperature variations, it's long-term compensation is counter- productive. Therefore, instead of letting the poll period increase to the default 1024s, perhaps it'd be best to limit it to 64s. However, this requires that each server has the option maxpoll attached to it. It'd be more convenient to have set this parameter for all servers from a single place, such as the old tinker maxpoll option. So, why was tinker maxpoll removed? Any chance to get it back in? Maybe because the algorithms have been optimized to get the best possible time with minimum load on the servers? Making it more convenient to lock polling at 64s isn't a good idea, imho. Locking the polling interval at ANY value probably isn't a good idea. If not tampered with, NTPD will adjust the polling interval to the optimum value for the conditions then obtaining. The conditions do change. Well, not really. ntp is designed to quite rapidly go to maxpoll of 10 and to stay there. The routine is very loath to decrease the poll and quick to increase it, so that it rarely decreases the poll interval. Ie, My observations do not support that. The polling interval changes throughout the day in both directions. snip ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdc +time since reset:
:Laurent. The time since reset is the time since the statistics were reset and the sysstats monitoring file updated, which occurs once per hour. See the documentation on monitoring commands. This feature is designed for very busy server such as those operated by NIST, USNO, and intended as early warning detector of clogging attacks. Dave Laurent Archambault wrote: Hello all, my question is probably always asked, sorry for this, but i don't see an explain for this : Example : When i use ntpd-4.2.4P6 compiled the time since restart and time since reset: are equal very often. But i use ntp-4.2.4p7 under the last Ubuntu and compiled by myself and the time since reset do not exceed 3600 sec ... it's good for me, because all numbers are light. But i will known how change this value (3600) . Many thanks for this. ntpdc -c sysstats localhost time since restart: 473049 time since reset: 1449 packets received: 13 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] tinkering with minpoll and maxpoll
Aneeq, The absolute minimum poll exponent 3 (8 s) is required by stability considerations and the adjustment interval of 1 s. The absolute maximum poll exponent 17 (36 h) is an arbitrary choice based on the wander characteristics of commodity computer clock oscillators. The default minimum of 6 (64 s) and default maximum of 10 (1024 s) were set thirty years ago by mindless conjecture, but have proven good choices under typical LAN and WAN conditions. When you hook up your cesium oscillator, you may need to reconsider these choices. Dave Aneeq Mahmood wrote: HI all, Can someone shed some light on the default values of MINPOLL , MINDPOLL , MAXPOLL etc etc in ntp.h file. I can not understand the logic for choosing these particular numbers. If there is any then please share it with me. Also what ramifications i can face if i decide to change these values as far as synchronization of my network is concerned. Some comments on that will be appreciated. Cheers!! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest Redux
Terje Mathisen terje.mathi...@tmsw.no writes: Evandro Menezes wrote: On Nov 6, 3:10 pm, Terje Mathisenterje.mathi...@tmsw.no wrote: Making it more convenient to lock polling at 64s isn't a good idea, imho. What do you suggest to mitigate the wild swings between daytime and nighttime, sunny and cloudy, cold-front and warm-front, etc, of both the offset and the frequency? If this in fact a real problem, I'd suggest wrapping some insulation around the clock crystal. This would make temperature swings much slower, right? Or use the ntp version with temperature input to correct the clock. Eg, http://www.ijs.si/time/temp-compensation/ Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Fudge time offset on client/peer?
Rich Wales wrote: you might experiment with the new interleaved mode to see how it handles the asymmetry. You could peer your home and work refclock ntpds . . . . Actually, I tried that some time back, but it didn't help a bit. I eventually came to understand that xleave mode is designed to reduce the effect of processing delays inside a server's network stack. Sadly, it doesn't do a thing to alleviate asymmetries. Indeed, my current impression (someone please correct me if I'm wrong!) is that NTP is *inherently incapable* of measuring (or even detecting) network latency asymmetries -- the NTP protocol assumes that traffic comes and goes with equal speed, and it has no way to detect situations in which this is not true. That is correct, unfortunately. Noone has been able to come up with a scheme that will allow NTP, or any other program for that matter, to be able to measure any asymmetry. All it can tell is when it sent out a packet and when it got it back. There is nothing that either end can do to give it any indication of the nature of the asymmetry. Neither photons nor electrons can tell you how fast they were moving even in a single segment never mind over multiple segments. I have no idea why anyone would think the xleave would make any difference since it cannot tell you anything about asymmetry. The fudge command is really meant for refclocks and not servers or peers. I don't think that it can be used to express asymmetry for a server or peer. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Fudge time offset on client/peer?
Dave, Can we not just introduce an option on the server line for this? That would effectively give you the association. The caviat here is how do you know what to put in the argument? Danny David Mills wrote: Rich, I have the same situation you have, but a dedicated ISDN line and routers that have a mostly symmetric delays. A per-association fudge is not possilbe unless the peer mobilization code is overhauled. There is in fact a calibration mechanism designed to compensate for small inconsistencies using the PPS signal as the ultimate reference. That is controlled by the enable/disable calibrate command and applies to all associations. A command might be introduced that could affect a specified association, but it would have to be given via ntpq after mobilization. Dave Rich Wales wrote: I suggest you don't want that. What you need is a fudge on the interface, not the association. In this situation, I think I really do want a fudge on the association. Consider the issue from the POV of my work desktop. My work desktop has a single network interface, connected to a conventional 100BASE-TX ethernet network. It has fast (and, for my purposes, sufficiently symmetric) connectivity over my school's campus network to stratum-1 and stratum-2 servers run by the campus IT services. In order for my work desktop to see the stratum-1 server I'm running at my home, however, it has to go over the campus network to the cable-modem network servicing the townhouse complex where I live. As I previously mentioned, this cable modem network appears to have an asymmetry, which I would like to fudge away for the benefit of my work desktop (but *not* for my home LAN). If I were to fudge the network interface of my work desktop, this would presumably affect not only its view of my home stratum-1 server, but also my work desktop's view of the campus tickers. What I think I want/need is a way to fudge my work desktop's view of one peer/server, but not another peer/server. That's why I wanted to be able to fudge an association. Rich Wales / ri...@richw.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Fudge time offset on client/peer?
Danny, Sure you can in a couple of lines of code. However, where are you going to put the result? The proto_config() call has a fixed number of fields all tied up with data structures used for name resolution and for remote configuration. The original plan, now only part way completed, was to save everything in the parse ttree while the resolver is out to lunch, then pick up where it left off when lunch is over. That would completely resolve (no pun) the issue and allow an indefinate expansion in configuration options. Dave Danny Mayer wrote: Dave, Can we not just introduce an option on the server line for this? That would effectively give you the association. The caviat here is how do you know what to put in the argument? Danny David Mills wrote: Rich, I have the same situation you have, but a dedicated ISDN line and routers that have a mostly symmetric delays. A per-association fudge is not possilbe unless the peer mobilization code is overhauled. There is in fact a calibration mechanism designed to compensate for small inconsistencies using the PPS signal as the ultimate reference. That is controlled by the enable/disable calibrate command and applies to all associations. A command might be introduced that could affect a specified association, but it would have to be given via ntpq after mobilization. Dave Rich Wales wrote: I suggest you don't want that. What you need is a fudge on the interface, not the association. In this situation, I think I really do want a fudge on the association. Consider the issue from the POV of my work desktop. My work desktop has a single network interface, connected to a conventional 100BASE-TX ethernet network. It has fast (and, for my purposes, sufficiently symmetric) connectivity over my school's campus network to stratum-1 and stratum-2 servers run by the campus IT services. In order for my work desktop to see the stratum-1 server I'm running at my home, however, it has to go over the campus network to the cable-modem network servicing the townhouse complex where I live. As I previously mentioned, this cable modem network appears to have an asymmetry, which I would like to fudge away for the benefit of my work desktop (but *not* for my home LAN). If I were to fudge the network interface of my work desktop, this would presumably affect not only its view of my home stratum-1 server, but also my work desktop's view of the campus tickers. What I think I want/need is a way to fudge my work desktop's view of one peer/server, but not another peer/server. That's why I wanted to be able to fudge an association. Rich Wales / ri...@richw.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest Redux
NTPD is at its best from about 2300 local time to 0700 local time. The net quiets down and NTP packets travel with minimal and highly predictable delays. Except at 3 AM when the cron jobs go off and warm up the system. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
