Keeping Time with Amazon Time Sync Service
aws.amazon.com
aws.amazon.com
It's kinda neat they're using a link local address.
Yes.
They make a second last slightly long for some time period.
In some scenarios handling DST might not be necessary then!
It wouldn't work for a tv schedule though, since what is broadcasted still uses actual time. ;)
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.
You generally do not want to mix "smearing" and "non-smearing" time servers.
Apple's one is also available at time.asia.apple.com and time.euro.apple.com
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.
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
Source: recently asked them this.
(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.
Not true, you need a GPS lock as well as PPS.
Are you sure about 50ns?
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")
High accuracy time is a fascinating domain. It’s this weird mix of general relativity, hardware, and anthropology. Cesium atoms and satellites vs calendars vs astronomy: who wins? :)
Point being: more organizations making high accuracy time available to more folks is a good thing!
As far as who wins for a long time now it has been astronomers. The fact that Google and Amazon are doing leap smearing is a nice sign that the tide may be turning. It is very rare that you see organizations supporting leap seconds during big standards discussions that are not astronomers.
Software can be fiddly but I found this guide to be helpful: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
Hell, you can hook it up to a NodeMCU as well: https://blog.squix.org/2016/05/esp8266-peripherals-ublox-gps...
Bam, $10 wifi enabled GPS.
I am really curious to know what atomic frequency standards they are using. There is something a little suspicious about the wording. I have a feeling they mean "we use GPSDOs" and there are no atomic frequency standards physically located in each regional datacenter.
I'm also a little surprised to see that the remote clock is stratum 4. It would be interesting to see how they are distributing the time between their clocks.
If someone from amazon reads this it would be neat if you posted some more details about your setup.
If you take it at face value, the TrueTime API is implementable on top of any clock synchronization protocol. It's just coincidentally true that if you're close to a stratum 0-equivalent clock, your skew will be low. In terms of implementation, TrueTime daemons essentially also use Marzullo's algorithm to estimate timestamps, just like NTP.
What am I missing?
Time is important and hard. I doubt that customers who really need precise time would walk away from their ghetto solutions with no SLA because when something like this craps out, it's almost always a circus.
But hey, when time precision and accuracy is a bonus not a requirement for your AWS instance then 'free local NTP server!'
Something like eg Google Spanner relies on atomic clocks - it's a combination of hardware and software that enable the use of wallclock time.
100ms? 10ms? 1ms? 100us?
Finra (Financial Industry Regulatory Authority) requires <50ms
MiFID II (EU centric) HFT requirement can be as low as 100 microseconds accuracy, or 0.1ms.