[ntp:questions] Accuracy of GPS device

unruh unruh at wormhole.physics.ubc.ca
Fri Sep 2 16:18:18 UTC 2011


On 2011-09-02, Miguel Gon?alves <mail at miguelgoncalves.com> wrote:
> On 2 September 2011 07:56, unruh <unruh at wormhole.physics.ubc.ca> wrote:
>
>>
>> Nope.
>>
>> It is completely unclear to me what your question is. Your 10.0.2.254 is
>> an outside switch.
>
>
> I had several questions in my first message. Your assumption is wrong.
>
> You are telling me that a switch I installed in my rack and defined its many
> IP addresses is outside my company? Uau!

I am not telling you anything. I am trying to find out what you are
doing.


>
> 10.0.2.254 is a local as any machine in the 10.0.0.0/8 network.
>
>>> > $ ntpq -p 10.0.99.99
>> >> >      remote           refid      st t when poll reach   delay   offset
>> >> >  jitter
>> >>
>> >>
>> >==============================================================================
>> >> > *10.0.2.10       .GPS.            1 u   21  256  377    0.173    0.196
>> >> > 0.008
>> >> > +10.0.2.9        .GPS.            1 u   93  256  377    0.175    0.191
>> >> > 0.014
>> >> > +10.0.2.254      81.94.123.16     2 u  149  256  377    0.583   -6.884
>> >> > 0.152
>>
>> This tells me that your two GPS receivers are consistant with each
>> other, but I have no idea why the offset is larger than the delay, and
>> why the offsets are so large. On a lan, the offsets should be a factor
>> of 20 or so less than what you are getting here.
>> That the external router is 7 ms out just tells me that it is really
>> poorly synced with the outside world.
>>
>
> I found out the problem and just for the record I'll explain...
>
> The offset is larger than the delay because NTPd is using 10.0.2.254 (more
> on this switch later) as a time source and it shouldn't because it has two
> local stratum 1 clocks that are closer (0.170 ms vs 0.583 ms) are show less
> jitter. Anyway... to prove my point I removed 10.0.2.254 (the **internal**
> switch) from the configuration and here's the result of ntpq -p as of now:
>
> $ ntpq -p 10.0.2.2
>      remote           refid      st t when poll reach   delay   offset
>  jitter
>==============================================================================
> +10.0.2.10       .GPS.            1 u  889 1024  377    0.179   -0.066
> 0.083
> *10.0.2.9        .GPS.            1 u  391 1024  377    0.166   -0.084
> 0.051

Still far too large an offset. 


>
> Oddly enough, FreeBSD embedded machine with roughly the same NTP
> configuration shows better results
>
> $ ntpq -p 10.0.99.99
>      remote           refid      st t when poll reach   delay   offset
>  jitter
>==============================================================================
> +10.0.2.10       .GPS.            1 u  864 1024  377    0.193    0.025
> 0.301
> *10.0.2.9        .GPS.            1 u 1012 1024  377    0.192    0.030
> 0.004

That is better, but still large. 


>
> Regarding 10.0.2.254 it is an internal switch it is getting time over a
> cable connection from several sources

Thank you. Why not have it also get its time from your intenal GPS
sources?

>
> $ ntpq -p 10.0.2.254
>      remote           refid      st t when poll reach   delay   offset
>  jitter
>==============================================================================
> -ntp0.as34288.ne .PPS.            1 u  391 1024  377   71.960   -1.029
> 0.270
> *canon.inria.fr  .GPSi.           1 u  707 1024  377   55.220    0.199
> 0.700
> +ntp1.inrim.it   .CTD.            1 u  359 1024  377   65.860    0.091
> 1.830
> +ntp-p1.obspm.fr .TS-3.           1 u  373 1024  377   55.110   -0.215
> 0.610
> -metasweb01.admi .HBGi.           1 u  992 1024  377   73.290   -5.182
> 0.850
>
> I can't control the network at my upstream provider and while my link is not
> saturated (far from that) my upstream provider links be could and there's
> nothing I can do about it except deploying local time sources as I did.
>
> I am checking my local time sources with some remote NTP stratum 1 servers
> at a fixed interval and plotting the results. I see that once in a while the
> offset to external time servers increases and I agree this has to be with
> network congestion but this happens at my ISP so there's not much I can do.
>
>>> > This is a FreeBSD embedded PBX machine running Asterisk. The machine is
>> >> > mostly idle. What kind of offsets should I get with local machines?
>> >>
>> >> in the 10s of usec range max. Certainly less than the delay.
>> >>
>> >
>> > tens of usec is good... Anyone here which can explain why NTP isn't
>> getting
>> > that?
>>
>> How could we?
>> Maybe you are running a virtual BSD machine, and thus the clocks are
>> wonkey. Maybe you have lousy hardware. Who knows.
>>
>
> No lousy hardware here but I think posting detailed hardware specifications
> won't help.
>
> No virtualization here also.
>
>>>  > Assuming ntp04, ntp05 and ntp06 are on the same LAN I see offsets
>> higher
>> >> > than 100 us. Is it possible to decrease these numbers?
>> >>
>> >> Sure. all my systems have offsets in the 10us range--  on the same lan
>> >> as my time server.
>> >> Mind you I do use chrony, not ntpd but even ntpd should be in a few 10s
>> >> of usec.
>> >
>> >
>> > Can ntpd really get there? I'll try to query some good public servers to
>> see
>> > what others are getting...
>>
>> Sure it can. It can get better than 30us. But why you are not getting it
>> is impossible for us to say.
>
>
>
> I got it... As you saw above.




More information about the questions mailing list