On 2014-09-15, Martin Burnicki wrote:
> Phil W Lee wrote:
>> William Unruh considered Sat, 13 Sep 2014 11:56:37
>> + (UTC) the perfect time to write:
>>
>>> On 2014-09-12, Martin Burnicki wrote:
William Unruh wrote:
> No idea why a fudge parameter would be complicated. If you wanted
William Unruh wrote:
On 2014-09-12, Martin Burnicki wrote:
William Unruh wrote:
No idea why a fudge parameter would be complicated. If you wanted to use
ntpd itself to figure out the assymmetry, that could well be
complicated. But if it is a fixed offset, I cannot see how that would be
complic
Rob schrieb:
Paul wrote:
On Fri, Sep 12, 2014 at 4:03 AM, Martin Burnicki
wrote:
+1
However, path asymmetry includes
I think you're abusing the conventional notion of asymmetric latency.
Uncorrected bandwidth asymmetry will result in offsets between
truechimers. Offsets between clocks th
Phil W Lee wrote:
William Unruh considered Sat, 13 Sep 2014 11:56:37
+ (UTC) the perfect time to write:
On 2014-09-12, Martin Burnicki wrote:
William Unruh wrote:
No idea why a fudge parameter would be complicated. If you wanted to use
ntpd itself to figure out the assymmetry, that coul
On Sat, Sep 13, 2014 at 1:46 AM, Rich Wales wrote:
> Any thoughts?
Something is wrong with your home machine but there's nothing you can
do with stock NTP to fix your offset.
As posted earlier I see exactly the same ~2ms offset. However as
noted -- given that you're on the same network -- these
On 2014-09-12, Martin Burnicki wrote:
> William Unruh wrote:
>> No idea why a fudge parameter would be complicated. If you wanted to use
>> ntpd itself to figure out the assymmetry, that could well be
>> complicated. But if it is a fixed offset, I cannot see how that would be
>> complicated and it
Le 13 sept. 2014 à 07:46, Rich Wales a écrit :
> Replying to Charles Elliott:
>
>> The offset may be a function of distance. Try this experiment:
>> Set up your ntp.conf file to have three servers . . . :
>> 1. A relatively unused stratum 1 or 2 server as close to you as possible
>> 2. A rela
Le 13 sept. 2014 à 07:46, Rich Wales a écrit :
>
>
> -68.65.164.12.PPS.1 u 13 16 3728.168 -2.126 4.585
>
> -171.67.203.16 204.63.224.702 u2 16 3339.6892.146 3.930
>
> Any thoughts?
>
I should have added
netstat -i
are you dropping p
Replying to Charles Elliott:
> The offset may be a function of distance. Try this experiment:
> Set up your ntp.conf file to have three servers . . . :
> 1. A relatively unused stratum 1 or 2 server as close to you as possible
> 2. A relatively unused stratum 1 or 2 server about 1,000 miles awa
On Fri, Sep 12, 2014 at 11:48 AM, Rob wrote:
> No, not link-speed asymmetry but propagation-time asymmetry
Sure, you can say that after the fact. Only one other person in this
conversation *particularly, not the OP* meant that. As I said "the
conventional notion of asymmetric latency". It's no
Paul wrote:
> On Fri, Sep 12, 2014 at 4:03 AM, Martin Burnicki
> wrote:
>> +1
>>
>> However, path asymmetry includes
>
>
> I think you're abusing the conventional notion of asymmetric latency.
> Uncorrected bandwidth asymmetry will result in offsets between
> truechimers. Offsets between clocks
On Thu, Sep 11, 2014 at 3:50 PM, mike cook wrote:
> Yup, AsymmetricDSL does have different up/down bit rates. What I really
> meant was that the difference would not explain his issue.
> ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around 40usec
> to 300usec transfer of a 48
On Fri, Sep 12, 2014 at 4:03 AM, Martin Burnicki
wrote:
> +1
>
> However, path asymmetry includes
I think you're abusing the conventional notion of asymmetric latency.
Uncorrected bandwidth asymmetry will result in offsets between
truechimers. Offsets between clocks that we hope are truechimers
Terje Mathisen wrote:
> Rob wrote:
>> Martin Burnicki wrote:
>>> Rob wrote:
Martin Burnicki wrote:
When you serve thousands of clients, this tends to overflow the NAT
table or stress the lookup code so much that it overloads the CPU.
>>>
>>> Haven't had such case, yet since my hom
Rob wrote:
Martin Burnicki wrote:
Rob wrote:
Martin Burnicki wrote:
When you serve thousands of clients, this tends to overflow the NAT
table or stress the lookup code so much that it overloads the CPU.
Haven't had such case, yet since my home NTP server doesn't serv 1000s
of clients, but s
Martin Burnicki wrote:
> Rob wrote:
>> Martin Burnicki wrote:
>>> - NAT doesn't hurt at all, unless you are trying to use NTP's authentication
>>
>> NAT in itself does not hurt, but when you want to be a timeserver for
>> a large number of clients, it can be a problem.
>>
>> Many home routers hav
Rob wrote:
Martin Burnicki wrote:
- NAT doesn't hurt at all, unless you are trying to use NTP's authentication
NAT in itself does not hurt, but when you want to be a timeserver for
a large number of clients, it can be a problem.
Many home routers have no "static NAT" but only "portforwarding
Rob wrote:
An offset between two GPS synced servers by definition means path asymmetry.
+1
However, path asymmetry includes
- systematic asymmetry (e.g. ADSL) on one ore more (!) parts of the path
between 2 nodes
- errors due to different link speeds, e.g 100 MBit from 1 switch port
to on
Martin Burnicki wrote:
> - NAT doesn't hurt at all, unless you are trying to use NTP's authentication
NAT in itself does not hurt, but when you want to be a timeserver for
a large number of clients, it can be a problem.
Many home routers have no "static NAT" but only "portforwarding" which
creat
William Unruh wrote:
No idea why a fudge parameter would be complicated. If you wanted to use
ntpd itself to figure out the assymmetry, that could well be
complicated. But if it is a fixed offset, I cannot see how that would be
complicated and it ihas already been implimented in the refclock case
Harlan Stenn wrote:
There are a bunch of issues here, and I don't think there is a simple
answer.
For starters, there is static asymmetry and dynamic asymmetry.
One of the core issues is that NTP is frequently multihop, and the
routing for at least some of these connections can spontaneously ch
On Thu, 11 Sep 2014 21:09:46 +, Rob wrote:
> Paul wrote:
>> On Thu, Sep 11, 2014 at 2:29 PM, William Unruh wrote:
>>> I doubt that NAT would add much assymetry
>>
>> NAT is symmetric. Otherwise it wouldn't work. But I don't see how
>> that's part of anything at hand.
>
> I never claimed i
mike cook wrote:
Le 11 sept. 2014 à 21:08, Paul a écrit :
On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote:
Did I miss something?
On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote:
My home LAN is connected to my school's network via a cable modem.
If we make the (safe) assumption of a com
David Woolley wrote:
> On 11/09/14 22:11, Rob wrote:
>> mike cook wrote:
>>>
>>> Le 11 sept. 2014 à 21:08, Paul a écrit :
>>>
On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote:
> Did I miss something?
On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote:
> My home LAN is con
On 11/09/14 22:11, Rob wrote:
mike cook wrote:
Le 11 sept. 2014 à 21:08, Paul a écrit :
On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote:
Did I miss something?
On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote:
My home LAN is connected to my school's network via a cable modem.
If we
There are a bunch of issues here, and I don't think there is a simple
answer.
For starters, there is static asymmetry and dynamic asymmetry.
One of the core issues is that NTP is frequently multihop, and the
routing for at least some of these connections can spontaneously change.
Declaring an as
mike cook wrote:
>
> Le 11 sept. 2014 à 18:48, Rob a écrit :
>
>> Paul wrote:
>>> As an aside has anyone tried shaping traffic to make the
>>> upstream/downstream latencies similar? It would seem more efficient
>>> to apply network solutions to network problems if possible.
>>
>> That does not
mike cook wrote:
>
> Le 11 sept. 2014 à 21:08, Paul a écrit :
>
>> On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote:
>>> Did I miss something?
>>
>> On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote:
>>> My home LAN is connected to my school's network via a cable modem.
>>
>> If we make the (s
Paul wrote:
> On Thu, Sep 11, 2014 at 2:29 PM, William Unruh wrote:
>> I doubt that NAT would add much assymetry
>
> NAT is symmetric. Otherwise it wouldn't work. But I don't see how
> that's part of anything at hand.
I never claimed it is part of the asymmetry, I only mentioned it because
usu
To: Questions List
> Subject: Re: [ntp:questions] Compensating for asymmetric delay on a
> per-peer/server basis?
>
>
> Le 11 sept. 2014 à 18:48, Rob a écrit :
>
> > Paul wrote:
> >> As an aside has anyone tried shaping traffic to make the
> >> upstream
Le 11 sept. 2014 à 21:08, Paul a écrit :
> On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote:
>> Did I miss something?
>
> On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote:
>> My home LAN is connected to my school's network via a cable modem.
>
> If we make the (safe) assumption of a common c
On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote:
> Did I miss something?
On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote:
> My home LAN is connected to my school's network via a cable modem.
If we make the (safe) assumption of a common cable ISP/FiOS in the
Palo Alto area the path is asymme
> Did I miss something? The OP did not offer any evidence that there was
> path asymmetry, just that there was an unexplained offset between two
> GPS sync'd servers.
The asymmetry in this case is being caused by the characteristics of the
cable modem that connects my residence with the campus net
On Thu, Sep 11, 2014 at 2:29 PM, William Unruh wrote:
> I doubt that NAT would add much assymetry
NAT is symmetric. Otherwise it wouldn't work. But I don't see how
that's part of anything at hand.
And yes the A in ADSL stands for Asymmetric. If you see the word
"home" in reference to a link in
On 2014-09-11, mike cook wrote:
>
> Le 11 sept. 2014 ? 18:48, Rob a ?crit :
>
>> Paul wrote:
>>> As an aside has anyone tried shaping traffic to make the
>>> upstream/downstream latencies similar? It would seem more efficient
>>> to apply network solutions to network problems if possible.
>>
>>
On 2014-09-11, Rob wrote:
> Martin Burnicki wrote:
>> This is also what Rob has mentioned in another post of this thread, and
>> I agree with Rob that a one approach could be to specify (and configure
>> for ntpd) the systematic error due to asymmetry of your internet connection.
>>
>> However,
Le 11 sept. 2014 à 18:48, Rob a écrit :
> Paul wrote:
>> As an aside has anyone tried shaping traffic to make the
>> upstream/downstream latencies similar? It would seem more efficient
>> to apply network solutions to network problems if possible.
>
> That does not work. The asymmetry is not
On Thu, Sep 11, 2014 at 12:48 PM, Rob wrote:
> That does not work. The asymmetry is not caused by traffic but by
> modem parameters.
The asymmetry is caused by asymmetric latency which is caused (for our
purposes) by asymmetric line speeds. Traffic shaping can change
various things (depending o
Paul wrote:
> As an aside has anyone tried shaping traffic to make the
> upstream/downstream latencies similar? It would seem more efficient
> to apply network solutions to network problems if possible.
That does not work. The asymmetry is not caused by traffic but by
modem parameters.
___
Paul wrote:
> Not to suggest that someone is doing something unreasonable but again
> why does time derived from the back-up clock need to be as accurate as
> the local clock (say .5ms versus 2ms)? If there's a legitimate need
> then trying to solve the problem with the wrong tool will only lead
On Tue, Sep 9, 2014 at 6:58 PM, Harlan Stenn 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.
I
On 2014-09-11, Martin Burnicki wrote:
> William Unruh wrote:
>> 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.
>
> The case mentioned by the original poster is just one possible reason.
>
> If you have a GPS controlled NTP
Martin Burnicki wrote:
> This is also what Rob has mentioned in another post of this thread, and
> I agree with Rob that a one approach could be to specify (and configure
> for ntpd) the systematic error due to asymmetry of your internet connection.
>
> However, this can also be pretty tricky if
Rob wrote:
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 se
William Unruh wrote:
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.
The case mentioned by the original poster is just one possible reason.
If you have a GPS controlled NTP server at home, and a fast internet
connection, a
On 2014-09-09, Harlan Stenn 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
questions@lists.ntp.org
> Subject: Re: [ntp:questions] Compensating for asymmetric delay on a
> per-peer/server basis?
>
> Rich Wales wrote:
> > Replying to "Rob":
> >
> >> Yes, you can use: fudge 1.2.3.4 time1 -0.002 or similar.
> >> see the
Rich Wales 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
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
On Tue, Sep 9, 2014 at 5:11 PM, Rich Wales wrote:
> I checked the manual before asking my question
Good start, so many don't -- even years later.
I might point you at The Huff-n'-Puff Filter but perhaps you could
explain your concern. An error in the small millisecond range is
often considered
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, t
Rich Wales wrote:
> Is there a way to compensate for asymmetric delay to/from one specific
> peer or server?
>
> My home LAN is connected to my school's network via a cable modem.
> There appears to be a consistent asymmetry of 2-3 msec between my home
> and the school's network. I can see this b
Is there a way to compensate for asymmetric delay to/from one specific
peer or server?
My home LAN is connected to my school's network via a cable modem.
There appears to be a consistent asymmetry of 2-3 msec between my home
and the school's network. I can see this by comparing the time on
my hom
53 matches
Mail list logo
