Re: [gpsd-dev] Clarifications needed for the time-service HOWTO

[Hal Murray]

address@hidden said:
> Is it really true that most public NTP servers are Stratum 2, or are there
> more layers in normal use?

It will be hard to say anything crisp in that area.

Public servers are often overloaded and/or abused.  ISPs should be running a 
NTP server for their customers, or rather several of them.

I'd break the public servers into 3 clumps.  (Remember, lot of fuzz in this 
area.)

The top level are the public servers run by the national timekeeping 
authorities of each country.  They are generally stratum 1.  In the US, 
that's NIST and USNO.  They are funded as part of the government.

The next level is companies or individuals who make their NTP servers 
available as a public service.  Some of these are stratum 1, but often they 
are stratum 2 to keep the load on their stratum 1 server reasonable.  Those 
stratum 2 servers are typically located close (via network timing) to a 
stratum 1 server.  From the point of view of a user on the great big 
internet, it's hard to tell the difference between stratum 1 and a well run 
stratum 2.

The next level is the pool.  It has a mix of stratum 1, 2, and 3, and 
probably a few others.


>                                                              When I look in 
> my system's config file, I see
> one server: ntp.ubuntu.com.  Stratum 2 or higher? Is there any way I can
> tell?  

ntp.ubuntu.com => 91.189.94.4 and 91.189.89.199

If you are running ntpd on your system, "ntpq -p" should tell you what 
servers you are using and their stratum.  That's the "st" column.

Or you can ask it directly:
    sntp -d ntp.ubuntu.com
Should print stuff ending with something like this:
sock_cb: ntp.ubuntu.com 91.189.89.199:123
2013-10-19 20:44:20.450437 (+0800) +0.009701 +/- 0.039762 ntp.ubuntu.com 
91.189.89.199 s2

That "s2" on the end is the stratum.

(ntpdate -d xxx will also print the stratum, but it's deprecated.)  


> More generally: what can I discover about the quality of the chimers I
> listen to? 

Again, I think it will be hard to get a crisp answer.

The key idea is that ntpd assumes that the network delays are symmetric in 
both directions.  (I assume you know the 4 time stamp stuff.)

In general, closer servers work better - there is less opportunity to hit an 
overloaded link.

If you are running ntpd, look at what "ntpq -p" says.  Keep an eye on the 
delay column.  You want the readings when that is at a minimum.

If you have a home DSL line, you want to avoid times when you are doing a big 
download.


>    Those hotplug devices will, however, may be able to use plain,
>    non-kernel PPS. gpsd tries to automatically fall back to this when
>    absence of root permissions makes KPPS unavailable. This fallback is
>    complicated by the fact that gpsd needs to communicate to ntpd in
>    a different way in root and non-root mode.  This complicates the
>    configuration in ways beyond the scope of this document and is strongly
>    discouraged in practice. 

I can't quite figure out what that's trying to say.

What do you mean by "KPPS"?

RFC-whatever has two parts.  One is to just grab the time stamp when the 
modem control signal changes, and the API to read it.  The other is to push 
the whole timekeeping phase locked loop into the kernel.  Linux doesn't 
implement the second part.

On Linux, things like
  cat /sys/class/pps/pps0/assert
will give you things like:
  1382242063.999995003#2900635
The stuff after the # is a counter.  The stuff before it is a timestamp.  
Looks like this box is off by 5 microseconds.

----------

address@hidden said:
> Which set of ntpd segments GPSD can use is constrained by whether it started
> up as root or not.  But whether it can use KPPS is controlled by whether it
> still has root *at the time the PPS source is opened*.  

I'll bet it's more complicated than that.  It depends on how your distro sets 
things up.

There is no reason you can't read the PPS stuff from a non privileged user 
ID.  (Or at least, I don't see one.)  The current code may not support that.



-- 
These are my opinions.  I hate spam.