[e2e] Accuracy achievable with NTP

[Woojune Kim]

Hi,

Thanks everyone for your information. 

My apologies for my rather lazy question. My original intent was to see what effect the larger delay variances would have on the accuracy presuming that variances correlates with the rough delay (hence my description of 10ms, 100ms etc.), guess it would have saved many people's time if I had stated it more clearly.

So to summarize, it seems while the absolute delay in theory will not effect the accuracy, it usually will as larger delays will usually translate into larger variability in the delay which is the main causes of inaccuracy. Also in today's internet, it would be expected to also lead to larger probability of assymetries in the forward / reverse delays again leading to inaccuracy. 

I guess this means while practically it is impossible in most cases, if we were to setup a symmetric link between an NTP server and client over the internet with guaranteed rates and delay guarantees (maybe something like the EF option in DiffServ with MPLS path engineering) it may be possible to use NTP to accurately synchronize the clocks.  

thanks

Woojune Kim

>-----Original Message-----
>From: Joe Touch [mailto:touch at ISI.EDU]
>Sent: Friday, April 11, 2003 4:39 PM
>To: David P. Reed
>Cc: Saad Biaz; Woojune Kim; end2end-interest at postel.org
>Subject: Re: [e2e] Accuracy achievable with NTP
>
>
>David P. Reed wrote:
>
>> Saad's point is well worth thinking about.   The question is ill
>> formed.  The accuracy of a clock stabilized and synchronized 
>by NTP is
>> in principle relatively independent of the range of delays 
>in the network.
>
>FWIW,
>
>	NTP's accuracy:
>		depends on the variability in the delay,
>		and asymmetries in the forward vs. reverse delay
>
>	NTP time-to-synch:
>		depends on the delay itself
>
>I.e., large RTTs will make it take longer to update the offset, and
>longer to establish the correct rate, but don't per-se have any effect
>on how closely the local clock can be synch'd to the remote clock (how
>correct the rate is).
>
>As David points out, larger RTTs are correllated to higher delay
>variability and asymmetries are, but this needs to be weighed against
>the accuracy of nearby clocks vs. remote (e.g., if nearby are 
>stratum 4,
>and remote is stratum 1...)
>
>Joe
>
>> At 11:53 AM 4/10/2003 -0500, Saad Biaz wrote:
>> 
>>> Woojune:
>>>
>>> It is not the delay RANGE that hinders precise clock 
>synchronization,
>>> it is the UNCERTAINTY on the delay that matters.
>>>
>>> Given a network of hosts, you must MEASURE the UNCERTAINTY 
>on the delay
>>> between all hosts. Then find the diameter D of your network 
>with edges
>>> weighted with the UNCERTAINTY (highest delay - lowest delay).
>>>
>>>
>>> Your worst case imprecision on the clocks will be  1/2 D (Diameter).
>>> Your average imprecision depends on the distribution of the 
>uncertainty.
>>>
>>> For a formal proof, check:
>>>
>>> S. Biaz and Jennifer L. Welch, "Closed form Bounds for Clock
>>> Synchronization under Simple Uncertainty Assumptions".
>>>
>>>
>>>
>>>
>>> On Thu, 10 Apr 2003, Woojune Kim wrote:
>>>
>>> > Hi,
>>> >
>>> > I've been looking for info on how accurate NTP can be. I've looked
>>> in various NTP related sites and still not quite sure.
>>> >
>>> > Say I have a LAN like environment with delays in the 
>range of 10s of
>>> ms. How accurate a time can I get from NTP, assuming I have the
>>> appropriate HW clocks on my host ?
>>> >
>>> > Say I have a corporate network like environment, relatively
>>> segregated from the Internet at large, with delays in the range of
>>> 100ms. How accurate a time can I get ?
>>> >
>>> > Say the delay range goes upto 500ms, how accurate can the 
>time be ?
>>> >
>>> > Any pointers to specific experiments or data would be appreciated.
>>> >
>>> > thanks
>>> >
>>> > Woojune Kim
>>> >
>
>
>
>