Hacker News Reader

Comment by CaliforniaKarl | Hacker News Reader

Argh! I wish the NTP servers were usable from outside of AWS.

Outside of North America and Europe, there aren't as many public NTP servers as there should be. For example, according to http://www.pool.ntp.org/zone/south-america, South America has less than 50 NTP servers.

It would be awesome if the large, widely-distributed providers (not just AWS with CloudFront, but also Akami, Cloudflare, etc.) provided public, Stratum-1 NTP servers at their POPs.

View on HN

Google hosts some: https://developers.google.com/time/

Note that they smear time, though (WRT leap seconds), as do Amazon.

You generally do not want to mix "smearing" and "non-smearing" time servers.

You probably don't want to mix time servers that use a different algorithm for smearing, either.

Interesting point, we're looking at implementing this new ntp server. Wanted to know a bit more about the risks of mixing leap second algos. Is there any more info / links you can give on the subject?

time.windows.com, time.apple.com, and time1.google.com are all publicly accessible.

Apple's one is also available at time.asia.apple.com and time.euro.apple.com

windows and apple tend to keep terribly inconsistent time, though, and windows time goes nutso at leap smears.

Do you have a citation for this? I've been monitoring NTP servers for years and Apple's are among the closest to my GPS reference.

Hmm...our data center (bare iron, not cloud) has always provided NTP servers. I assumed this was standard.

Anyone can provide an NTP server, but that's much different from having an atomic clock powered NTP server.

The servers your datacenter provide are probably clients of other NTP servers, so the quality and availability of NTP servers near your datacenter is still really important.

Having an atomic clock behind your NTP server doesn't really gain you anything unless GPS is lost for an extended period of time. As long as a timeserver has a GPS lock, it's going to be disciplining the atomic clock the same way any other clock is disciplined, so you don't really gain anything. Even a cheapie timekeeping GPS chip can get down into the < 500ns accuracy range (and the Thunderbolt on my desk will get down to < 50ns).

(You can gain a little accuracy if your timeserver itself is running its main clock (the one that drives the CPU and all the busses) off of a precision frequency reference, be it GPSDO or atomic clock, but that's a separate discussion)

Oh, and if you're using NTP and not directly connected to a precision timesource (not over the network), you may as well give up on that level of precision anyhow. For that you need PTP.

> As long as a timeserver has a GPS lock, it's going to be disciplining the atomic clock the same way any other clock is disciplined

Not true, you need a GPS lock as well as PPS.

Are you sure about 50ns?

The PPS is just something you get when the GPS chipset has a lock, though (and sometimes when it doesn't, depending on how you have it configured). Most non-timekeeping GPS chipsets give you a PPS output for free, and 100% of timekeeping GPS chipsets give you one.

Pretty sure about 50ns. Datasheet for the Trimble Thunderbolt E: http://trl.trimble.com/docushare/dsweb/Get/Document-383329/0... ...second page, "PPS accuracy: 15ns (one sigma)" (I picked a larger number than the spec sheet simply so that hopefully nobody would go "oh, that's the ONE SIGMA value, lets argue".)

My Thunderbolt, in a completely temperature-uncontrolled environment with ~20 degree daily swings, generally has a PPS accuracy of ±45ns, in what is pretty crap conditions (first rule of precision timekeeping is "temperature stability")

I should have been more specific. You need GPS, PPS and you need to correctly configure them. Its a bad idea if people think you can just plug a USB into a GPS and be good to go.

I would assume a datacentre would put a GPS somewhere to provide time to an NTP server. It's quite cheap, easy to do, and a useful value-add for their customers; and it's something that can only can be done by someone with physical (and likely roof) access.

And I would add for the crowd that one can easily check what sort of NTP server is on offer. NTP tracks the "stratum" of a server, which is how far the server is from an authoritative time source:

https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_st...

If you're using ntpd, you can check it like this:

  $ ntpq
  ntpq> peer
       remote           refid      st t when poll reach   delay   offset  jitter
  ==============================================================================
  *y.ns.gin.ntt.ne 249.224.99.213   2 u  815 1024  377    1.230   -4.148   1.825
  +hadb2.smatwebde 209.51.161.238   2 u  809 1024  377   49.672   -2.073   3.869
  +six0.ntp3.mattn 128.227.205.3    2 u  409 1024  377   63.721   -4.328   2.669
  -hadb1.smatwebde 45.79.187.10     3 u  808 1024  377   49.767   -6.600   2.927

These are 4 servers out of the NTP pool; 3 are stratum 2 and one is stratum 3. The * means it has selected the first, the + means it likes the next 2, and the - means it has discarded the last one.

As one example, Rackspace doesn’t (they upstream from pool) for all their data centers.

Source: recently asked them this.

The datacenter I use does: http://www.he.net/adm/ntp.html

I've always assumed the DC's NTP servers were GPS fed, but I admit I have never asked. I don't need atomic-clock time accuracy for my work at present.

Reply on news.ycombinator.com