[ntp:questions] NTP tunning for OWD measurements

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Sat Oct 27 21:48:45 UTC 2012


pret3nder at gmail.com wrote:
> Yes, circuit switched networks don't have this problem,
> for sure.
> If, for example, having a GPS on S1, and using it as a
> timeserver for X1, and considering the incoming and outgoing
> delay on that path are equal, when measuring the OWD
> between S1 and X1, I would get a measurement with an accuracy
> equal to the offset reported by NTP, right?

No, you would get zero accuracy on a measurement of zero (i.e. equal 
delays both ways).

Terje
>
>
> On Saturday, October 27, 2012 7:34:46 PM UTC+1, unruh wrote:
>> On 2012-10-27, pret3nder at gmail.com <pret3nder at gmail.com> wrote:
>>
>>> The accuracy requirement is not written on stone,
>>
>>> but <1ms would be the goal we're aiming for.
>>
>>>
>>
>>> I think you made some confusions on the units
>>
>>> there (usec and sec, when I think those are in ms),
>>
>>
>>
>> usec and msec I should have said.
>>
>>
>>
>>> but I got your point. The way NTP works, it estimates
>>
>>> the one-way delays as RTT/2 and uses that to correct
>>
>>> the computer clock to UTC. So, without having an external
>>
>>
>>
>> Yes.
>>
>>
>>
>>> source on both ends that can correct the computer
>>
>>> clock with a delay <1ms, I can't get that accuracy, right?
>>
>>
>>
>> Yes. All you can say is that it lies between all of the delay being on
>>
>> the outgoing trip and all the delay on the ingoing. Now, I agree that is
>>
>> unlikely, but certainly if say the outgoing delay is .6 of the total
>>
>> delay and the ingoing is .4, you could not tell that. For example the
>>
>> outgoing path could go through different routers, switches etc, than the
>>
>> ingoing path. Eg, Toronto to Vancouver could go through Dallas while
>>
>> Vancouver to Toronto could go through chicago instead.  (and the
>>
>> equivalent for shorter hops). Each packet is independent and is routed
>>
>> independently of any prior packets passing either way. The internet is
>>
>> set up to handle each packet independently on purpose to increase fault
>>
>> tolerance. An internet connection does not establish a permanant two way
>>
>> link between machine as old telephone calls did.
>>
>>
>>
>>
>>
>>>
>>
>>>
>>
>>> On Saturday, October 27, 2012 6:15:30 PM UTC+1, unruh wrote:
>>
>>>> On 2012-10-27, pret3nder at gmail.com <pret3nder at gmail.com> wrote:
>>
>>>>
>>
>>>>> OWAMP can refer to One-Way Active Measurement Protocol,
>>
>>>>
>>
>>>>> see http://tools.ietf.org/html/rfc4656, or the tool that follows
>>
>>>>
>>
>>>>> that protocol to measure one-way delay,
>>
>>>>
>>
>>>>> see http://www.internet2.edu/performance/owamp/
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> NREN, as stated before, means National Research and Education Network.
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> @unruh: yes, I was talking in the range of microseconds,
>>
>>>>
>>
>>>>> not single microsecond accuracy!
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>> Then why do you not say WHAT your accuracy requirement is? You still
>>
>>>>
>>
>>>> have not done so.
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>> This is the current output of ntpq -p on X1 server:
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> [alias at x1 ntp]# ntpq -p
>>
>>>>
>>
>>>>>       remote           refid      st t when poll reach   delay   offset  jitter
>>
>>>>
>>
>>>>> =============================================
>>
>>>>
>>
>>>>> *time01.nren.pt  .DCFa.           1 u    7   16  377    5.661    0.021   0.015
>>
>>>>
>>
>>>>>   time02.nren.pt  .DCFa.           1 u    6   16  377    1.240    0.078   0.026
>>
>>>>
>>
>>>>>   time04.nren.pt  .DCFa.           1 u    2   16  377    2.324    0.102   0.009
>>
>>>>
>>
>>>>>   time03.nren.pt  .DCFa.           1 u    -   16  377    8.757    0.109   0.011
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> If the delay, offset and jitter values are shown in milliseconds,
>>
>>>>
>>
>>>>> I am led to believe X1 currently has an offset to time01 stratum
>>
>>>>
>>
>>>>> 1 server of 21 microseconds, right? If S1 has the same offset,
>>
>>>>
>>
>>>>> I can expect a maximum error of 42 microseconds on the owd
>>
>>>>
>>
>>>>> measurements, ignoring the errors caused by the delay asymmetry.
>>
>>>>
>>
>>>>> Is this correct?
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>> No. It means that the current offset -- the difference between the
>>
>>>>
>>
>>>> measurement of the mean time between sent and received-- for time01 is
>>
>>>>
>>
>>>> .021 us. That does NOT mean that your system is withing .021 sec on the
>>
>>>>
>>
>>>> true time. Note that all four of the time01-4 are presumably equivalent
>>
>>>>
>>
>>>> clocks and the scatter for the offset is more like .1ms. The delays are
>>
>>>>
>>
>>>> 5ms, so the best you can say is that the real time lies between +- 2.6ms
>>
>>>>
>>
>>>> since yo uhave no idea what the difference between outgoing and incoming
>>
>>>>
>>
>>>> delay times is. THAT IS WHY YOU NEED GPS ON BOTH ENDS.
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Pedro
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> On Saturday, October 27, 2012 5:19:09 PM UTC+1, Richard B. Gilbert wrote:
>>
>>>>
>>
>>>>>> On 10/26/2012 5:56 PM, pret3nder at gmail.com wrote:
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>> Hi all, and thank you for your answers. I'm afraid I might not have
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>> been clear about my objectives, so I'll try to explain clearer.
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>> I'll also try and keep the lines smaller, and please, excuse me if
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>> I make any mistakes, as english is not my native language.
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>>
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>> This project involves a NREN, which interconnects several institutions.
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> I give up?  WHAT IS "NREN"?????
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> <snip>
>>
>>>
>


-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list