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), 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 source on both ends that can correct the computer clock with a delay <1ms, I can't get that accuracy, right? On Saturday, October 27, 2012 6:15:30 PM UTC+1, unruh wrote: > On 2012-10-27, pret3n...@gmail.com <pret3n...@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@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, pret3n...@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> _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
