Maybe we can contact Google and see if they can help those underserved zones.
Google Public NTP
i think this could be a problem because google uses a leap-smeared time and not the ntp standard leap time. A mix of both could cause problems
alica
#3
Workaround: just stop publishing Google servers during the lead second smearing period/day, because they are intentionally keeping inaccurate time. Other than that Google servers should perform well.
ask
#4
Hi Alica,
That’d work well for SNTP clients (that just connect and set the time). For “ntpd” type clients that keep querying the same server for a long time (sometimes many months) this would still cause trouble.
I’m also not sure if Google has good service in the “underserved areas” (China, South America and Africa, for example).
That being said, I think it’s exciting getting more public NTP services. Until now the NTP Pool has been the only “global” high capacity NTP service other than those run for customers of particular systems.
paulgear
#5
I set up a few VMs to monitor the Google time service during the leap second period; hopefully I’ll have opportunity to publish an analysis some time in the new year. I’m also monitoring Apple, Microsoft, and Ubuntu over the same period.
josephb
#6
time.google.com seems to be DNS balanced over time1/2/3/4.google.com
They all have slightly different latencies, so one assumes they are in different locations, although it seems largely US centric at present based on latency in traceroutes.
Google is laregely very well connected to end user networks, so it’s good to have an alternative time source, although as @ask and even Google point out you can’t mix their time with general NTP pool time sources.
Traceroutes to time1 from various worldwide locations
https://pulse.turbobytes.com/results/58665a45ecbe403773002a2e/
Traceroutes to time2 from various worldwide locations
https://pulse.turbobytes.com/results/58665adbecbe403773002a35/
ddrown
#7
I believe they’re using Geo DNS, and your traceroutes are all to the same IP. I suspect the networks in your traceroutes would get different answers for time.google.com - 216.239.35.8 and 216.239.35.12 seem to be outside the US.
I have graphs for time1/time2, from my home connection (cable modem). Client has a GPS PPS, so the offset movements are from the networks involved. You can see the response latency of time1 moving around, probably from Google changing their outbound path. There was one odd spike in time2 where the request latency went over 500ms. The most likely canidate of what caused that is the cable network, though.
NTP RTT, time1: min 27.9ms, avg 37.0ms, max 68.5ms, stddev 4.4
NTP RTT, time2: min 35.7ms, avg 43.2ms, max 75.1ms, stddev 4.2 (excluding the 547.7ms rtt)
josephb
#8
The traceroutes were to the hostnames time1 and time2.
The turbobytes probes use their local DNS resolvers, so it doesn’t appear any GeoDNS routing is happening at present.
The graphs look great 
What are you using to create those?
ddrown
#9
Maybe the “time” hostname is the one Geo load balanced? time3 seems to be somewhere in Europe and time4 looks like it’s in Hong Kong.
The main branch is for chrony - there’s also a ntpd branch
josephb
#10
Now you mention it, I’ve run a few tests and yes that looks to be right, you get redirected to the closest one latency wise in all the cases I’ve tried.
time4 is about 140ms from Sydney, so yes that would very likely be Hong Kong.
time3 is about 280ms from Sydney, seems about right for the UK.
Thanks, will have a look see!
ask
#12
There were 9 servers in the pool that used the smeared leap seconds. They all got temporarily “kicked out” as they diverted from UTC. NTP servers that already were using them likely kept doing so though.
Steven Sommars helped in the last weeks identify servers likely to use Google NTP upstream and I asked them not to, but obviously we didn’t find everyone (or some switched after we’d checked a week or two ago).
Leap second 2017 status
ddrown
#13
And the full leap second smear, from a system that applied the leap second at midnight.
The difference in when the client saw the jump came from one packet being lost near 00:00 and the polling interval was 1024 seconds.
wols
#15
Me too 
Here is a screenshot from a first Grafana dashbord of my upcomming project “NTP statistics - Next Generation”.
I shows ptbtime3.ptb.de, tick.euro.apple.com and time2.google.com monitored by a Meinberg NTPCPU:
