Re: [ntp:questions] 500ppm - is it too small?
"David Malone" <> wrote in message news:h6dh6d$rg...@walton.maths.tcd.ie... [] > Indeed - to push us back on track a little, here's a graph of the > drift values from a few hundred machines: > > http://www.maths.tcd.ie/~dwmalone/time/drifts.png > > There's almost 600 machines in that list, but it included machines > from two big clusters, so there is a certain uniformity of hardware. > Most machines are Linux, but there are also some versions of FreeBSD. > > David. Most helpful, David, thanks very much. Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Running ntpd in a Windows domain
Hi all, running ntpd in a Windows domain has been discussed here quite some time. However, recent discussions of the NTP developers make me assume running ntpd in a Windows domain may result in some ugly problems. Summary: Normally if w32time is running on the PDC it makes an entry in the active directory which identifies that PDC as authoritative time source, so other servers and workstations running w32time can identify that PDC as their authoritative time source when they log in to the domain. If ntpd is running instead of w32time on the PDC then there is no such entry in the active directory, so other servers and workstations running w32time are unable to detect the PDC as authoritative time source. Of course, if all other servers and clients also run ntpd then you can submit an appropriate ntp.conf file to those machines, with a server entry pointing to the PDC. There have been two proposals for workarounds if there are still client machines running w32time: 1.) On the PDC, make w32time depending on ntpd and start it additionally to ntpd. So w32time starts *after* ntpd. It has been reported that even though w32time is unable to open NTP port 123 it continues to execute and makes the relevant entry in the directory. However, ntpd will respond to network requests. This may work or not depending on the version of w32time, i.e. it won't work anymore if a version of w32time stops itself if it is unable to open port 123 (just like ntpd would do). 2.) The time source on the clients could be configured manually or using group policies, so they could be configured to use any upstream NTP server, either the PDC or any other NTP server. The reason for this posting is the following: The development version of the NTP package contains code which can let the Samba software running on the same Unnix machine append a MS-style signature to the reply packets to be sent to w32time clients. This shall be required if the Samba server on a Unix machine has been configured to take the role of a Windows PDC. That MS-style signature is not compatible with the autokey or MD5 signatures normally used by NTP. This makes me assume recent w32time versions running on a PDC also append a MS-style signature to the packets sent to its clients, and the w32time clients expect reply packets with a valid MS-style signature from their upstream server. IIRC ntpd supports MS-style signatures only in cooperation with Samba, so ntpd does *not* support that type of signature if running on a real Windows PDC. AFAICS this means recent w32time clients in a Windows domain would never accept reply packets from the PDC if ntpd instead of w32time is running on the PDC, even if either of the workarounds mentioned above is being used. Of course you could run ntpd also on the clients, which would accept the NTP daemon running on the server as their time source. However, the question is if other applications (e.g. databases) running on workstations or secondary servers try to find out whether the time of the machine they are running on is synchronized to the "network time", and complain if this is not the case. If they do, then how do they do it? Do w32time clients also provide a registry setting or API to let other applications find out whether the system time is synchronized? If this is the case then it would not even help to install ntpd both on the PDC and on other servers and workstations. Unfortunately I don't have access to a Windows domain, so I'd like to ask if someone else in this group has experience with ntpd running in a domain of recent Windows versions? Thanks, 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] 500ppm - is it too small?
David Mills wrote: > Bill, > > "Traditional" seems to imply some kind of voodoo art. See my 1997 > Internet survey which characterized the time and frequency errors of > some 27,000 NTP servers. The median error was 38.6 PPM, mean error 78.1 > PPM. 2.5 percent of the population showed zero error and 3 percent more > than 500 PPM error. Those two populations were not synchronized to a > working server. There is a histogram in the paper, which is also in my > book along with a discussion on the issues. Speaking for myself, in > probably several hundred machines I have seen at one time or another, > none had errors more than 200 PPM. Someone should repeat the survey since that was 12 years ago. Clocks have changed but I suspect that the quality has not. > > The advice handed down in the documentation has always been to trim the > intrinsic error to less than 100 PPM by adjusting the tick value, either > with the tickadj program in the distribution or by some native OS > facility. Otherwise, the sawtooth error can become very large. > > Somebody should ask the question what happens in NTP if the intrinsic > error is greater than 500 PPM. Funny thing, the contraption keeps right > on working, but cannot trim the time offset to all the way to zero. What prevents the time offset from being trimmed to zero? 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] 500ppm - is it too small?
Richard B. Gilbert wrote: > Unruh wrote: >> "Richard B. Gilbert" writes: >> >>> Evandro Menezes wrote: It's not so much a question of clock error as the ability of NTP converging too slowly. If it could slew by more than 500PPM, than it could even avoid time steps, especially backwards. It seems that being able to slew more than 500PPM is what makes Chrony perform so much better than NTP in adverse conditions. I'm starting to wonder if NTP actually stands for "standard (normal) temperature and pressure", to hint at its ideal conditions design... :-) >>> The design was intended to cope with the horrors of the internet. >>> Packets may arrive with variable delays. Some may not arrive at all. >>> Ntpd does manage to extract a reasonable approximation of the correct >>> time in spite of having to do it over the internet. You might find it >>> interesting/useful to look at the statistics for ntpd during the period >>> 11PM to 7AM local time and compare them with the stats for the other >>> sixteen hours of the day. >>> If you find that chrony gives you better results, please feel free to >>> use it. >> I had thought that this discussion group was a group to discuss time on >> computers using the ntp protocol, including improvements in the way that >> the reference implimentation uses the protocol to discipline the clocks. >> The evidence is that at least under some fairly broad circumstances, >> chrony disciplines the clocks better than does the reference >> implimentation ( by factors reported to be from 2 to 20 times better), >> converges to the correct time far faster than does ntp, does not step >> the time, and can handle out of spec clocks ( eg whose drift rate is >> larger than 500PPM) better. I would think that this might lead the >> reference implimentation to consider altering its approach so that it at >> least equaled chrony. >> It may of course be that there are circumstances where ntp does better, >> but noone has ever demonstrated that as far as I know, and if it is >> true, it would be really useful to know. >> >> But the discussion strikes me as being similar to the discussion between >> the American and Japanese car makers in the 90s. Time and again, it was >> argued that the Japanse were better than the American in all kinds of >> areas, and the response of the American car makers was "If they are so >> much better why don't you just go buy one". And eventually the Americans >> did. >> >> At the same time I see statements that chrony controlled clocks should >> not be allowed as part of the pool, and that there are ways of >> determining that they are not runnning reference ntp and thus could be >> actively kept out of the pool. Reminds me of the attempts by the >> American car makers to have the government outlaw Japanese cars. >> >> >> >> chrony does have weaknesses. It runs only on Linux and BSD at present. >> It has a much smaller range of refclocks that it supports ( as of now >> only the shm refclock added very recently by Lichvar). Both are distinct >> disadvantages. >> >> What I would like to see is a dispassionate examination of the strengths >> and weaknesses of the various approaches, and have the reference >> implimentation use the very best. Instead I see what looks like a >> religion, where questions are treated as apostasy or treason. (You >> remember the statements to the Vietnam protestors, that if they do not >> like everything the US does, they should move to Russia, or Vietnam, or >> Liberia, or) or Canada? >> > > Testing and comparing in a laboratory can certainly be done. It does > require some facilities not readily available. I'd think that comparing > both programs configured as recommended by the author(s) using identical > hardware, network connections, etc. with an atomic clock for a week or > so would tell us far more than a flame war here. Something like that would take a large research grant, lab space and a fairly sophisticated setup. This is not something that most people can do. However, the question that you would need to answer is what would the benefit be? If it's just to say whether chrony is better or worse than ntpd, then you are just wasting time, money and effort. Better to use what fits your needs. 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] 500ppm - is it too small?
Unruh wrote: > The changes that chrony would demand lie at the heart of ntp-- the heart > which is even listed in the rfc, and the heart which is controlled by > David Mills, and which in the ntp reference code says "Do not make > changes without getting the OK of David Mills" (paraphrase). > > Also my coding abilities are not that great. > I am also sure that the lack of coders is one of the reasons why there > is a resistance to making a major change to ntp. No, the real reason is that you have to understand how the algorithms really work extremely well and then defend your changes (think Ph.D. thesis defense) after you have done lots of simulation and testing of a wide variety of scenarios. This is not something that most people would be able to do. 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] Running ntpd in a Windows domain
On Tue, Aug 18, 2009 at 10:34 AM, Martin Burnicki wrote: > AFAICS this means recent w32time clients in a Windows domain would never > accept reply packets from the PDC if ntpd instead of w32time is running on > the PDC, even if either of the workarounds mentioned above is being used. > Of course you could run ntpd also on the clients, which would accept the > NTP daemon running on the server as their time source. You are correct. It is conceivable that one day ntpd will be enhanced to perform MS-SNTP signing on Windows DCs. ntpd would then also need to ensure the DC is advertised as a time source within the domain by setting the registry value or whatever. > However, the question is if other applications (e.g. databases) running on > workstations or secondary servers try to find out whether the time of the > machine they are running on is synchronized to the "network time", and > complain if this is not the case. I do not believe so. > If they do, then how do they do it? Do w32time clients also provide a > registry setting or API to let other applications find out whether the > system time is synchronized? If this is the case then it would not even > help to install ntpd both on the PDC and on other servers and workstations. > > Unfortunately I don't have access to a Windows domain, so I'd like to ask if > someone else in this group has experience with ntpd running in a domain of > recent Windows versions? I run ntpd on a _a_ DC, but not on the DC acting as PDC. The PDC is set to sync to the ntpd DC. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
Harlan Stenn wrote in news:ywn9iqglsynz@ntp1.isc.org: ... > Now I'm more inclined to think you are a troll. > > The copyright says: > > *... that the name > * * University of Delaware not be used in advertising or publicity >* * pertaining to distribution of the software without specific, > * * written prior permission. > The text of the "approved" ntp licence at http://www.opensource.org/licenses/ntp-license.php refers (somewhat oddly it seems to me), not specifically to "University of Delaware," but rather to the "string variables" of (CopyrightHoldersName) and (TrademarkedName). I mistook the latter as referring to the name "ntp" when, in fact, both "string variables" appear to have been assigned (by whom?) a common value of "University of Delaware." Overlooking this "string substitution" oddity, I now withdraw my cavils regarding ntp's status as open source. Regards, PS I do not, however, withdraw my earlier comments regarding the "political overhead" associated with the design and development of ntp. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
nemo_outis writes: > I do not, however, withdraw my earlier comments regarding the > "political overhead" associated with the design and development of > ntp. Every successful Open Source project I know of has similar "overhead". -- John Hasler j...@dhh.gt.org Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
John Hasler wrote in news:87my5xnlwj@thumper.dhh.gt.org: > nemo_outis writes: >> I do not, however, withdraw my earlier comments regarding the >> "political overhead" associated with the design and development of >> ntp. > > Every successful Open Source project I know of has similar "overhead". Quite so. For instance, OpenBSD comes to mind as an even more egregious case of dominance by a single personality, the "parent" who can't/won't let go. That such political overhead is common in open source doesn't make it any less a deplorable nuisance. Regards, ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
This is a remarkably long and interesting thread so I don't feel it's unreasonable to insert a comment which relates more directly to the original post. Way back in May 2009, David Taylor and Richard Gilbert said (Richard) > An error greater than 500 PPM suggests seriously broken hardware! There > might be some way to "kludge" the software to compensate for > this brokenness but I think it would be easier and cheaper to fix or > replace the broken hardware. (David) I was trying to see what errors might be expected in the typical PC clock crystals, but my gut instinct is to agree with you. However, suggesting that someone replace their pride and joy just because it doesn't run ntp is unlikely to elicit a favourable response! I recall that the NTP support wiki has a page on "known hardware issues" (http://support.ntp.org/bin/view/Support/ KnownHardwareIssues#Section_9.1.7.) which cites a number of examples where combinations of hardware, BIOS and OS produced some seriously unstable or inaccurate clocks. It seems to me that these combinations really are in some sense "broken", but they could often be fixed without replacing the hardware. My instinct is that it would be better for people who encounter systems with very inaccurate or unstable clocks to document these cases and look for (and document) fixes which don't involve changes to ntp. -- John Allen Bofferdange, Luxembourg al...@vo.lu http://allenlux.dyndns.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
>>> In article , dwmal...@maths.tcd.ie (David >>> Malone) writes: David> Indeed - to push us back on track a little, here's a graph of the David> drift values from a few hundred machines: David> http://www.maths.tcd.ie/~dwmalone/time/drifts.png Again, drift values are about the clock's *time*, and the 500ppm slew limit is about the clock's *frequency*. -- Harlan Stenn http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] >>>> MOUSE PICTURES <<<
___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Running ntpd in a Windows domain
Dave Hart wrote: > On Tue, Aug 18, 2009 at 10:34 AM, Martin > Burnicki wrote: > >> AFAICS this means recent w32time clients in a Windows domain would never >> accept reply packets from the PDC if ntpd instead of w32time is running on >> the PDC, even if either of the workarounds mentioned above is being used. >> Of course you could run ntpd also on the clients, which would accept the >> NTP daemon running on the server as their time source. >> > > You are correct. It is conceivable that one day ntpd will be enhanced > to perform MS-SNTP signing on Windows DCs. ntpd would then also need > to ensure the DC is advertised as a time source within the domain by > setting the registry value or whatever. > > >> However, the question is if other applications (e.g. databases) running on >> workstations or secondary servers try to find out whether the time of the >> machine they are running on is synchronized to the "network time", and >> complain if this is not the case. >> > > I do not believe so. > > >> If they do, then how do they do it? Do w32time clients also provide a >> registry setting or API to let other applications find out whether the >> system time is synchronized? If this is the case then it would not even >> help to install ntpd both on the PDC and on other servers and workstations. >> >> Unfortunately I don't have access to a Windows domain, so I'd like to ask if >> someone else in this group has experience with ntpd running in a domain of >> recent Windows versions? >> > > I run ntpd on a _a_ DC, but not on the DC acting as PDC. The PDC is > set to sync to the ntpd DC. > This puts the time control evidence model outside of the DC and increases the complexity of DC and PDCe type operations. Todd > Cheers, > Dave Hart > ___ > questions mailing list > questions@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/questions > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.59/2310 - Release Date: 08/17/09 > 18:04:00 > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Slow sychronization
Hi All, I am running a new version of the NTP daemon, version 4.2.4p6, on a Linux machine with kenel version 2.6.27. When I start the daemon, the peer information shows that all the peer have a offset of about 30 milliseconds. This offset will increase to about 50 milliseconds after an hour. It might take many hour to days before the offset comes down to a few milliseconds. I tried using 'iburst' on the peers to see if this would speed things up, but it made no difference. Are there any settings to speed up this process? Is the a problem with this version of NTP? Thanks, Ray - ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] >>>> ART GAMES <<<
___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow sychronization
Ray wrote: > Hi All, > > I am running a new version of the NTP daemon, version 4.2.4p6, on a Linux > machine with kenel version 2.6.27. > > When I start the daemon, the peer information shows that all the peer have a > offset of about 30 milliseconds. This offset will increase to about 50 > milliseconds after an hour. It might take many hour to days before the > offset comes down to a few milliseconds. I tried using 'iburst' on the peers > to see if this would speed things up, but it made no difference. > > Are there any settings to speed up this process? Is the a problem with this > version of NTP? > > Thanks, > Ray > - > > Ntpd will keep your clock well synchronized but it requires many hours to reach that state following a cold start. Performance is somewhat better after a warm start. For best results, start ntpd ten to twelve hours before you need tight synchronization. Let it run continuously as long as you need it. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
>>> In article , Harlan Stenn >>> writes: >>> In article , dwmal...@maths.tcd.ie (David >>> Malone) writes: David> Indeed - to push us back on track a little, here's a graph of the David> drift values from a few hundred machines: David> http://www.maths.tcd.ie/~dwmalone/time/drifts.png Harlan> Again, drift values are about the clock's *time*, and the 500ppm Harlan> slew limit is about the clock's *frequency*. I was, of course, insane when I wrote that. I misread and thought that offsets were being plotted, not drift file values (which are, indeed, the ppm frequency offsets). -- Harlan Stenn http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow sychronization
Ray wrote: > Hi All, > > I am running a new version of the NTP daemon, version 4.2.4p6, on a Linux > machine with kenel version 2.6.27. > > When I start the daemon, the peer information shows that all the peer have a > offset of about 30 milliseconds. This offset will increase to about 50 > milliseconds after an hour. It might take many hour to days before the > offset comes down to a few milliseconds. I tried using 'iburst' on the peers > to see if this would speed things up, but it made no difference. I've seen same on NetBSD and FreeBSD and took it as normal on a fresh install with large swings in offset until a reasonable value for drift has been obtained. If you're lucky, a new kernel doesn't cause a significant change from existing driftfile value and sync will be quite rapid. Other point mentioned in the 500ppm thread is that if the drift value is large not only will it take a long period to sync, it may also not be possible at all for ntp to adjust to a reasonable offset or worse the offset will become unstable and swing wildly. Here, with a small value of drift, a few ppm, or maybe an established driftfile with larger frequency offset (but < 50ppm), I'd expect time offset to be within a few ms after a couple of hours or so assuming delay from sources is reasonably steady. "ntpdc -c loopinfo" gives following for my three servers: pc:k6-400 p4-2400via-c3-600 ntpd version: 4.2.0-r4.2.4p24.2.4p2 offset(ms):-0.00180.37 -0.000336 frequency(ppm):-0.876 8.868 -49.225 offsets taken at 30min split into ranges <.1ms <.2ms <.5ms etc 95%range(ms): <5 <5 <10 David > > Are there any settings to speed up this process? Is the a problem with this > version of NTP? > > Thanks, > Ray > - > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow sychronization
Ray wrote: > Hi All, > > I am running a new version of the NTP daemon, version 4.2.4p6, on a Linux > machine with kenel version 2.6.27. > > When I start the daemon, the peer information shows that all the peer have a > offset of about 30 milliseconds. This offset will increase to about 50 > milliseconds after an hour. It might take many hour to days before the > offset comes down to a few milliseconds. I tried using 'iburst' on the peers > to see if this would speed things up, but it made no difference. > > Are there any settings to speed up this process? Is the a problem with this > version of NTP? > > Thanks, > Ray > - > > The topic has been visited several times in the last year or two. The only solution I know of is to let ntpd run continuously. If, for any reason, you need to shut down and reboot regularly, ntpd is probably a poor choice. There is software available called "chrony" which provides "gratification now". I am uncertain as to whether it provides the same accuracy as ntpd. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow sychronization
"Richard B. Gilbert" writes: >Ray wrote: >> Hi All, >> >> I am running a new version of the NTP daemon, version 4.2.4p6, on a Linux >> machine with kenel version 2.6.27. >> >> When I start the daemon, the peer information shows that all the peer have a >> offset of about 30 milliseconds. This offset will increase to about 50 >> milliseconds after an hour. It might take many hour to days before the >> offset comes down to a few milliseconds. I tried using 'iburst' on the peers >> to see if this would speed things up, but it made no difference. >> >> Are there any settings to speed up this process? Is the a problem with this >> version of NTP? >> >> Thanks, >> Ray >> - >> >> >The topic has been visited several times in the last year or two. The >only solution I know of is to let ntpd run continuously. If, for any >reason, you need to shut down and reboot regularly, ntpd is probably a >poor choice. >There is software available called "chrony" which provides >"gratification now". I am uncertain as to whether it provides the same >accuracy as ntpd. In my tests, it provides about a factor of 2 better accuracy than does ntpd. It runs on Linux and BSD. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
