This is a combination of a few different hosts using IPv6.
This is the local clock, which is predictably uninteresting.
This is our GPS clock, which has regular outages due to bad positioning.
Rackety is quite dependable, but quite a way away.
The path to ETH looks like it might have been asymmetric. It also looks like something was tugging on the offset in shortly after the leap second.
We see that later the noise calms down a bit and the offset gets sorted out later. It looks like the blip was likely to be leap second related.
A local peer in TCD - the graph looks jumpy but the range is only a few milliseconds.
Another local peer in TCD - not quite so well behaved. No obvious leap second related incidents.
Another TCD peer - pretty well behaved.
A peer in TCD computer science - well behaved. There is a spike in jitter, but it is quite a way after the leap second, so I don't think it is related.
A peer in UCD. This machine gets the leap second wrong and then veers way off course, until it is reset. This machine might have been running an old OpenNTPd.
A peer in UCG - pretty well behaved.
A peer in IT Carlow - looks like it missed the leap second (strangely by about 0.5s), stepped the clock and then decayed back into place.
I'm not sure what happened here. The machine looks like it stepped its clock twice in the wrong direction and then twice back again.
This shows a machine in UCD that seems to be sliding around a little, but given the scale of the graph it is well behaved.
There's definitely some kind of action here around the leap second, but it is on a pretty small scale.
This is a RIPE TT box that seems to do the wrong thing - it is usually very well behaved, but looks like it got the second wrong. Once it steps back again things correct pretty quickly.
This is a machine that looks really badly behaved. I'm not sure if it is really this bad or if there are a few machines behind a NAT that we can't tell apart. It does look extra bad around the leap second, but it is usually about a second out so.
We don't really have enough measurements to see anything useful here.
This machine seems unperturbed by the leap second.
This machine seems to have been slightly dragged around by the leap second, but only by a few milliseconds.
This guy is always miles off.
On a short time scale it looks like there might be something going on with this host, but on a longer time scale, you see it just seems to be doing some sort of drift-correct-drift-correct-... thing.
Here's another one that gets the leap second wrong and seems to jump around a bit before getting everything back in place. It does seem to have had a similar incident a while *before* the leap second too!
Quite similar to the guy above.
Another quite well behaved guy.
Quite like 193.120.49.154 above. Generally terrible and not really any evidence that the leap second did anything.
For this one there's not enough points to say anything useful.
Again, not enough points.
Well behaved peer - not much to see here.
Wandering around a little, but on the whole pretty well behaved.
Yet another well behaved peer.
At first glance this looks like a leap second related problem, by on reflection it seems like there was some sort of routing glitch that did something bad to the RTT.
This machine seems particularly confused.
Fairly well behaved, ho obvious leap second related events.
Any issues here seem to be RTT related.
This machine seems to be a variable, but very large distance from us. There may be something leap second related here though, as the spike just after the leap second seems to be associated with quite a small RTT.
Not enough data to see what's going on.
Again, not really enough data to know what's going on.
This machine seems to take occasional fits, and there's one around starting about an hour before the leap second. Probably not leap second related?
Another well behaved peer.
Another well behaved peer.
A well behaved peer with a routing change.
A well behaved peer with the same routing change as above.
Not enough points and the peer doesn't look like it is usually well behaved anyway.
It's not clear what this guy was up to at all.
A well behaved peer, bar a routing glitch well after the leap second.
This seems like a usually well behaved peer who gets the leap second wrong. Looks like it gets back on track after only one step.
This seems to be another host that has an event a while before the leap second. The delay seems to go right up, so it may not be leap second relayed.
Something bad happens to this peer, and it doesn't seem to recover. There is a delay associated with it, so maybe not leap second related.
There seems to be a very big event here around the leap second, but the host recovers very quickly.
Another peer with a offset just after the leap second - maybe this machine is following someone who stepped to correct their offset?
Slightly wackey, but on the whole quite well behaved.
Go team damped oscillation!
This machine has a big jump, which is corrected relatively quickly, but it looks like it may have made the offset unstable for a while afterwards.
Not terribly well behaved, but there's definitely something going on around the leap second.
Not enough points to see what's going on.
Not enough points to see what's going on.
Not enough points to see what's going on.
Not enough points to see what's going on.
Not enough points to see what's going on.
Not enough points to see what's going on.
