[ntp:questions] Garmin 18 LVC: whether to fudge
Hello, I'm using a Garmin 18 LVC connected using LinuxPPS with mostly good results. I am curious about one thing though. The offset reported by the GPS18 differ from the public NIST servers by around 1.7-1.9MS. as shown in the offset numbers of ntpq below. remote refid st t when poll reach delay offset jitter == *GPS_NMEA(0) .GPS.0 l4 16 3770.000 -0.448 0.189 +bigben.cac.wash .USNO. 1 u 34 1024 377 11.1340.283 2.645 All of the server's internet peers are ahead by around that same value so I'm guessing that when the GPS18 loses sync, ntpd would have to bring the clock up by 2MS and reverse when signal is reacquired. Is there any way to know whether it's our internet link (ADSL) causing the internet servers to appear off or does the GPS18 need a time1 fudge to bring it in line with the others? That is, is there a 2MS lag in processing the interrupt for PPS? Best, Shane ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Problem using ntp autokey with the trusted ce rtificate identity s cheme
I downloaded the development version of NTP (4.2.5p158), I installed it on all the systems, I kept the certificates and the same configuration (except the logconfig line of ntp.conf) especially one trusted system. It works. The synchronization of server3 occurred quite quickly. I am quite worried about the release version... Thanks for your help. Alain BARTHOLOMÉ -Message d'origine- De : questions-bounces+alain.bartholome=eads@lists.ntp.org [mailto:questions-bounces+alain.bartholome=eads@lists.ntp.org] De la part de Martin Burnicki Envoyé : mardi 10 février 2009 10:17 À : questions@lists.ntp.org Objet : Re: [ntp:questions] Problem using ntp autokey with the trusted certificate identity scheme Steve Kostecke wrote: > On 2009-02-10, Danny Mayer wrote: >> Steve Kostecke wrote: >> [---=| Quote block shrinked by t-prot: 24 lines snipped |=---] >> server3 does not synchronize with server2 >>> >>> The problem here is that you want to operate _two_ trust groups: >>> >>> server2 trusts serverT1 >>> server3 trusts server2 >>> >>> Server3 needs to be able to trust server2. Try regenerating the >>> paramters on server2 using '-T'. >> >> My understanding from what Dave has said is that the newer versions of >> the development branch supports multiple trust groups. > > You missed the point. The OP has set up a _chain_ of two trust groups. > This is not a problem with one ntpd serving multiple trust groups. > > The server for the second trust group needs to have a trusted cert so > that it will be trused by its client. This is an interesting setup, but should not be very uncommon. Has anyone *tried* to configure autokey so that a machine is a client which uses one certificate for his upstream server, and additionally acts as a server who provides its own certificate to its clients? This setup should also be mentioned in http://support.ntp.org/Support/ConfiguringAutokey Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ 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
[ntp:questions] NTP over redundant peer links, undetected loops
Hi! We are trying to implement a NTP installation over a redundant network, connecting the stratum 2 servers to the stratum 3 clients. The precise situation is the following (compare with http://1stein.org/download/network.png): 3 networks, 192.168.3.0, 192.168.4.0, 192.168.5.0 ATOM1, ATOM2 - stratum 1 servers in network 3 GW1, GW2 - stratum 2 servers in all networks, i.e. 3, 4, 5 CLIENT1...CLIENTn - stratum 3 clients in network 4 and 5 Our goal is that GW1 and GW2 are always synchronized, even - if network 3 goes down, - or if one of networks 4 or 5 goes down, - or if the worst case happens that network 3 and 4 (or 5) go down and only one link is left between GW1, GW2 and the clients. We have configured the hosts in the following way: GW1 - with two IPs GW1_4, GW1_5 server 127.127.1.0 fudge stratum 5 server ATOM1 server ATOM2 peer GW2_4 peer GW2_5 GW2 - with two IPs GW2_4, GW2_5 server 127.127.1.0 fudge stratum 10 server ATOM1 server ATOM2 peer GW1_4 peer GW1_5 CLIENT1 ... CLIENTn server GW1 server GW2 The problem: If network 3 goes down, GW1 and GW2 select each other as their reference clock, one over network 4, one over network 5. The loop detection does not work here. The stratum of both references goes up poll by poll, until it reaches 16. Then one of GW1/GW2, say GW1, switches to the LOCAL(0) source. After the new stratum of GW1 propages to GW2 and back to GW1 (as stratum 7), GW1 switches back to GW2, even though the local clock's stratum is smaller. Then the game starts again that the stratum goes up by propagation. Solution 1: By removing one peer connection, we are able to remove the possible loop and it starts working, obviously by loosing some of the redundancy in network 4 and 5 which we do not want. Solution 2: We can also remove all peer statements and put "server GW1_4" and "server GW1_5" in GW2's config. But then we are lost if ATOM1 and ATOM2 are out of sync, because then it can happen that GW1 syncs to ATOM1 and GW2 to ATOM2, such that GW1 and GW2 are out of sync. But the latter _must not_ happen. Is there a way to tell xntpd to identify the IPs GW1_4, GW1_5 and GW2_4, GW2_5 such that the loop detection works? Can one force to use a common refid instead of the IP? Regards Stefan Schimanski ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd failure on ioctl(I_SETSIG, S_INPUT): Bbad address
Sorry I wasn't clear on my previous message. I was doing cross-compile and it turns out to be a build option error on my part. I got it working now. It's exactly like what Frank said, UDP_SIGPOLL is not used for linux. After checking the source of configure that I realized that I had the wrong build option --host=, where is not *-*-*linux*. I and also have to add into config.sub since it's not one of the machines supported. What I eventually did was to set and export env. variables CC/LD/AR pointing to -gcc and set --host=-linux. Thanks to all for your responses. Wayne -Original Message- From: questions-bounces+wliu=impinj@lists.ntp.org [mailto:questions-bounces+wliu=impinj@lists.ntp.org] On Behalf Of Frank Kardel Sent: Sunday, February 08, 2009 9:41 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] ntpd failure on ioctl(I_SETSIG,S_INPUT): Bbad address Danny Mayer wrote: > Harlan Stenn wrote: > In article <977ad296bdaf2f428cf7028f923e4a200af1a...@earth.impinj.com>, wayne@impinj.com (Wayne Liu) writes: >> Wayne> Hello All; I'm running the latest ntp-4.2.4p6 on Linux 2.6.18 and I >> Wayne> got the following up front when I start ntpd: === ntpd >> Wayne> 4.2@1.1549 Fri Feb 6 02:09:46 UTC 2009 (3) setsockopt >> Wayne> SO_TIMESTAMP enabled on fd 16 address 0.0.0.0 bind() fd 16, family 2, >> Wayne> port 123, addr 0.0.0.0, flags=0x89 addto_syslog: init_socket_sig: >> Wayne> ioctl(I_SETSIG, S_INPUT) failed: Bad address == >> >> Wayne> From the kernel code it seems that "Bad address" is due to I_SETSIG not >> Wayne> being supported by sock as an ioctl cmd, which is then passed down to >> Wayne> dev_ioctl underneath which rejects the arg S_INPUT as bad address. ... >> >> The configure choices for USE_UDP_SIGPOLL were done a long time ago and >> might have changed. >> > > I think that's what Frank implemented recently for dynamic interface > notification. Nope. I didn't fiddle there. I didn't even have to go near the IO/SIGNAL setup code. EFAULT usually means that there is an invalid address. Usually unsupported options are indicated by EINVAL. Looking into configuration on Linux 2.6.16.27 everything is fine. SIGPOLL is not detected (config.h /* #undef USE_UDP_SIGPOLL */) ntp 4.2.4p6 works as designed. Looking at configure USE_UDP_SIGPOLL is not used if configure finds *-*-linux* as host specification. Maybe your distro has a different host specification. > > Danny >> I'd appreciate learning how to discern the correct answer for your case. >> >> I do not know what the correct answer is... Best regards, Frank ___ 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] Problem using ntp autokey with the trusted certificate identity s cheme
Martin, Yes, this scenario is included in the online documentation. Dave Martin Burnicki wrote: >Steve Kostecke wrote: > > >>On 2009-02-10, Danny Mayer wrote: >> >> >>>Steve Kostecke wrote: >>>[---=| Quote block shrinked by t-prot: 24 lines snipped |=---] >>> >>> >>> >server3 does not synchronize with server2 > > The problem here is that you want to operate _two_ trust groups: server2 trusts serverT1 server3 trusts server2 Server3 needs to be able to trust server2. Try regenerating the paramters on server2 using '-T'. >>>My understanding from what Dave has said is that the newer versions of >>>the development branch supports multiple trust groups. >>> >>> >>You missed the point. The OP has set up a _chain_ of two trust groups. >>This is not a problem with one ntpd serving multiple trust groups. >> >>The server for the second trust group needs to have a trusted cert so >>that it will be trused by its client. >> >> > >This is an interesting setup, but should not be very uncommon. > >Has anyone *tried* to configure autokey so that a machine is a client which >uses one certificate for his upstream server, and additionally acts as a >server who provides its own certificate to its clients? > >This setup should also be mentioned in >http://support.ntp.org/Support/ConfiguringAutokey > >Martin > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Problem using ntp autokey with the trusted certificate identity s cheme
Guys, The current version does support multiple trusted groups, but see the online documenation. Every trusted group has a single tier of trusted hosts, but can be a client of other trusted groups. See the example in the documentation; it is simple to configure. Dave Danny Mayer wrote: >Steve Kostecke wrote: > > >>On 2009-02-04, Bartholome, Alain wrote: >> >> >> >>>I am currently trying to run the ntp autokey protocol with the Trusted >>>Certificate identity scheme. >>> >>> >>You may find the information at >>http://support.ntp.org/Support/ConfiguringAutokey to be helpful. >> >> >> >>>I use 3 systems (serverT1, server2,server3) all running ntp-4.2.4p6 on >>>windows 2003. >>> >>> >>This means that the debate about ntp-stable vs ntp-dev is not relevant >>to your case. Just remember that the documentaion at >>http://www.eecis.udel.edu/~mills/ntp/html/ is for ntp-dev; see >>http://doc.ntp.org/ or the ./html/ directory in the release tarball for >>your version for the documentation applicable to that version. >> >> >> >>>1)The stratum 1 system , serverT1 is trusted. >>> >>> >>>2) serveur server2 is not trusted , synchronization is successful with >>>serverT1 >>> >>> >>>3) server3 is not trusted and should synchronize with server2 >>> >>> >>>server3 does not synchronize with server2 >>> >>> >>The problem here is that you want to operate _two_ trust groups: >> >>server2 trusts serverT1 >>server3 trusts server2 >> >>Server3 needs to be able to trust server2. Try regenerating the >>paramters on server2 using '-T'. >> >> >> > >My understanding from what Dave has said is that the newer versions of >the development branch supports multiple trust groups. > >Danny >___ >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] Very rapid polling
Judah, Recent versions of NTP have very serious rate controls that prevent clients from exceeding specified burst rate and average headway constraints, even if improperly configured. Client packets that violate these constraints are discarded and, if so configured, the server will toss back a rate-controlled Kiss-o'-Death packet. A client receiving a KoD packet will reduce the sending constraints to near catatonic levels. These defenses are described in the online documentation. So, unless somebody hacks the implmentation, I doubt NTP is the problem. Dave Danny Mayer wrote: >jlevine wrote: > > >>In the last few days I have seen an increasing number of systems that >>are requesting the time in NTP format several times per second. This >>poll interval is far in excess of the usual best practices. Since >>there are a number of such systems, it is possible that this problem >>is a result of a new version of NTP that has just been released. >>Please let me know if you have any information about a new version of >>NTP that can do this or if any of you are seeing the same problem. >> >>Thanks. >> >>Judah Levine >>Time and Frequency Division >>NIST Boulder >> >> > >Hi Judah, > >There is no new release yet (the 4.2.4p6 was just a patch release to fix >a couple or minor issues mainly related to OpenSSL. It is most unlikely >that ntp is doing this. Did you take a couple of the addresses and query >them with ntpq? I don't think that ntpd can be configured to query that >quickly. Harlan is preparing a new stable release from the development >branch. Dave has added KOD code to deal with situations like this and >such clients are likely to find their clock drifting off if the do not >follow the protocols. > >Danny >___ >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] Very rapid polling
Danny Mayer wrote: > Eric wrote: >> On Mon, 9 Feb 2009 14:07:26 -0800 (PST), jlevine >> wrote for the entire planet to see: >> >>> In the last few days I have seen an increasing number of systems that >>> are requesting the time in NTP format several times per second. >> Have you considered the possibility that they are spoofed queries from a >> botnet? There are some records of which IPs are the current/past targets. >> >> There have been a number of recent DDoS attacks using spoofed UDP packets. >> The usual attack uses port 53 (DNS) and attempts to get 'amplification' of >> a small query into a large response towards the victim IP. NTP packets are >> the same size both ways, but might still be used to help with a flood. >> >> The only mitigation I can think of here is for NTP to not respond to >> excessive rate queries at all, or very infrequently, after the KOD. >> >> - Eric > > That's what the latest code does. > > Danny If ntpd responds to such DOS attacks with the WRONG YEAR or random date-times, it might discourage the perpetrators. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] What is the "best" synchronization possible over the network?
John Ioannidis wrote: > The problem setup: two locations, both within the United States, neither > has roof access so no GPS reception is possible. How do you synchronize > them with better than 50-microsecond accuracy? Straight NTP over the > Internet doesn't do the trick. They don't need to actually be > synchronized to "real" time, they only need to be synchronized to each > other. Assume reasonably unlimited resources (running a private fiber > plant across the continent *is* unreasonable). > > I've looked into slaving something off a voice-carrier time base, but > that's not accurate enough. Maybe something over raw SONET would do the > trick? > > Thanks > > /ji Two Atomic Clocks?? I suspect they would cost far more than you are willing/able to spend but they would get the job done! You could try putting a GPS antenna in a window with a southern exposure. With the proper GPS hardware and software, once you know your exact latitude, longitude, and elevation, you only need *one* satellite to get the time. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
Unruh wrote: > "Richard B. Gilbert" writes: > >> Unruh wrote: >>> "Richard B. Gilbert" writes: >>> jlevine wrote: > In the last few days I have seen an increasing number of systems that > are requesting the time in NTP format several times per second. This > poll interval is far in excess of the usual best practices. Since > there are a number of such systems, it is possible that this problem > is a result of a new version of NTP that has just been released. > Please let me know if you have any information about a new version of > NTP that can do this or if any of you are seeing the same problem. > > Thanks. > > Judah Levine > Time and Frequency Division > NIST Boulder Have you captured the IP addresses of the systems involved? If so, have you identified the ISP responsible for those addresses? Complained to the ISP? Etc, etc? The half witted will always be with us. . . . >>> There is no way you can set up ntpd so that it will poll many times a >>> second, unless there is a severe bug in ntp. He is asking if perhaps such a >>> bug exists in the latest version of ntpd ( since the latest version just >>> came out a month ago, and latest devel version a week ago, this would be a >>> sensible worry). >>> Alternatively one of those modem manufacturers may have screwed up again, >>> or some ntp like program has come out that has such a default. >>> I agree that asking the IP addressee what it is that they are running might >>> work, but probably not. >>> > >> It may take a while to get results but if the only alternative is to do >> nothing and suffer. . . . The ISPs have the power to cut these idiots >> off at the knees! Whether they are willing to do so is something you >> have to ask them. They also have the ability to reduce a network >> address to a street address. Again, you have to ask. If you ask on >> NIST letterhead, your chances of being taken seriously are much improved. > > IF it is a bug in ntp, then the users are not idiots, unless using ntp > makes you an idiot. If it is a bug in some other ntp software, then the > users of that software are not idiots, unless use of that software per se > makes you an idiot. If it is some modem manufacturer who has misapplied ntp > on their modem/router, again the same applies. He is trying to find out if > it is possible that such bugs exist, or than anyone else has seen them. > > >> As I recall my contract with Comcast, they can simply cut me off in >> response to just about any sort of abuse. If nobody complains, I can >> get away with practically anything! > > > Is a bug in the software "abuse"? > Yes! It's customary to do some sort of minimal testing before distributing your software to the masses. Given the past history; e.g. U-Wisconsin, Tardis, PHK vs. D-Link and a few other such incidents I'd say it's mandatory to do some pre-release testing of hardware, firmware, and/or software. I'd say that it's also mandatory to read, and comply with, the relevant RFCs. I doubt very much that ntpd has such a bug/misfeature! The authors are very much aware of the potential problems and have done an excellent job. It seems clear that the internet community needs a methodology for coping with such incidents. Each time, it seems that a posse comitatus must be formed, the miscreants tracked down, and asked to fix their hardware, firmware, or software. Sometimes, as in the U-Wisconsin incident it's not possible to track down all instances of the defective hardware/firmware/software.. With the ever increasing use of the internet, the problems are only going to get worse! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
Unruh wrote: > "Richard B. Gilbert" writes: > >> Unruh wrote: >>> "Richard B. Gilbert" writes: >>> jlevine wrote: > In the last few days I have seen an increasing number of systems that > are requesting the time in NTP format several times per second. This > poll interval is far in excess of the usual best practices. Since > there are a number of such systems, it is possible that this problem > is a result of a new version of NTP that has just been released. > Please let me know if you have any information about a new version of > NTP that can do this or if any of you are seeing the same problem. > > Thanks. > > Judah Levine > Time and Frequency Division > NIST Boulder Have you captured the IP addresses of the systems involved? If so, have you identified the ISP responsible for those addresses? Complained to the ISP? Etc, etc? The half witted will always be with us. . . . >>> There is no way you can set up ntpd so that it will poll many times a >>> second, unless there is a severe bug in ntp. He is asking if perhaps such a >>> bug exists in the latest version of ntpd ( since the latest version just >>> came out a month ago, and latest devel version a week ago, this would be a >>> sensible worry). >>> Alternatively one of those modem manufacturers may have screwed up again, >>> or some ntp like program has come out that has such a default. >>> I agree that asking the IP addressee what it is that they are running might >>> work, but probably not. >>> > >> It may take a while to get results but if the only alternative is to do >> nothing and suffer. . . . The ISPs have the power to cut these idiots >> off at the knees! Whether they are willing to do so is something you >> have to ask them. They also have the ability to reduce a network >> address to a street address. Again, you have to ask. If you ask on >> NIST letterhead, your chances of being taken seriously are much improved. > > IF it is a bug in ntp, then the users are not idiots, unless using ntp > makes you an idiot. If it is a bug in some other ntp software, then the > users of that software are not idiots, unless use of that software per se > makes you an idiot. If it is some modem manufacturer who has misapplied ntp > on their modem/router, again the same applies. He is trying to find out if > it is possible that such bugs exist, or than anyone else has seen them. > > >> As I recall my contract with Comcast, they can simply cut me off in >> response to just about any sort of abuse. If nobody complains, I can >> get away with practically anything! > > > Is a bug in the software "abuse"? Yes. Any software needs to be properly tested before it is released and checked to see that it follows the protocol rules. If you don't do proper QA then you not only are not doing proper development and you are not ensuring that you are working cooperatively with the server on which you are dependent for information. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
Eric wrote: > On Mon, 9 Feb 2009 14:07:26 -0800 (PST), jlevine > wrote for the entire planet to see: > >> In the last few days I have seen an increasing number of systems that >> are requesting the time in NTP format several times per second. > > Have you considered the possibility that they are spoofed queries from a > botnet? There are some records of which IPs are the current/past targets. > > There have been a number of recent DDoS attacks using spoofed UDP packets. > The usual attack uses port 53 (DNS) and attempts to get 'amplification' of > a small query into a large response towards the victim IP. NTP packets are > the same size both ways, but might still be used to help with a flood. > > The only mitigation I can think of here is for NTP to not respond to > excessive rate queries at all, or very infrequently, after the KOD. > > - Eric That's what the latest code does. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Uwe Klein wrote: > Richard B. Gilbert wrote: >> Uwe Klein wrote: >>> See: >>> currently on SuSE systems 'rcntpd restart' is run on any interface >>> changes. > >> Looks like a SuSE problem rather than an ntpd problem! > > Not really distribution specific. Look into the ip_up/down stuff > on any linux system. > > Its a dynamic IP problem and its a ntpd problem due to no > signaling path for interface changes. > ( there have been some improvements very recently? ) > > uwe ntp 4.2.4 supports dynamic interfaces even if it cannot detect the change directly. The O/S does not need to worry about this for ntpd. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Uwe Klein wrote: > Richard B. Gilbert wrote: >> Harlan Stenn wrote: >> >> In article , Martin Burnicki >> writes: >>> >>> Harlan> Because ntpd also gets restarted, and there is a strong belief >>> that >>> Harlan> -g is bad for a restart and restarts will happen more often than >>> Harlan> boots. >>> >>> Martin> Huh? I'm afraid I don't understand what you mean here. >>> >>> The general case is that -g should only be used at startup, when time >>> can be >>> stepped. >>> >>> If ntpd is restarted, it is Bad for the time to be stepped backwards for >>> many people. Since this could happen with -g, when restarting ntpd >>> for this >>> common case, one should not use -g. >> >> Why should it be necessary to restart ntpd Unless I have a power >> failure that lasts longer than my UPS, I almost never restart my NTP >> server! Same for the NTP clients. >> >> Systems that go down and up like a yo-yo are never going to know what >> time it is anyway! > > See: > currently on SuSE systems 'rcntpd restart' is run on any interface changes. > > uwe Why? ntpd support dynamic interface changes. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
Richard B. Gilbert wrote: > Unruh wrote: >> "Richard B. Gilbert" writes: >> >>> jlevine wrote: In the last few days I have seen an increasing number of systems that are requesting the time in NTP format several times per second. This poll interval is far in excess of the usual best practices. Since there are a number of such systems, it is possible that this problem is a result of a new version of NTP that has just been released. Please let me know if you have any information about a new version of NTP that can do this or if any of you are seeing the same problem. Thanks. Judah Levine Time and Frequency Division NIST Boulder >>> Have you captured the IP addresses of the systems involved? If so, have >>> you identified the ISP responsible for those addresses? Complained to >>> the ISP? Etc, etc? >>> The half witted will always be with us. . . . >> There is no way you can set up ntpd so that it will poll many times a >> second, unless there is a severe bug in ntp. He is asking if perhaps such a >> bug exists in the latest version of ntpd ( since the latest version just >> came out a month ago, and latest devel version a week ago, this would be a >> sensible worry). >> Alternatively one of those modem manufacturers may have screwed up again, >> or some ntp like program has come out that has such a default. >> I agree that asking the IP addressee what it is that they are running might >> work, but probably not. >> > > It may take a while to get results but if the only alternative is to do > nothing and suffer. . . . The ISPs have the power to cut these idiots > off at the knees! Whether they are willing to do so is something you > have to ask them. They also have the ability to reduce a network > address to a street address. Again, you have to ask. If you ask on > NIST letterhead, your chances of being taken seriously are much improved. > > As I recall my contract with Comcast, they can simply cut me off in > response to just about any sort of abuse. If nobody complains, I can > get away with practically anything! If you have the most recent versions of ntp-dev installed, ntpd will issue KOD packets and then stop responding for a while. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] What is the "best" synchronization possible over the network?
On Feb 10, 5:30 pm, n...@tla.org (John Ioannidis) wrote: > The problem setup: two locations, both within the United States, neither > has roof access so no GPS reception is possible. How do you synchronize > them with better than 50-microsecond accuracy? You might want to consider a CDMA receiver such as these units from EndRun Technologies: http://www.endruntechnologies.com/network-time-source.htm http://www.endruntechnologies.com/network-time-server.htm Regards, Gene Miller ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] What is the "best" synchronization possible over the network?
The problem setup: two locations, both within the United States, neither has roof access so no GPS reception is possible. How do you synchronize them with better than 50-microsecond accuracy? Straight NTP over the Internet doesn't do the trick. They don't need to actually be synchronized to "real" time, they only need to be synchronized to each other. Assume reasonably unlimited resources (running a private fiber plant across the continent *is* unreasonable). I've looked into slaving something off a voice-carrier time base, but that's not accurate enough. Maybe something over raw SONET would do the trick? Thanks /ji ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
>>> In article , Martin Burnicki >>> writes: Martin> The basic thing I don't understand in the context of this thread is Martin> why the behaviour with -g should not become the default behaviour Martin> for ntpd. Because -g overrides a sanity check. It is better to actively override a sanity check than it is to require an active action to provide a sanity check. -- 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] ntpdate works, but ntpd doesn't (reach = 0)
Nero Imhard wrote: > Uwe Klein wrote: > >> Not really distribution specific. Look into the ip_up/down stuff on >> any linux system. > > > Well, linux-specific then ;-) We will rule the world ;- > > Some smartass thing called "network manager" has bitten me in this > respect even on a system with totally static interfaces. It's enabled by > default (on Ubuntu) and screws things up for ntpd right at system boot. welcome to the club. "network manager" is a piece of shit. ( though my impression is that most of the semiautomagic stuff is not by a wide margin ripe enough for wide distribution and usage ) > >> Its a dynamic IP problem and its a ntpd problem due to no signaling >> path for interface changes. > > > It's a matter of opinion whether it is reasonable to want to run > full-blown ntpd on systems that are so unstable (interface-wise) taht > they need mechanisms to handle interface changes automatically. And you > can guess mine... As long as ntp is not only the prefered tool for time propagation but also used for final client services .. There will rising numbers of single hosts _and_ large networks hidden behind dynamic IPs and NAT. ( At least till everybody has changed over to IPV6 which will certainly not happen until after the depression following the current one has been overcome, or hell freezes over, whichever comes first). so any number of carefully selected derogatory words will lead us nowhere. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] like a kid with a new toy (PPS jitter)
On Feb 10, 12:58 pm, Chris
wrote:
>
> While I only have Windows 2003 DDK installed at the moment, they do
> include a complete serial device driver source project.
> I've only done very minor Windows driver programming, but I may try to
> download the newest DDK and give it a whirl.
You might as well be up-to-date, but my hunch is the serial code in
the DDK hasn't changed in a while. It's great the serial.sys source
is there as a baseline.
> // This bit is the delta data carrier detect. It is used to indicate
> // that the data carrier bit (in this register) has *changed*
> // since this register was last read by the CPU.
> //
> #define SERIAL_MSR_DDCD 0x08
>
> and
> if (ModemStatus & (SERIAL_MSR_DCTS |
> SERIAL_MSR_DDSR |
> SERIAL_MSR_TERI |
> SERIAL_MSR_DDCD)) {
>
> I think the change would/could be done in modmflow.c or isr.c, but I'd
> really have to do some reading to get comfortable with driver
> programming. I'm not really sure how'd I'd signal an event to the ATOM
> driver (perhaps through DeviceIoCtrl?)- Hide quoted text -
It sounds like you're on the right track. I believe the typical
approach on Unix does use ioctls, but it's an implementation choice as
long as you provide a matching ppsapi.h. ntpd calls a ppsapi
interface to get the timestamp of the last PPS, which could use
DeviceIoControl to retrieve it. However, there is a complicaton.
Unlike most modern unix platforms, Windows doesn't have a high-
resolution system clock with which to provide a reasonable timestamp
from the serial driver. I think you can overcome this by returning a
KeQueryPerformanceCounter (or whatever drivers call it) "timestamp"
and then hook your ppsapi implementation into the ntpd Windows
interpolation code to translate the performance counter value to a
timestamp. You might also run up against divergent QPC counters on
each processor, though most machines keep them at least roughly
synchronized.
It's a project :)
Cheers,
Dave Hart
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Uwe Klein wrote: > Not really distribution specific. Look into the ip_up/down stuff on > any linux system. Well, linux-specific then ;-) Some smartass thing called "network manager" has bitten me in this respect even on a system with totally static interfaces. It's enabled by default (on Ubuntu) and screws things up for ntpd right at system boot. > Its a dynamic IP problem and its a ntpd problem due to no signaling > path for interface changes. It's a matter of opinion whether it is reasonable to want to run full-blown ntpd on systems that are so unstable (interface-wise) taht they need mechanisms to handle interface changes automatically. And you can guess mine... N ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
"Richard B. Gilbert" writes: >Unruh wrote: >> "Richard B. Gilbert" writes: >> >>> jlevine wrote: In the last few days I have seen an increasing number of systems that are requesting the time in NTP format several times per second. This poll interval is far in excess of the usual best practices. Since there are a number of such systems, it is possible that this problem is a result of a new version of NTP that has just been released. Please let me know if you have any information about a new version of NTP that can do this or if any of you are seeing the same problem. Thanks. Judah Levine Time and Frequency Division NIST Boulder >> >>> Have you captured the IP addresses of the systems involved? If so, have >>> you identified the ISP responsible for those addresses? Complained to >>> the ISP? Etc, etc? >> >>> The half witted will always be with us. . . . >> >> There is no way you can set up ntpd so that it will poll many times a >> second, unless there is a severe bug in ntp. He is asking if perhaps such a >> bug exists in the latest version of ntpd ( since the latest version just >> came out a month ago, and latest devel version a week ago, this would be a >> sensible worry). >> Alternatively one of those modem manufacturers may have screwed up again, >> or some ntp like program has come out that has such a default. >> I agree that asking the IP addressee what it is that they are running might >> work, but probably not. >> >It may take a while to get results but if the only alternative is to do >nothing and suffer. . . . The ISPs have the power to cut these idiots >off at the knees! Whether they are willing to do so is something you >have to ask them. They also have the ability to reduce a network >address to a street address. Again, you have to ask. If you ask on >NIST letterhead, your chances of being taken seriously are much improved. IF it is a bug in ntp, then the users are not idiots, unless using ntp makes you an idiot. If it is a bug in some other ntp software, then the users of that software are not idiots, unless use of that software per se makes you an idiot. If it is some modem manufacturer who has misapplied ntp on their modem/router, again the same applies. He is trying to find out if it is possible that such bugs exist, or than anyone else has seen them. >As I recall my contract with Comcast, they can simply cut me off in >response to just about any sort of abuse. If nobody complains, I can >get away with practically anything! Is a bug in the software "abuse"? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
On Mon, 9 Feb 2009 14:07:26 -0800 (PST), jlevine wrote for the entire planet to see: >In the last few days I have seen an increasing number of systems that >are requesting the time in NTP format several times per second. Have you considered the possibility that they are spoofed queries from a botnet? There are some records of which IPs are the current/past targets. There have been a number of recent DDoS attacks using spoofed UDP packets. The usual attack uses port 53 (DNS) and attempts to get 'amplification' of a small query into a large response towards the victim IP. NTP packets are the same size both ways, but might still be used to help with a flood. The only mitigation I can think of here is for NTP to not respond to excessive rate queries at all, or very infrequently, after the KOD. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Richard B. Gilbert wrote: > Uwe Klein wrote: >> See: >> currently on SuSE systems 'rcntpd restart' is run on any interface >> changes. > > Looks like a SuSE problem rather than an ntpd problem! Not really distribution specific. Look into the ip_up/down stuff on any linux system. Its a dynamic IP problem and its a ntpd problem due to no signaling path for interface changes. ( there have been some improvements very recently? ) uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Uwe Klein wrote: > Richard B. Gilbert wrote: >> Harlan Stenn wrote: >> >> In article , Martin >> Burnicki writes: >>> >>> >>> Harlan> Because ntpd also gets restarted, and there is a strong >>> belief that >>> Harlan> -g is bad for a restart and restarts will happen more often than >>> Harlan> boots. >>> >>> Martin> Huh? I'm afraid I don't understand what you mean here. >>> >>> The general case is that -g should only be used at startup, when time >>> can be >>> stepped. >>> >>> If ntpd is restarted, it is Bad for the time to be stepped backwards for >>> many people. Since this could happen with -g, when restarting ntpd >>> for this >>> common case, one should not use -g. >> >> >> Why should it be necessary to restart ntpd Unless I have a power >> failure that lasts longer than my UPS, I almost never restart my NTP >> server! Same for the NTP clients. >> >> Systems that go down and up like a yo-yo are never going to know what >> time it is anyway! > > See: > currently on SuSE systems 'rcntpd restart' is run on any interface changes. > > uwe Looks like a SuSE problem rather than an ntpd problem! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Richard B. Gilbert wrote: > Harlan Stenn wrote: > > In article , Martin Burnicki > writes: >> >> >> Harlan> Because ntpd also gets restarted, and there is a strong belief >> that >> Harlan> -g is bad for a restart and restarts will happen more often than >> Harlan> boots. >> >> Martin> Huh? I'm afraid I don't understand what you mean here. >> >> The general case is that -g should only be used at startup, when time >> can be >> stepped. >> >> If ntpd is restarted, it is Bad for the time to be stepped backwards for >> many people. Since this could happen with -g, when restarting ntpd >> for this >> common case, one should not use -g. > > > Why should it be necessary to restart ntpd Unless I have a power > failure that lasts longer than my UPS, I almost never restart my NTP > server! Same for the NTP clients. > > Systems that go down and up like a yo-yo are never going to know what > time it is anyway! See: currently on SuSE systems 'rcntpd restart' is run on any interface changes. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Harlan Stenn wrote: In article , Martin Burnicki writes: > > Harlan> Because ntpd also gets restarted, and there is a strong belief that > Harlan> -g is bad for a restart and restarts will happen more often than > Harlan> boots. > > Martin> Huh? I'm afraid I don't understand what you mean here. > > The general case is that -g should only be used at startup, when time can be > stepped. > > If ntpd is restarted, it is Bad for the time to be stepped backwards for > many people. Since this could happen with -g, when restarting ntpd for this > common case, one should not use -g. Why should it be necessary to restart ntpd Unless I have a power failure that lasts longer than my UPS, I almost never restart my NTP server! Same for the NTP clients. Systems that go down and up like a yo-yo are never going to know what time it is anyway! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
On Feb 9, 8:26 pm, ma...@ntp.isc.org (Danny Mayer) wrote: > jlevine wrote: > > In the last few days I have seen an increasing number of systems that > > are requesting the time in NTP format several times per second. This > > poll interval is far in excess of the usual best practices. Since > > there are a number of such systems, it is possible that this problem > > is a result of a new version of NTP that has just been released. > > Please let me know if you have any information about a new version of > > NTP that can do this or if any of you are seeing the same problem. > > > Thanks. > > > Judah Levine > > Time and Frequency Division > > NIST Boulder > > Hi Judah, > > There is no new release yet (the 4.2.4p6 was just a patch release to fix > a couple or minor issues mainly related to OpenSSL. It is most unlikely > that ntp is doing this. Did you take a couple of the addresses and query > them with ntpq? I don't think that ntpd can be configured to query that > quickly. Harlan is preparing a new stable release from the development > branch. Dave has added KOD code to deal with situations like this and > such clients are likely to find their clock drifting off if the do not > follow the protocols. > > Danny Hello, I have the ip addresses that are causing the problems. I have not contacted the ISPs because my previous experience is that they are very unhelpful in dealling with these sorts of queries. However, the sources are domestic addresses, so perhaps there is a chance. I was pretty sure that this was not caused by a bug in a new version of NTP, but I just wanted to check for sure. (I remember that some older versions of Linux could use a poll interval of 0 by default, but that was a long time ago.) These sorts of problems come and go on all of our servers pretty much all of the time. Most of them are just annoying, but this one is serious enough to cause possible trouble. Thanks for your prompt replies. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
Unruh wrote: > "Richard B. Gilbert" writes: > >> jlevine wrote: >>> In the last few days I have seen an increasing number of systems that >>> are requesting the time in NTP format several times per second. This >>> poll interval is far in excess of the usual best practices. Since >>> there are a number of such systems, it is possible that this problem >>> is a result of a new version of NTP that has just been released. >>> Please let me know if you have any information about a new version of >>> NTP that can do this or if any of you are seeing the same problem. >>> >>> Thanks. >>> >>> Judah Levine >>> Time and Frequency Division >>> NIST Boulder > >> Have you captured the IP addresses of the systems involved? If so, have >> you identified the ISP responsible for those addresses? Complained to >> the ISP? Etc, etc? > >> The half witted will always be with us. . . . > > There is no way you can set up ntpd so that it will poll many times a > second, unless there is a severe bug in ntp. He is asking if perhaps such a > bug exists in the latest version of ntpd ( since the latest version just > came out a month ago, and latest devel version a week ago, this would be a > sensible worry). > Alternatively one of those modem manufacturers may have screwed up again, > or some ntp like program has come out that has such a default. > I agree that asking the IP addressee what it is that they are running might > work, but probably not. > It may take a while to get results but if the only alternative is to do nothing and suffer. . . . The ISPs have the power to cut these idiots off at the knees! Whether they are willing to do so is something you have to ask them. They also have the ability to reduce a network address to a street address. Again, you have to ask. If you ask on NIST letterhead, your chances of being taken seriously are much improved. As I recall my contract with Comcast, they can simply cut me off in response to just about any sort of abuse. If nobody complains, I can get away with practically anything! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] like a kid with a new toy (PPS jitter)
On Feb 8, 7:40 pm, Dave Hart wrote:
> On Feb 8, 12:12 pm, Chris
> wrote:
>
> > I'd be very interested to know your implementation in windows for
> > capturing the PPS pin. I'm currently using a FreeBSD box and syncing
> > windows boxes around it, but I'd much rather be able to sync my
> > windows servers directly to the device for a few of the critical
> > servers. Any chance you'd share your methods, or at least give some
> > hints? I'm well versed in the Windows API, so that shouldn't be a
> > problem. I just assumed that you'd need a kernel driver for this sort
> > of syncing.
>
> Well, a modified serial driver that would timestamp CD transitions
> would be ideal and would give better results than I'm getting. That's
> not really practical unless you can start with Microsoft's existing
> serial.sys code (it may be in the DDK, I don't know). What I've done
> is patch ntpd serial code for Windows to better emulate unix tty line
> discipline, where a read returns at each end of line. I've done this
> using WaitCommEvent and dcb.EventChar set to CR. The sources (a few
> days old) and binaries (very recent) for my patched ntpd for Windows
> are onhttp://davehart.net/refclock/
>
> The PPS implementation (hack) fell out of this design. Instead of
> waiting for just the event character, the code always waits for
> changes to the CD line. When it transitions on, a timestamp is
> taken. When a serial refclock next reads a line from the serial port,
> instead of timestamping the arrival of the CR, the PPS-on-CD timestamp
> is used instead if one has been taken since the last line was read.
> So this makes any serial refclock with PPS on the CD line act as a PPS-
> controlled refclock. It is not the preferred design, of course,
> because it's not getting a timestamp at interrupt time, and also
> because there is a move to get PPS functionality out of individual
> refclock drivers and use the separate ATOM refclock for the PPS
> aspect. Now my change doesn't use any PPS functionality in the
> reflclock driver, it just causes the reflock to appear to complete
> reading a line of text at the time of the PPS signal. It sounds like
> you might want to share the PPS signal among several hosts with only
> one getting the serial data pins connected. In that case, what you
> really need is a bit of work to provide a PPS-only refclock on
> Windows, presumably using the ATOM driver. I'm sure it can be done,
> it's just a matter of doing it cleanly enough to be accepted into the
> ntp reference implementation. Are you contemplating bringing just PPS
> to the Windows boxes or PPS+serial?
>
> The binares onhttp://davehart.net/refclock/have other patches as
> well as the serial code. They should behave better on Vista machines
> (assuming -M on the command line as defaulted by Meinberg's installer)
> by disabling nanokernel-like interpolation when it can't possibly work
> well. Other Windows machines should benefit from changing the
> interface to return the (possibly synthesized) time of day to the
> portable ntp code from timeval / microsecond resolution to timespec /
> nanosecond resolution. The interpolation calculates the time
> internally using Win32 units of 100 ns, so-called hectonanoseconds,
> but without my patch always rounds off the tenths-of-a-microsecond
> component before returning it to the portable ntpd code. That allowed
> one machine I tested on to go from precision=-20 to -21, which is an
> exponent of 2, so from about a microsecond to about 500 nanoseconds.
> Additionally the interpolation scheme is marginally improved by
> filtering outlying samples of time/counter correlations. The biggest
> downside is the patched binaries are chatty to the eventlog/ntp.log,
> particularly about the filtering. I encourage anyone using ntpd on
> windows to give them a whirl and report back.
>
> Cheers,
> Dave Hart
Dave,
Interesting, short-term I may look at that as a solution. I don't
necessarily need to feed a single pin to multiple computers. Only one
of the Windows machines is critical, I could sync off that if I needed
to.
While I only have Windows 2003 DDK installed at the moment, they do
include a complete serial device driver source project.
I've only done very minor Windows driver programming, but I may try to
download the newest DDK and give it a whirl.
// This bit is the delta data carrier detect. It is used to indicate
// that the data carrier bit (in this register) has *changed*
// since this register was last read by the CPU.
//
#define SERIAL_MSR_DDCD 0x08
and
if (ModemStatus & (SERIAL_MSR_DCTS |
SERIAL_MSR_DDSR |
SERIAL_MSR_TERI |
SERIAL_MSR_DDCD)) {
I think the change would/could be done in modmflow.c or isr.c, but I'd
really have to do some reading to get comfortable with driver
programming. I'm not really sure how'd I'd signal an event to the ATOM
driver (perhaps through DeviceIoCtrl?)
Re: [ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
Uwe, Uwe Klein wrote: >>>If ntpd is restarted, it is Bad for the time to be stepped backwards for >>>many people. Since this could happen with -g, when restarting ntpd for >>>this common case, one should not use -g. > > If you step forward the system effect will be comparable to "limbo" > nothing has happened for an interval. we can live with that. > ( Though cron,batch,at may stumble ) > > If you step backward in time you are in danger of running into > future timestamps. > > Think of a make in progress that sees timestamps for prerequisites > as older than the target file due to the backward timestep. > Unpleasantness ensuess. I'm aware of the problems with stepping time backward, and I agree this should be avoided. The basic thing I don't understand in the context of this thread is why the behaviour with -g should not become the default behaviour for ntpd. What if the big difference if a) ntpd without -g steps the time back by the amount of 128 ms up to the sanity limit of about 1000 seconds b) ntpd with -g steps the time back by the amount of 128 ms up to more than the sanity limit If backward time steps are Bad then also time steps below but maybe close to 1000 seconds are Bad. So there's basically no big difference if you use -g or not. Please remember this all is related to the statement that ntpd should not be re-started (!) with -g, i.e. ntpd has already been running before, and thus the system time has been synchronized before. 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] ntpdate works, but ntpd doesn't (reach = 0)
>> >>If ntpd is restarted, it is Bad for the time to be stepped backwards for >>many people. Since this could happen with -g, when restarting ntpd for >>this common case, one should not use -g. If you step forward the system effect will be comparable to "limbo" nothing has happened for an interval. we can live with that. ( Though cron,batch,at may stumble ) If you step backward in time you are in danger of running into future timestamps. Think of a make in progress that sees timestamps for prerequisites as older than the target file due to the backward timestep. Unpleasantness ensuess. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Problem using ntp autokey with the trusted certificate identity s cheme
Steve Kostecke wrote: > On 2009-02-10, Danny Mayer wrote: >> Steve Kostecke wrote: >> [---=| Quote block shrinked by t-prot: 24 lines snipped |=---] >> server3 does not synchronize with server2 >>> >>> The problem here is that you want to operate _two_ trust groups: >>> >>> server2 trusts serverT1 >>> server3 trusts server2 >>> >>> Server3 needs to be able to trust server2. Try regenerating the >>> paramters on server2 using '-T'. >> >> My understanding from what Dave has said is that the newer versions of >> the development branch supports multiple trust groups. > > You missed the point. The OP has set up a _chain_ of two trust groups. > This is not a problem with one ntpd serving multiple trust groups. > > The server for the second trust group needs to have a trusted cert so > that it will be trused by its client. This is an interesting setup, but should not be very uncommon. Has anyone *tried* to configure autokey so that a machine is a client which uses one certificate for his upstream server, and additionally acts as a server who provides its own certificate to its clients? This setup should also be mentioned in http://support.ntp.org/Support/ConfiguringAutokey 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] ntpdate works, but ntpd doesn't (reach = 0)
Harlan, Harlan Stenn wrote: In article , Martin Burnicki writes: > > Harlan> Because ntpd also gets restarted, and there is a strong belief > that Harlan> -g is bad for a restart and restarts will happen more often > than Harlan> boots. > > Martin> Huh? I'm afraid I don't understand what you mean here. > > The general case is that -g should only be used at startup, when time can > be stepped. > > If ntpd is restarted, it is Bad for the time to be stepped backwards for > many people. Since this could happen with -g, when restarting ntpd for > this common case, one should not use -g. Anyway, I don't understand where the problem with -g is. If the system time has been synchronized better than 128 ms before, by ntpd, ntpdate, sntp or whatever, then ntpd will not step the time when it is (re-)started. If the system time *is* off by more than 128 ms then the system time *will* be stepped by ntpd anyway (maybe unless the -x, no slew option is given), if the time offset is below the sanity limit, even if -g is not given. If stepping the time back is Bad in general then stepping it back by 1000 second with or without -g is as bad as stepping it back by more than 1000 seconds with -g. IMHO if this happens then this is a configuration problem, not an NTP problem. Maybe initial time steps should be allowed by default but inhibited if -x is explicitely given. > From what I can see, it might be an improvement if ntpd had a mode that > said "Stepping forward is OK, but do not step backwards." Agreed. > What I really think is needed is an in-depth study of the various cases, > perhaps with some new timekeeping functions that better implement what is > needed. I think here is a good place to discuss this, maybe in a new thread. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
