The PTP guy

Legacy systems

One of the issues often discussed in the light of time sync requirements for software applications coming from the MiFID II and NMS CAT regulations is the one of legacy systems. There are two parts to this.

First is legacy applications, being applications which do not support the capture of timestamps with the required granularity. The problem lies either with their design (simply put, fields, structures and protocols with no room for nanosecond or even microsecond resolution), or with the technology they use (older Java versions for example). Both of these issues can be remedied with some development and migration effort. Another issue is the accuracy and non-uniformity of timestamps retrieved from the operating system - this is not easily fixed, as it is mostly out of the developers' control. In non-virtualised systems, clock_gettime() or even gettimeofday() usually meet the regulatory requirements. I will not discuss their performance here, but that is not to say that they have no effect. For older Java applications, one can use JNI to call these functions, at the cost of even greater call latency.

The second part is legacy operating systems, and this post is about one of them: Solaris 10.

What what what?

Seeing that this situation has not improved at all since around 2010 when I first looked into it, I thought it would be worthwhile to write a note on an important step so often missed by vendors when implementing (IP) multicast PTP (Default profile and Enterprise profile).

I have worked with multiple complete hardware PTP implementations (appliances) that are multicast-capable: GMs, slaves, and most importantly in this context - probes, analysers and other test kit. All but very few supported sending IGMP joins or replied to IGMP querries. In my book, a multicast-capable IP stack with no IGMP support is incomplete. You all do support ICMP, do you not - or did I lose you already?

Even the fact itself that I have to explain this, should already be embarrassing to those vendors. In multiple conversations, vendor representatives otherwise well-versed in all things timing, were not quite sure what the question was. When asked if they supported sending IGMP joins or replying to IGMP queries, they would in turn ask me to spell it (as if it were some rare animal), write it down and say they would get back to me. OK, I can understand that you're a frequency guy who transitioned into the world of IP, but it's an IP world we live in, so please do your homework!

Why are we all here?

Do not believe anyone spreading apocalyptic news about things crashing and burning because of the leap second. Just like death from a gunshot wound is not death from lead poisoning, things crash because people do not test their systems enough, and not because we insert an extra second every few years. Having tested the leap second event ad nauseam for the past couple of months, using GPS simulators and a range of timing hardware along with pure software setups, I feel both relieved and disappointed at the same time, now that the day of he leap second has come. Weeks of preparations on hardware and software side, hard and sometimes frustrating work with vendors and coding until small hours, all conclude today, and then we will likely forget about it for another year or two, or more - that's if it doesn't get abolished later this year. Everything is ready and leap second pending warnings are flying around. Why is it all always last minute? Hard to say - but mostly because vendors don't do their job right so everything has to be verified twice by the customer. It's not even that the cake is a lie. Everything is.

So much for a rant, a now for something completely different; no. 1: the leap second.

Author's note

This article is meant as a mostly non-scientific source of information about the leap second event in relation to running (maintaining) computer systems - personal computers, servers, network equipment or any other systems using some form of external time source. While I only managed to put this together just about a week before this year's event (2015), I thought it's still worth it as it is quite likely that this is not the last leap second event we are going to witness. If you're reading this before this year's event, consider it a good refresher. If you're reading this before this year's event and it's all new to you, you may be slightly worried. There is still some time.

I think it's worth adding that I was tired of reading oversimplified statements like "every now and then the day becomes longer by a second" being the only meaningful fact conveyed in a two-page long blob of text. I wanted to provide something in the middle. I probably failed (in favour of too detailed), but at least one cannot say I didn't try. As you will find, the style this is written in, is an annoying combination of technical details interleaved with absolute basics. This text also is not a ready-to-eat HOWTO. If you're looking for information on how to configure your NTP or PTP, this is not the right place - but keep checking the site for more articles. This is a knowledge transfer dump about all things leap second. Perhaps an infographic or a leap second timeline could be added at some point.

There are no graphics throughout, so I'll start with a picture. Here is the Leap Second 2015 in stereotypes:

All right, here goes the website. Having wasted a lot of documentation material by e-mailing people instead of publishing it, I finally decided to wise up and start typing things up. I'm hoping for this page to become a good source of information on all things PTP / IEEE 1588 and all things PTPd. If you like what you see, follow me on twitter @ThePTPGuy and come back to this site every now and then. I chose Logdown as my initial publishing platform and we'll see where this takes me. Possibly to Github.