Re: [ntp:questions] Garmin 18 LVC: whether to fudge
"Richard B. Gilbert" writes: >shane-dated-1234940...@csy.ca wrote: >> 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 >> >My bet would be that there is an asymmetry in your ADSL link! If I'm >not mistaken, the "A" in ADSL stands for asymmetric! Your GPS PPS >output is probably within 50 nanoseconds of the exact time! The process >of getting that signal into your computer is going degrade the accuracy >by an amount that is somewhere between difficult and impossible to measure. No, it is not. Put out a signal on one of the parallel port pins, and run that into the whatever you use for the PPS input. read the system time when you turn on the parallel pin and when the interrupt is read on the PPS input. Subtract. On my system this is from 1-3usec, most usually 1. Note that this is measuring the time required to switch on the parallel pin as well as getting the input from the PPS pin, so it overestimates the error. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
shane-dated-1234940...@csy.ca writes: >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. Sorry, where is that 1.7-1.9ms? I see a difference of .7ms, which, given the 11 ms delay is pretty good. >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? If there is a 2ms delay is processing the interrupt, throw away your system and buy a new one. It is severely damaged. ___ 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?
n...@tla.org (John Ioannidis) writes: >The problem setup: two locations, both within the United States, neither >has roof access so no GPS reception is possible. How do you synchronize What about window access? And since you have money, I am sure that your building does have a roof. Stick a cheap computer near the roof and run a GPS18 onto the roof and a cable down to that computer. (Nota that you can extend the line beyond the 5M that the GPS18 comes with -- to get really best results with an amplifier and matched lines, and run the wires down to the computers. Ie, set up fast amps connected with cat 5 cable and 100ohm termnation on each end. >them with better than 50-microsecond accuracy? Straight NTP over the >Internet doesn't do the trick. They don't need to actually be Sure it does. have one of them as a client of the other and on a local ethernet you should be able to get 50usec agreement. >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). Is running a single Cat5 to the roof 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] Very rapid polling
ma...@ntp.org (Danny Mayer) writes: >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. While it may be abuse by the developer, it is not abuse by the user. >Danny ___ 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: >> >>> 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.. Just what do you have in mind? It seems that what you describe is exactly a methodology for coping with such incidents. Or are you going to drive around with a gun and shoot the president of D-Link say? >With the ever increasing use of the internet, the problems are only >going to get worse! Yes. And with the increasing population of the earth "problems are only going to get worse" as well. ___ 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 writes: 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. The sanity check is whether or not the clock it too far off. When ntp is started it is expected that the clock is way off, and that the sanity check becomes an insanity check. Ie, if the system behaves badly in situations where everything is behaving as expected, then that is not a useful sanity check. ___ 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)
Martin Burnicki wrote: > Why shouldn't ntpd be run e.g. on a laptop? [...] > And surely this results in the question which has been discussed here > several times: why does it takes so long for ntpd to adjust an > initial tiny offset of a few milliseconds? In my understanding, ntpd was designed as a tool to discipline clocks of systems that need (or need to provide) very accurate time, and not as a general-purpose clock-setting tool. The requirements that would mandate the use of full-blown ntpd are mainly found on systems that stay up and connected for long stretches of time (time servers, measurement and monitoring systems, loghosts, file servers, etc.). There may well be examples of laptop use cases that require full-blown ntpd and where periodic setting using sntp is unacceptable, but I think they are rare. For this reason, I also think that shortening the time it takes ntpd to do its initial adjustment is not very relevant to its (presumed) design goals. N ___ 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
>>> In article , Martin Burnicki >>> writes: Martin> So it looks like you really have to wait until the current developer Martin> version becomes the next release version, unless you can co with the Martin> -dev version. -dev has been in feature freeze for a while. It is 1 or 2 (known) bugfixes away from 4.2.6-RC1. I think the current -dev is at least as good as -stable. -- 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] Problem using ntp autokey with the trusted certificate identity s cheme
>>> In article <49931384.4010...@udel.edu>, mi...@udel.edu (David Mills) writes: David> Martin, The release version is currently maintained on a separate David> track, so it might not happen that the next release version would be David> the current development version. I don't like this, but I don't David> maintain the release version and there might be mitigating factors I David> am not aware of. ntp-dev will become 4.2.6 (-stable) as soon as I can invest the effort to integrate and test the final blocking bug. There is no "additional track" for -dev. -- 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] Garmin 18 LVC: whether to fudge
>>> In article , Terje Mathisen >>> <"terje.mathisen at tmsw.no"> writes: Terje> I have wished for fudge time1 on network clocks for many years now, Terje> but I have realized that it will never happen unless I go in and Terje> write the code myself. https://support.ntp.org/bin/view/Dev/NewNtpConfFormat is the place to add this and any other ideas for improving the format and/or content of the configuration file. -- 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] Very rapid polling
On Tue, 10 Feb 2009 23:38:07 -0500, "Richard B. Gilbert" wrote for the entire planet to see: >Danny Mayer wrote: >> Eric wrote: > >>> 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. Not really. If it's really a DDoS attempt the source address won't belong to an NTP server and the packet will be discarded, sooner or later. It's value is just to clog the pipes. And anyway, there seems to be a general consensus that sending the wrong time is wrong. Just don't send it, or simply mark it invalid or KOD or all zeros, or all three. No need to attempt to confound the "requester". ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
Kevin Oberman wrote: > Also, the jitter on your time is extremely high for PPS which should be > < 1 us. I suspect that this is a system problem, but I can't be sure. I > never see this much jitter on any of our PPS synced reference clocks (of > which we have about 25 scattered across the US). If the jitter on any of > my reference clocks using PPS exceeds .005, I consider this a big > problem. I use FreeBSD which has excellent PPS support. I have setup a bunch of FreeBSD based refclocks over the years, mostly Oncore UT+ timing receivers (15-50 ns) but also Gar 18LVC as well as an Endrun CDMA-based clock in the US. I just got my homebuilt 18LVC back in operation today, after moving to a new office building: I use this the monitor all my official refclocks by configuring them as servers to my local box, so I can compare with the GPS results. Since the Garmin isn't a timing-optimized receiver, I cannot put it in Zero-D like the Oncores, and it has a less than optimal window sill location (pointing NE in Oslo, at 60N), but I'm still getting offset mostly around +/- 2-3 us, and sub-5 us jitter. Terje PS. I had lost my original documentation on how to setup a server with this GPS, but a little Googling found lots of howto, including some that quoted my old description. :-) -- - "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] NTP over redundant peer links, undetected loops
Stefan Schimanski wrote: > 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 I did quite a bit of work while setting up a big corporate network, with dual servers, one of which had a Motorola Oncore UT+, in each of three geographically distributed locations. I had similar plans like you, wanting to setup two or three layers of servers, but then I realized that this was totally superfluous! We had less than 40K server and client machines worldwide, so even if every single one of them configured all 6 primary servers, the resulting load would be negligible, the timing results would be optimal, and so would the redundancy level. The icing on the cake is that I don't need to consider where a client machine is located, I simply tell everyone to use exactly the same configuration file, with one exception: The core/root DNS servers (as well as DHCP servers and some other network gear) use the same six servers, but they use the IP addresses directly instead of the DNS names. Terje -- - "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] Garmin 18 LVC: whether to fudge
Brian Utterback wrote: > Decreased bandwidth means increased latency. The two are related. Only indirectly so. There are at least two components to the higher latency on the ADSL uplink as compared to the downlink. A minor component is the fact that the lower bitrate means that equal-sized packets are in flight longer on the uplink than they are on the downlink. The main component is however that there is a transmit queue in the CPE that packets take a while to get through before actually being sent up the link, particularly under load. So this component is not only dominant, it is also variable with upstream load. One way to get around that is to set up multiple transmit queues for different flows, perhaps based on TOS marking. This way, NTP packets, when suitably marked, can be made to bypass the transmit queue for best-effort traffic. Cheers, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
shane-dated-1234940...@csy.ca wrote: >> Chris Adams wrote: >>> Once upon a time, Richard B. Gilbert said: My bet would be that there is an asymmetry in your ADSL link! If I'm not mistaken, the "A" in ADSL stands for asymmetric! >>> The asymmetry in ADSL is in bandwidth, not path or latency. More >>> frequency space is used for downstream (ISP->end user) communication >>> than for upstream, but both travel the same path. > > Yeah, figured it was either interrupt latency or ADSL but thought ntpd might > be able to factor the ADSL link out of the offset. Is there any way I can > do this manually? As far as I could tell, fudge time1 only works for a > refclock driver and not an internet server. You are absolutely correct! :-) I have wished for fudge time1 on network clocks for many years now, but I have realized that it will never happen unless I go in and write the code myself. I know that Dave Mills prefers other solutions, in particular the huff-puff code which handles variable network congestion but cannot deal with a systematic/constant offset between send and receive paths. Terje -- - "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] Garmin 18 LVC: whether to fudge
Richard B. Gilbert wrote: > The difference in bandwidth would mean that a packet of N bytes would > take more time in one direction than the other! I don't know if that > would be sufficient to account for the observed behavior but I can't > think of another explanation. There is more to it. look up "fastpath adls". throughput and latency are coupled in funny _and_ variable ways for *DSL . My DSL provider recently tested variable connection setups where allocated bandwidth for upstream and downstream traffic (and the summ of both) is optimised for max throughput ( depending on the copper line utilisation, the weather and how much money I have in the bank ;-). Retraining happens on a regular basis. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
Brian Utterback wrote: > Chris Adams wrote: > >> The asymmetry in ADSL is in bandwidth, not path or latency. More >> frequency space is used for downstream (ISP->end user) communication >> than for upstream, but both travel the same path. > > Decreased bandwidth means increased latency. The two are related. > > Brian Utterback Thanks Brian. You said it more succinctly than I could! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
On 2009-02-11, shane-dated-1234940...@csy.ca wrote: > 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 377 0.000 -0.448 0.189 > +bigben.cac.wash .USNO. 1 u 34 1024 377 11.134 0.283 2.645 The offset difference in your _snapshot_ is only 0.731 milliseconds. If you wich to calculate a correction value you need to look at the statistics over the long term. Enable statistics collection, let ntpd run for a few days, and use the peer.awk script from the ./scripts directory of the NTP Reference Implementation Distribution to summarize your peerstats file. -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
Chris Adams wrote: > Once upon a time, Richard B. Gilbert said: >> My bet would be that there is an asymmetry in your ADSL link! If I'm >> not mistaken, the "A" in ADSL stands for asymmetric! > > The asymmetry in ADSL is in bandwidth, not path or latency. More > frequency space is used for downstream (ISP->end user) communication > than for upstream, but both travel the same path. > > There may be asymmetric routing going on (very often the case when you > talk to a host across the Internet, especially if either your ISP or the > remote host's ISP are multihomed), but it is highly unlikely it is > happening between the end user and his own ISP. > The difference in bandwidth would mean that a packet of N bytes would take more time in one direction than the other! I don't know if that would be sufficient to account for the observed behavior but I can't think of another explanation. ___ 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, The release version is currently maintained on a separate track, so it might not happen that the next release version would be the current development version. I don't like this, but I don't maintain the release version and there might be mitigating factors I am not aware of. Dave Martin Burnicki wrote: >Dave, > >David Mills wrote: > > >>Martin, >> >>Yes, this scenario is included in the online documentation. >> >> > >So this will be available with the next release version. > >Thanks for the update. > >Martin > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
> From: cmad...@hiwaay.net (Chris Adams) > Date: Wed, 11 Feb 2009 08:26:39 -0600 > Sender: questions-bounces+oberman=es@lists.ntp.org > > Once upon a time, Richard B. Gilbert said: > >My bet would be that there is an asymmetry in your ADSL link! If I'm > >not mistaken, the "A" in ADSL stands for asymmetric! > > The asymmetry in ADSL is in bandwidth, not path or latency. More > frequency space is used for downstream (ISP->end user) communication > than for upstream, but both travel the same path. Depending on the difference in bandwidth, that does impact latency. ntp assumes that the time from message transmission to message receipt is the same in both directions. If the packet takes longer on the wire, that is an asymmetric latency. Also, the jitter on your time is extremely high for PPS which should be < 1 us. I suspect that this is a system problem, but I can't be sure. I never see this much jitter on any of our PPS synced reference clocks (of which we have about 25 scattered across the US). If the jitter on any of my reference clocks using PPS exceeds .005, I consider this a big problem. I use FreeBSD which has excellent PPS support. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
>Chris Adams wrote: >> Once upon a time, Richard B. Gilbert said: >>>My bet would be that there is an asymmetry in your ADSL link! If I'm >>>not mistaken, the "A" in ADSL stands for asymmetric! >> >> The asymmetry in ADSL is in bandwidth, not path or latency. More >> frequency space is used for downstream (ISP->end user) communication >> than for upstream, but both travel the same path. Yeah, figured it was either interrupt latency or ADSL but thought ntpd might be able to factor the ADSL link out of the offset. Is there any way I can do this manually? As far as I could tell, fudge time1 only works for a refclock driver and not an internet server. Best, Shane ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
Chris Adams wrote: > Once upon a time, Richard B. Gilbert said: >>My bet would be that there is an asymmetry in your ADSL link! If I'm >>not mistaken, the "A" in ADSL stands for asymmetric! > > The asymmetry in ADSL is in bandwidth, not path or latency. More > frequency space is used for downstream (ISP->end user) communication > than for upstream, but both travel the same path. > > There may be asymmetric routing going on (very often the case when you > talk to a host across the Internet, especially if either your ISP or the > remote host's ISP are multihomed), but it is highly unlikely it is > happening between the end user and his own ISP. Of course it makes a difference whether the link speeds in both directions are the same, or not. If my ntpd polls an upstream server across my ADSL link there is an offset of a few milliseconds. If the route goes via a SDSL link then the offset is below 1 ms. We have observed it even makes a difference of a few microseconds if one NTP server uses a 10 MBit link and the other one a 100 MBit link, and both are connected via a dual speed switch. 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] Problem using ntp autokey with the trusted ce rtificate identity s cheme
Alain, Bartholome, Alain wrote: > 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... So it looks like you really have to wait until the current developer version becomes the next release version, unless you can co with the -dev version. 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] Garmin 18 LVC: whether to fudge
Chris Adams wrote: > The asymmetry in ADSL is in bandwidth, not path or latency. More > frequency space is used for downstream (ISP->end user) communication > than for upstream, but both travel the same path. Decreased bandwidth means increased latency. The two are related. Brian Utterback ___ 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
Dave, David Mills wrote: > Martin, > > Yes, this scenario is included in the online documentation. So this will be available with the next release version. Thanks for the update. 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] Garmin 18 LVC: whether to fudge
Once upon a time, Richard B. Gilbert said: >My bet would be that there is an asymmetry in your ADSL link! If I'm >not mistaken, the "A" in ADSL stands for asymmetric! The asymmetry in ADSL is in bandwidth, not path or latency. More frequency space is used for downstream (ISP->end user) communication than for upstream, but both travel the same path. There may be asymmetric routing going on (very often the case when you talk to a host across the Internet, especially if either your ISP or the remote host's ISP are multihomed), but it is highly unlikely it is happening between the end user and his own ISP. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ 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)
Martin Burnicki wrote: > Harlan Stenn wrote: > 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. > > Or in other words, the question is whether that sanity check makes sense > right after startup. > > Martin "Quisnam igitur sanus?" Horace That translates to "Who then is sane?" If NTPD queries four or more servers and gets responses that more or less agree then I think NTPD would be justified in setting the clock to its best estimate. It's still going to take somewhere between thirty minutes and ten hours before NTPD can be reasonably certain that it does have the time correct to within, say, fifty microseconds. If you want -g it's easy enough to get it without making it the default for everyone. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin 18 LVC: whether to fudge
shane-dated-1234940...@csy.ca wrote: > 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 > My bet would be that there is an asymmetry in your ADSL link! If I'm not mistaken, the "A" in ADSL stands for asymmetric! Your GPS PPS output is probably within 50 nanoseconds of the exact time! The process of getting that signal into your computer is going degrade the accuracy by an amount that is somewhere between difficult and impossible to measure. ___ 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 ;-) > > 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... Why shouldn't ntpd be run e.g. on a laptop? If it does run then it synchronizes the system time when network connection is available, and can still compensate the native clock drift if the laptop is offline. Of course synchronization will be better if ntpd reaches an upstream server continuously, but still this is better than no synchronization at all ... And surely this results in the question which has been discussed here several times: why does it takes so long for ntpd to adjust an initial tiny offset of a few milliseconds? 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)
Danny Mayer wrote: > 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. This is only supported kind of reasonably since 4.2.4p5. In earlier versions it may have taken very long time after an interface has appeared until ntpd re-tried to use it and mobilize associations. So there's no wonder why the Linux distributors tried to implement some workarounds (e.g. control ntpd from ifup/ifdown) to speed things up. There are *not* only servers running 24/7 which use NTP. 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)
Hi, Danny, Danny Mayer wrote: > > 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. How is that effected? > > Danny SuSE 10.3 ( and previous: restarts ntp on IF change ): xntp-4.2.4p3 SuSE 11.0 ( installed but don't have access to it at the moment): ntp-4.2.4p4 SuSE 11.1 ( published a couple of weeks ago, not used yet ): ntp-4.2.4p5 ___ 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: > > 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. Or in other words, the question is whether that sanity check makes sense right after startup. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
