Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Rich Wales ri...@richw.org wrote: Replying to Rob: Yes, you can use: fudge 1.2.3.4 time1 -0.002 or similar. see the manual. This didn't work. And the following error message appeared in my syslog: inappropriate address 10.0.229.163 for the fudge command, line ignored As best I can tell from the online manual, the fudge command is defined only for local reference clocks and has no effect on peers or servers. Ok you are right. In fact I filed bug #2598 myself for a similar situation... In my case I wanted to compensate for the delay asymmetry for external users using my GPS reference via my ADSL line. So I would like to apply such a fudge command to a network interface, not to a peer server. I forgot that it is not even possible to apply it to a server, what you would like to do. I think the only thing you can do is apply an offset to your GPS and live with the fact that you are always 2ms off. At least then you don't have a time wander when you switch to your backup and the external users of your system get the correct time. That is what I did as a workaround until someone fixes this in ntpd. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
You can do it in broadcast mode, but I am not sure it works, or has even been tried on a WAN. Broadcast mode was solid as a rock on my LAN for more than a year, especially after I started using GB Ethernet. I don't use broadcast mode now after switching to using FreeNAS as a time server, it addition to its other duties. Charles Elliott -Original Message- From: questions-bounces+elliott.ch=comcast@lists.ntp.org [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Rob Sent: Wednesday, September 10, 2014 3:34 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis? Rich Wales ri...@richw.org wrote: Replying to Rob: Yes, you can use: fudge 1.2.3.4 time1 -0.002 or similar. see the manual. This didn't work. And the following error message appeared in my syslog: inappropriate address 10.0.229.163 for the fudge command, line ignored As best I can tell from the online manual, the fudge command is defined only for local reference clocks and has no effect on peers or servers. Ok you are right. In fact I filed bug #2598 myself for a similar situation... In my case I wanted to compensate for the delay asymmetry for external users using my GPS reference via my ADSL line. So I would like to apply such a fudge command to a network interface, not to a peer server. I forgot that it is not even possible to apply it to a server, what you would like to do. I think the only thing you can do is apply an offset to your GPS and live with the fact that you are always 2ms off. At least then you don't have a time wander when you switch to your backup and the external users of your system get the correct time. That is what I did as a workaround until someone fixes this in ntpd. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On 2014-09-09, Harlan Stenn st...@ntp.org wrote: The issue is that the huff-n-puff filter will work in the case where a symmetrical delay becomes asymmetric, and it will tolerate or accommodate an asymmetric delay (caused by a large download, for example) for some period of time. This is a case where there is reasonably-understood asymmetry for a given server, or across a given interface. That one is really hard to figure out. Not if you have gps reference at both ends, though why you would not use the gps as the timesource then I do not know. (I guess you could have it only temporarily). May home connections are much slower one way than the other, and an assymmetric delay is very possible. If it really is stable, it would be nice to be able to remove it (like the fudge time1 for refclocks). But I also could not see the equivalent for network clocks. I agree that huff and puff is for temporary assymmetry. There is not way a permanant assymmeter could be detected by ntpd. But if there was a sudden onset, then one could use the free running computer clock to notice that (delta t vs roundtrip would show it). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
