Hello all, The fundamental answer / constraint to all questions of engineering, including temporal engineering, is funding. No bucks, no Buck Rogers. “Time” is a vast topic, pretty much as big as “space”. Precision timekeeping topics are only somewhat smaller in practical terms since issues of anthropology and philosophy, etc., that may be far afield in other kinds of engineering, remain remarkably pertinent.
Funding falls into per-project and per-community responsibilities. Per-project, the engineering requirements related to timekeeping are remarkably diverse. You can read about the resulting timekeeping solution we implemented in support of our Near-Earth Asteroid (NEA) survey (https://arxiv.org/abs/1807.01370), but the precise mix of ingredients varies even between astronomical observatories. The short answer, per-project, is that organizations should plan and budget for timekeeping just as with any other critical infrastructure. For example, we operate facilities in 6 buildings in 3 diverse locations, including two remote mountaintops. So we bought 3 commercial GNSS clocks and ran fiber between the pairs of buildings. We are extremely happy with the quality and support we have received from Meinberg, and I am happy to leave the NTP server-side updates to them, rolled into their occasional firmware updates. These updates have included significant feature improvements, including a nifty time synchronization monitor tool. My boss might call it the world’s most boring video game, but really that’s kind of the point. Many of the figures in the preprint above came directly from our Meinberg clocks. The cost of these clocks and related equipment is in the ballpark (baseball for “similar to”) for other classes of computing infrastructure. We don’t expect commodity computers to do hardware time-capture out of the box. At the moment we are commissioning operations on another telescope on yet another mountaintop and will probably buy another GNSS clock to provide both hardware time capture and NTP services. We are also planning a project-wide OS upgrade for which chronyd is the default NTP option and are evaluating its performance, which is to say that project timekeeping operations costs continue. Per-community, NTP is just one tool in a larger toolkit, but even so the panoply of NTP engineering requirements across many hundreds or thousands of projects is more diverse than POSIX or IETF have ever even attempted to capture, and funding has to compete with many other host-level and network-level standards. The Network Time Foundation (https://www.nwtime.org) supports the core NTP project, but NTF’s responsibilities are themselves broader than NTP. How many organizations support (financially) all the organizations like NTF that are responsible for standards, APIs, and protocols they rely on? Heck, how many of us read and respond to this professionally-relevant mailing list off-the-clock (as it were), as I am doing right now, rather than during work hours? Many people reading this are their organization’s expert on timekeeping issues, and time is likely of significant importance to your organization if you are still reading to the end of this message. Ask yourself if your project, company, or community budgets for timekeeping infrastructure, operations, and standards proportional to their impact and risks, positive and negative, to your mission? I believe one reason Meinberg added its very useful syncmon tool was to address customers’ precise-timekeeping reporting requirements, especially for financial institutions, who attach equally precise estimates of its value in units of currency. What’s time worth to you? Rob Seaman Catalina Sky Survey Lunar and Planetary Laboratory (I have no financial interests in Meinberg or NTF.) -- Hi Hal, It's 2020. How on earth can NTP still not implement UTC correctly, in all cases? Or is it a fundamental NTP design flaw? The Z3801A issue doesn't sound like an NTP problem. This is a known legacy Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or even two GPS WNRO problems buy now? /tvb On 2/6/2020 1:41 AM, Hal Murray wrote: tvb said: There's no ambiguity. Those are just bugs. No software should depend on more than 1 month notice of a leap second and no software should be fooled if the notice is months or even years in advance. There are plenty of quirks in ntp code along that line. The APIs don't have an explicit when. The NTP-Kernal API for leap-pending is leap-tonight. You have most of the next day to turn it off. The leap-pending on the wire is leap-at-the-end-of-this-month. I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was June or December. It's a hack, but it gets the job done and the code wasn't setup to ask it when the leap would happen. tvb said: If you're writing a FAQ or best practices guide stay in touch. I have a semi-technical leap second report in the works. UTC is actually very simple; but it's been complicated by untold levels of bad assumptions, bad execution, and bad prose. Are you going to say anything about POSIX?
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
