[ntp:questions] NTP tunning for OWD measurements

unruh unruh at invalid.ca
Sat Oct 27 17:25:48 UTC 2012


On 2012-10-27, pret3nder at gmail.com <pret3nder at gmail.com> wrote:
> Gotcha. There's no hidden agenda though, the purpose
> is to replace an old and proprietary system (QoSMetrics) 
> which is being used to measure these OWD's and do monthly 
> reports about the quality of the links being measured.
> QoSMetrics used QTP, a proprietary time protocol.

Then probably the best you can do is, every month, plot the offset vs
delay graphs for ntpd from the Xi to the S1/2, with gps on S1/2 so that
you know that they are within a few usec of UTC. (Surely your advisor
can afford the 100 dollars for those two gps)  You cannot do better
than that. And you do not need any extra protocols  or software for that. 
And it is free, especially as you are already running ntpd for setting
the clocks.

If you want to summarize the graphs into numbers, you could calculate
the mean and standard deviation, and also some statistic to measure the
"wings" on that graph. (eg, look at the standard deviation and the
difference between the mean and the mode for the "wings". But the graph
is far more useful and informative.

>
> So, although that is a good question, and a pertinent one 
> for the matter (how do you measure OWD when the only
> source of timing is over the network you are measuring),
> it is not the core of the project in hands.
>
>
> On Saturday, October 27, 2012 5:46:54 PM UTC+1, David Woolley wrote:
>> pret3nder at gmail.com wrote:
>> 
>> 
>> 
>> 
>> 
>> > David Woolley is right, the project is about making the measurements,
>> 
>> > although I don't like the idea of doing them blindly, without
>> 
>> > knowing how to interpret the results. I won't have time to
>> 
>> > investigate the deeps of NTP, but I do want to know the basics,
>> 
>> > as that's one of the objectives of my thesis.
>> 
>> 
>> 
>> I think you misunderstood my point.  Your project is effectively, how do 
>> 
>>   you measure one way delay when the only source of timing is over the 
>> 
>> network you are studying.  It is not what are the one way delays in the 
>> 
>> particular network you mention.
>> 
>> 
>> 
>> You can only properly do that with a deep understanding of the 
>> 
>> protocols, as you are going to have to look for second order effects 
>> 
>> that may allow you to recover information that wouldn't be recoverable 
>> 
>> if they system only showed first order effects.
>> 
>> 
>> 
>> I don't know the exact context in which the project brief was given, but 
>> 
>> it is even possible that you were expected to realise this yourself.
>



More information about the questions mailing list