[ntp:questions] Accuracy of GPS device

Miguel Gonçalves mail at miguelgoncalves.com
Fri Sep 2 09:07:29 UTC 2011

Hi David!

On 2 September 2011 08:19, David Woolley <david at ex.djwhome.demon.invalid>wrote:

> Miguel Gonçalves wrote:
>> No. This is a stratum 2 server and it gets the time from stratum 1 servers
>> thus the names and not IP addresses.
> Poorly connected stratum 1 servers.  With current WAN speeds you should
> have delays more like 10ms.  Maybe you WAN is overloaded.  Certainly you
> haven't prioritised NTP traffic.  As you are running VoIP, maybe you have
> prioritised that.

Actually I haven prioritized traffic has my WAN link is far from saturated:
it shows less than 5% of usage everyday. I monitor this so I know.

 Assuming ntp04, ntp05 and ntp06 are on the same LAN I see offsets higher
>> than 100 us. Is it possible to decrease these numbers?
> Why do you need that accuracy.  VoIP will tolerate a few milliseconds.

The reason is the same as some guys have Cesium atomic clocks at home: if I
can why not have it? :-)

At the moment I have two GPS receivers (Garmin 18 LVC and Sure Evaluation
Board). I intend to deploy a Motorola OnCore and a Garmin 18x in the future.
For NTP they should perform equally. :-)

 Firstly note that the offset is not the same as the error.  When things are
> stabilised the error should be several times less than the RMS offset.

So... The estimated error returned from ntptime is the value I need to

> To improve:
> - Do use local radio clocks - the jitter from your long delay external
> servers doesn't give you a good start;

Have 2.

> - Don't use Gigabit switches, these can introduce considerable latency;

Can't change this :-(

> - Beware of modern ethernet cards that do interrupt combining;

Will check this.

> - Make sure that your routers and the ethernet driver give NTP traffic
> highest priority.  As you are presumably already using EF for the VoIP
> traffic, and that is likely to be a significant part of the traffic, this
> may not be possible within the DiffServ framework;

Will have to see what I can do about this.

> - ideally don't run VoIP on the same machine, as it likely to produce
> bursty traffic

VoIP server is a stratum 2 server (it uses the two GPS connected servers)
and only provides time to the VoIP phones.

 OK. But this is a 24 port Gigabit switch from Cisco. I wouldn't expect
>> asymmetry but it could be.
> Gigabit switches are bad news for anything with extreme latency
> requirements.

Unfortunately I can't change this.

>  All these machines sit in a room temperature controlled at 20 ºC.
>> is a backup server that just does some work every hour but nothing huge
> That doesn't mean that there is a good exchange of air between the hot
> areas and the controlled room.  Incidentally the best way of cooling
> machines, although not necessarily the best way of getting a constant
> temperature, is blow the cooled air directly into the machines, rather than
> just generally cooling the air in the room.

Very good point really. This is probably why the FreeBSD machine performs
better than the Linux one. The FreeBSD is embedded and doesn't produce a lot
of heat while the Linux one is a Dell regular server. Perhaps removing the
lid on the Linux server will improve things.

>> has been running for quite a while and it doesn't seem to get
>> lower
>> offsets. Could it be because it's running Linux? I've heard Linux is not
>> as
>> good as FreeBSD for time keeping.
> It probably means there is jitter in the time from the servers.  Offset
> doesn't measure the error in the internal time, it measures the estimated
> instantaneous error in the measurements of that time.  A large error in the
> measurement will produce a proportionate, but smaller error in the actual
> time.

OK. So I should look at ntptime? Or ntp -c kerninfo? I tried

$ ntpq -p; ntpdc -c kerninfo
     remote           refid      st t when poll reach   delay   offset
+       .GPS.            1 u  734 1024  377    0.182   -0.149
*        .GPS.            1 u  235 1024  377    0.163   -0.055
pll offset:           -8.5e-05 s
pll frequency:        44.545 ppm
maximum error:        0.151092 s
estimated error:      3.8e-05 s
status:               0001
pll time constant:    6
precision:            1e-06 s
frequency tolerance:  512 ppm

So, despite 149 and 55 us I should consider the 38 us estimated error?

For the FreeBSD PBX server

asterisk# ntpq -pn ; ntpdc -c kerninfo
     remote           refid      st t when poll reach   delay   offset
+       .GPS.            1 u  843 1024  377    0.202    0.033
*        .GPS.            1 u  991 1024  377    0.186    0.029
pll offset:           2.4324e-05 s
pll frequency:        151.490 ppm
maximum error:        1.03863 s
estimated error:      2.1e-05 s
status:               2001  pll nano
pll time constant:    10
precision:            1e-09 s
frequency tolerance:  496 ppm

BTW, what is the difference between 2001 pll nano and 0001 in the status?

Thanks a lot David! You were very helpful!

More information about the questions mailing list