On 2012-10-26, pret3n...@gmail.com <pret3n...@gmail.com> wrote:
> I'm sorry, I'm not following you. What delay asymmetry are you refering to?
>
> OWAMP does rely on accurate time stamps, see 
> http://www.internet2.edu/performance/owamp/index.html
>
> If I have S1 and X1 synching to the same time reference (in this case,
> the same stratum 1 server), and I do one-way delay tests between S1 and X1,
> I'm expecting to find a valid measurement of the one-way delay, no?

No. Because S1 and X1 synching to the same time reference suffer one way
delays which alter their time from the "true (UTC) time" defined as
simultinaity on the surface of the earth. Let us say it takes X1 1
second to send a signal to the server, and gets back an answer in 1 ns.
Its time will then be .5 sec late of true time. Let us say that there is
no one way assymetry between S1 and the server. Its time will be exactly
utc. Then, if you send a message from S1 to X1 which takes .5 sec each
way, it will seem to take 0 sec to get to X1 and 1 sec to get back. Ie a
huge asymmetry, when in reality there is none. 

>
> If you're talking about the asymmetry caused by NTP assuming the one-way delay
> to/from the clients is RTT/2, I'm aware of that error. And I will try to 
> minimize it,
> e.g., using tunnels.

No idea what you think a tunnel is or how you think this would help you
at all. 


To reiterate. Get a gps PPS receiver for each end of the link you want to
test, and sync your clocks to that. You will still have problems on the
usec level, but that is better than the 100 us to ms problems you will have on 
the net. 

And if management tells you you cannot have that tell them you cannot do
the job they want you to do. It is impossible. 



>
>
> On Friday, October 26, 2012 11:19:26 PM UTC+1, David Woolley wrote:
>> pret3n...@gmail.com wrote:
>> 
>> 
>> 
>> > 
>> 
>> > Also, I don't want to use NTP to directly measure the one-way delay, I 
>> > have OWAMP
>> 
>> 
>> 
>> You can't stop it measuring the delay asymmetry!  The trouble is you 
>> 
>> will not have any way to obtain that value, which will tend to cancel 
>> 
>> out the asymmetry measured by your primary tool, assuming it depends on 
>> 
>> accurate time stamps!
>> 
>> 
>> 
>> > (more specifically perfSonar - http://www.internet2.edu/performance/pS-PS/)
>> 
>> > to do that for me.
>> 
>> > 
>> 
>> The page is a commercial type hype, not a technical overview of the 
>> 
>> algorithms used, but the only way I know of measuring one way delay is 
>> 
>> synchronise the clocks somewhat better than the acceptable measurement 
>> 
>> error, which you can't do if the synchronisation process is vulnerable 
>> 
>> to the effects of the same delay asymmetry.
>
>
>
> On Friday, October 26, 2012 11:19:26 PM UTC+1, David Woolley wrote:
>> pret3n...@gmail.com wrote:
>> 
>> 
>> 
>> > 
>> 
>> > Also, I don't want to use NTP to directly measure the one-way delay, I 
>> > have OWAMP
>> 
>> 
>> 
>> You can't stop it measuring the delay asymmetry!  The trouble is you 
>> 
>> will not have any way to obtain that value, which will tend to cancel 
>> 
>> out the asymmetry measured by your primary tool, assuming it depends on 
>> 
>> accurate time stamps!
>> 
>> 
>> 
>> > (more specifically perfSonar - http://www.internet2.edu/performance/pS-PS/)
>> 
>> > to do that for me.
>> 
>> > 
>> 
>> The page is a commercial type hype, not a technical overview of the 
>> 
>> algorithms used, but the only way I know of measuring one way delay is 
>> 
>> synchronise the clocks somewhat better than the acceptable measurement 
>> 
>> error, which you can't do if the synchronisation process is vulnerable 
>> 
>> to the effects of the same delay asymmetry.
>
>
>
> On Friday, October 26, 2012 11:19:26 PM UTC+1, David Woolley wrote:
>> pret3n...@gmail.com wrote:
>> 
>> 
>> 
>> > 
>> 
>> > Also, I don't want to use NTP to directly measure the one-way delay, I 
>> > have OWAMP
>> 
>> 
>> 
>> You can't stop it measuring the delay asymmetry!  The trouble is you 
>> 
>> will not have any way to obtain that value, which will tend to cancel 
>> 
>> out the asymmetry measured by your primary tool, assuming it depends on 
>> 
>> accurate time stamps!
>> 
>> 
>> 
>> > (more specifically perfSonar - http://www.internet2.edu/performance/pS-PS/)
>> 
>> > to do that for me.
>> 
>> > 
>> 
>> The page is a commercial type hype, not a technical overview of the 
>> 
>> algorithms used, but the only way I know of measuring one way delay is 
>> 
>> synchronise the clocks somewhat better than the acceptable measurement 
>> 
>> error, which you can't do if the synchronisation process is vulnerable 
>> 
>> to the effects of the same delay asymmetry.

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to