Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming

NTP's Fate Hinges On "Father Time" 287

Esther Schindler writes In April, one of the open source code movement's first and biggest success stories, the Network Time Protocol, will reach a decision point, writes Charlie Babcock. At 30 years old, will NTP continue as the preeminent time synchronization system for Macs, Windows, and Linux computers and most servers on networks? Or will this protocol go into a decline marked by drastically slowed development, fewer bug fixes, and greater security risks for the computers that use it? The question hinges to a surprising degree on the personal finances of a 59-year-old technologist in Talent, Ore., named Harlan Stenn.
This discussion has been archived. No new comments can be posted.

NTP's Fate Hinges On "Father Time"

Comments Filter:
  • Fewer bug fixes? (Score:3, Insightful)

    by Anonymous Coward on Thursday March 12, 2015 @09:07PM (#49246987)

    What the hell is there to fix in a protocol solely designed to return a string of numbers?

    • Re:Fewer bug fixes? (Score:5, Interesting)

      by nitehawk214 ( 222219 ) on Thursday March 12, 2015 @09:59PM (#49247215)

      If it is not broke, fix it until it is.

      Is this what keeps projects alive?

    • Re:Fewer bug fixes? (Score:5, Interesting)

      by BitZtream ( 692029 ) on Thursday March 12, 2015 @10:26PM (#49247327)

      NTP doesn't just 'return a string of numbers'.

      But either way, the article isn't about NTP the protocol, its about one shitty implementation of NTP that I don't think anyone even uses anymore. Windows and OS X certainly don't.

      The summary and headline are equivalent to saying 'Netscape is going out of business, HTTP in danger of disappearing'

      If he were to drop dead right this instant ... no one that matters would notice beyond his family.

      • Re:Fewer bug fixes? (Score:5, Informative)

        by garyisabusyguy ( 732330 ) on Thursday March 12, 2015 @10:47PM (#49247405)

        Feeling grumpy?
        From page 2 of the linked article:
        Apple Macintosh computers and servers running OSX use NTP, and Stenn said Apple developers have called him for help on several NTP issues. In the last such incident, he said he delayed a patch to give Apple more time to prepare OS X for it. When they were ready, he applied the patch and asked "whether Apple could send a donation to the Network Time Foundation," Stenn recalled. "They said they would do their best to see that Apple throws some money our way." But it hasn't happened yet.

        Apparently somebody is under the impression that OSX still uses it, unfortunately this is how the business majors deal withit:
        "Everybody loves us," Stenn said. "But people with money say, 'We don't give to open source projects.'"
        http://www.informationweek.com... [informationweek.com]

        • by Anonymous Coward on Friday March 13, 2015 @12:10AM (#49247635)

          "Everybody loves us," Stenn said. "But people with money say, 'We don't give to open source projects.'"

          They don't give to GPL projects.

          They hire BSD developers (CUPS, Clang, etc) because they can keep the parts closed they want.

        • Re:Fewer bug fixes? (Score:5, Interesting)

          by Crashmarik ( 635988 ) on Friday March 13, 2015 @02:17AM (#49247929)

          So he patched for and worked with Apple and they said we'll see ?

          If his time isn't valuable to him why should it be to Apple ? Next time they call he should tell them he can't talk to them unless they fax back a block time purchase agreement with either a check or credit card and a statement they won't charge back.

          • Re:Fewer bug fixes? (Score:5, Informative)

            by gnasher719 ( 869701 ) on Friday March 13, 2015 @04:31AM (#49248295)

            So he patched for and worked with Apple and they said we'll see ?

            The way he did this, it is probably difficult for the responsible person at Apple to actually pay him. He should have offered to do the work as a contractor, someone would have found money in a budget, and when he sends a bill for five days contracting work they pay the bill. That's how it works.

            He seems to be asking for a donation to an open source project. How can someone at a commercial company put that in a budget? The financial guys say "is there any legal reason why we have to pay this money", the answer is no, so it won't get paid.

          • by gl4ss ( 559668 )

            it would be helpful if it mentioned what the patch actually did.

            was a patch for the server, that would have broken osx if rolled out? did the patch then break unpatched osx time sync? or what. I mean, why did he need to delay it? what the fuck? why not make actual sense, maybe people would give you money if you could articulate it meaningfully why you need more money to maintain something that does one thing and has been getting patches for a long time already, never mind that simplification of it to a degr

        • No business sense (Score:5, Insightful)

          by melchoir55 ( 218842 ) on Friday March 13, 2015 @02:26AM (#49247941)

          It is absurd to expect a corporation of any size to "toss something your way". He should have told apple, when it mattered to them, that they could pay a service fee to have him delay the patch for their benefit. No, this isn't how you want to deal with individual people. Yes, this is how you must deal with a corporation.

          Life lesson: mega corps don't even care for the people they employ, and much less people outside the corporation. A corp is an abstract non-human entity. It doesn't deserve your charity.

          • Not to protect douchebag apple guys, but even if developers who contacted the "NTP dad" wanted Apple to throw a donation, then it would be real hard to push by the accounting. If they, on the other hand would be billed for "3rd party expert services" - noone would blink an eye, so, yes, if a large corporation contacts you asking to help fix something - send them a bill first.

          • by TFlan91 ( 2615727 ) on Friday March 13, 2015 @08:59AM (#49249459)

            "A corp is an abstract non-human entity"

            I know of 9 judges who would tell you otherwise.

      • Re:Fewer bug fixes? (Score:4, Interesting)

        by msauve ( 701917 ) on Friday March 13, 2015 @12:01AM (#49247603)
        So, what implementation of the NTP protocol do you use? Chrony?

        The reference implementation, which is the subject of the article, is what's used by pretty much everyone. Name a significant OS/distribution which doesn't use ntpd.

        Oh, and that includes OS X, contrary to your incorrect claim:

        macmini-2:~ msauve$ ntpd --version
        ntpd - NTP daemon program - Ver. 4.2.6

        --OS X Yosemite

        You are correct about one thing - it is a shitty implementation. It doesn't even follow RFC 5905, which it's supposed to be the reference for.

      • Re:Fewer bug fixes? (Score:5, Informative)

        by f3rret ( 1776822 ) on Friday March 13, 2015 @04:04AM (#49248211)

        NTP doesn't just 'return a string of numbers'.

        No, sometimes it returns A lot of strings of numbers [sans.edu].

    • by Terje Mathisen ( 128806 ) on Friday March 13, 2015 @02:41AM (#49247973)

      I've been on the "NTP Hackers" mailing list for ~15 years now, my last major effort was to develop a server-optimized multi-threaded version of the core ntpd sw: I was hoping for wire speed packet processing on an embedded linux platform, but had to settle for 3-500 Mbit/s since the target kernel version did not support multi-thread targeting of incoming packets, i.e. I needed to have a single receive thread which would fetch the incoming packets, timestamp them and queue them up, then all the other threads/cores would grab them from there.

      Back to the "why are there bugs in such a trivial protocol?" question:

      By far the biggest cause of required effort when trying to modify or optimize the NTPD distribution is the need to support a big number of OSs and even larger number of OS versions, some of them more than 20 years old, even if the main targets are Unix-like or Windows.

      The second problem is the need to support 30+ reference clocks, with all sorts of OS/version specific interfaces needed in order to timestamp events as accurately as possible.

      The third and final major stumbling block is all the crypto stuff, which got added in order to be able to authenticate both time packets and monitoring/configuration requests, and this is where the latest major bugs have been found.

      PHK (who is working on Ntimed) has spent a lot of time on NTP, including his time as a core FreeBSD hacker when he made sure that the FBSD had the best possible timekeeping kernel. This is the reason that my personal pool server has always used FreeBSD.

      If your only need is to get 0.1s level time sync on a number of client only machines, then it really doesn't matter how you implement the NTP protocol, except that you should really try to measure and adjust the local clock frequency so as to track the reference time!

      The default Windows time code implements Simple NTP (SNTP) which uses the NTP packet format but doesn't try to implement the proper control loop to steer the local clock, instead it just yanks the OS clock resulting in a sawtooth-like pattern of clock offsets.

      Terje

    • What the hell is there to fix in a protocol solely designed to return a string of numbers?

      Yeah. All You Have To Do Is...

      (screams)

    • What the hell is there to fix in a protocol solely designed to return a string of numbers?

      Because time is a rabbit's nest of problems. https://www.youtube.com/watch?... [youtube.com]

  • by borcharc ( 56372 ) *

    stop hitting us up for money

    • by snowsnoot ( 3389789 ) on Thursday March 12, 2015 @09:19PM (#49247055)
      Yes but there are an assload of companies out there making a shit-tonne of cash using these FOSS programs and not contributing in any way whatsoever. Its a complete disgrace and they should be exposed for the cheapskates they are.
      • Free and Open Source... unless you make money, then fuck you.

      • As much as we can shit on corporations for not paying the piper, I am sure many are oblivious who they need to be supporting and funding. How many of us on /. actually are aware of the time and effort spend by certain individuals to ensure backbone implementations are kept in a healthy state. I am sure many corporations on in the same spot, after all they paid RedHat or some other vendor for a solution and that's probably as far as it went. Many of us take these projects for granted.

        The other issue is the p

    • by LWATCDR ( 28044 )

      1. It is an article about a problem. At no time did he ask for individual donations.
      2. NTP is important like SSL is important to the internet in general.

      You are not saying anything that helps solve a real problem or contributing to the discourse. So since you commented how would you solve the issue of providing resources for the development of NTP?

  • by YrWrstNtmr ( 564987 ) on Thursday March 12, 2015 @09:12PM (#49247009)
    Given 30 years, a single protocol, and 'many eyes'...what is there to fix or update?
    • Re:Bugs? (Score:5, Informative)

      by garyisabusyguy ( 732330 ) on Thursday March 12, 2015 @10:17PM (#49247297)

      Here is an interesting interview with Harlan Stenn at the 2013 Google Summer of Code
      https://www.youtube.com/watch?... [youtube.com]

      Apparently he is keeping 7 doctoral and post-doc students busy working on timestamps, noise and 'something' that he did not seem to have a firm grasp on
      He also mentioned a need for admins, a webmail guy and people who want to do documentation

      Having been handed projects after a leads retirement, I think that documentation may be the more pressing need

      • by mjgday ( 173139 )

        I think that documentation may be the more pressing need

        But the code IS the documentation!!!!

  • Not stable yet? (Score:2, Insightful)

    No offence, but NTP simple time protocol as it is is surely reliable enough that it doesn't need more maintenance (after IPv6). Don't fix what ain't broken.
    • No offence, but NTP simple time protocol as it is is surely reliable enough that it doesn't need more maintenance (after IPv6). Don't fix what ain't broken.

      Stable platforms do not survive well in the OSS world. The stack is constantly living, and the components need periodical adjustments to keep them in the wagon.

      • NTP is pretty independent in the OSS world. A server - maybe dedicated - is based on a hwclock that gives very precise time. Dependencies? Network, ssl maybe... And that's it. So once security and ipv6 are working fine, done. Don't touch it anymore.
    • It's gotten more complex because it has security now, which it needs and is broken without it. Crypto, key exchange, etc. So complex enough that it needs maintenance.

  • by macraig ( 621737 ) <mark...a...craig@@@gmail...com> on Thursday March 12, 2015 @09:13PM (#49247027)

    At 59 years old, statistically Mr. Stenn isn't going to live long enough to maintain NTP for another 30 years. Perhaps something so crucial should be a voluntary communal effort?

    • Re: (Score:2, Funny)

      by borcharc ( 56372 ) *

      according to the article he does the entire project by himself, no wonder its a mess. If this graybeard cant take on a team of young folks then we will have to wait for him to die or a fork.

    • At 59 years old, statistically Mr. Stenn isn't going to live long enough to maintain NTP for another 30 years. Perhaps something so crucial should be a voluntary communal effort?

      From the sounds of it he wouldn't mind a bunch of young Turks with tons of relevant experience saying "Hey, I 'd like to help and am not only willing to do it for free but front some of the costs out of pocket. BTW, I'd love to put in some crazy hours at times where a critical patch needs to come out and get bitched at by people who didn't do anything to help but feel free to complain when they don't like what I did." As others point out, another issue is what happens when he stops doing this? Who takes ove

  • UI (Score:2, Troll)

    by ISoldat53 ( 977164 )
    Someone is dying to put a new UI on it.
  • by QuietLagoon ( 813062 ) on Thursday March 12, 2015 @09:26PM (#49247095)
    The summary makes the mistake of conflating the NTP protocol with the messy NTP software developed by ntp.org.

    .
    Hopefully the ntp.org software fades away.

    However, the Network Time Protocol should live on in more secure and more easily maintained implementations (e.g., NTimed and OpenNTPd).

    • I don't know much about NTP, other trying to implement it a few times and always end up scratching my head wondering why this is so hard? It's a fucking clock that just needs to be sycn'd. Why all the archiac hieroglyphic commands? Why not just a button that says sync with this server, with a status saying it's working or not? It doesn't need to be harder than that for most people.
      • ...

        You should look at OpenNTPd. Much, much easier to configure.

        .
        The config file on one of my servers has one line in it, the name of the server pool to sync to. With that one line config file, OpenNTPd syncs to the servers in the pool and does not open any ports for listening.

      • by dbIII ( 701233 ) on Thursday March 12, 2015 @11:50PM (#49247577)
        It's just a computer. It only has to work. How hard can it be?
        Wasn't that ridiculous
        NTP is also not trivial due to among many other things the large amount of clock drift on a lot of motherboards. If you had an alarm clock that lost an hour in a week you would throw it away, but that's seen as acceptable even for some server boards. So then you fetch the time but it takes time for the signal to get to you, so the time is out of date by the time you get it - which then means trying to work out how long it takes for the time signal to get to you. There's plenty more after that.
        • by itzly ( 3699663 )

          So then you fetch the time but it takes time for the signal to get to you, so the time is out of date by the time you get it

          Not a particularly hard problem. Take the round trip time, and divide by two. That should get you within a few ms. If you have special needs for better performance, get a cheap GPS unit and attach it to a local server.

          • Now add security, because if someone is spoofing the time they can really mess things up badly in a lot of ways.

          • > get a cheap GPS unit and attach it to a local server.

            Yes, I should buy 40,000 cheap GPS units. Actually, you know what? I'm going to ask Dell, HP and Intel to implement this. Oh crap, I can't, 'cause I can't get a GPS signal in a DC.

            You really didn't think about this too hard did you? People have been working at this for years, NTP does a heck of a lot of stuff to ensure that the clock is accurate, and how much you can trust the information you're given. NTP isn't a cheap hack, it's mathematically bril

  • 100 hours a week? (Score:4, Interesting)

    by Anonymous Coward on Thursday March 12, 2015 @09:33PM (#49247135)

    For the last three-and-a-half years, Stenn said he's worked 100-plus hours a week answering emails, accepting patches, rewriting patches to work across multiple operating systems, piecing together new releases, and administering the NTP mailing list.

    100 hours a week to maintain NTP? How much of that comes down to answering emails that maybe don't need to be answered? I have a ton of respect for Mr. Stenn, whose name, incidentally, I don't think I'd ever heard until today despite having two systems in pool.ntp.org for years and using NTP in or on nearly every device I've owned for two decades. But there's simply no way there's enough going on in NTP to generate 100 hours of work per week. I see the changelog [udel.edu] is active and fresh, but I still can't imagine those releases driving a "crunch time" developer schedule, week in and week out for 3+ years.

    I hope he backs away from the email before tossing in his hat entirely. Engaging random strangers in thoughtful discussion is probably consuming a lot more of his time than it needs to, and maybe more than he's noticing.

  • Serious question. Last time I worked with with a Windows network, time was set by the domain controller on login.

    I think, anyway. That was a long time ago.

    • by suutar ( 1860506 )

      yeah, on my personal laptop (not part of a domain) the Date and Time window has a tab named "Internet Time" that my work laptop doesn't. That's NTP (or was last time I actually dug into it), though their list of servers is kinda small.

    • Windows has done NTP since Windows XP. Before that you had to either ask the domain controller or use a third-party NTP utility.

    • MS uses it's SNTP which is the simplified version that just works for MS OS's on MS domains. This doesn't work if you have switches, routers or anything non-MS that you need accurate time for (which all use regular NTP).
    • Yes, ActiveDirectory time is synced via the NTP protocol.

      ActiveDirectory is a collection of protocols, most of which are based on public standards, NTP, LDAP, Kerberos, ect. Plenty of Microsoft Proprietary piled on top too.

      You can point any NTP client at an active directory server and sync from it, just like you can use it for a kerberos realm out of the box, and with Services for Unix installed on your AD server, the schema is extended to support the various Unix attributes required to use nss_ldap and pu

  • by tlambert ( 566799 ) on Thursday March 12, 2015 @09:53PM (#49247197)

    I have two problems with this article.

    (1) $7,000/month * 12 months + additional $12,000/year = $96,000/year, not including any other contributions that come into his non-profit on top of that.

    (2) Most of the need for NTP is driven by bad protocol design in client/server software.

    NFS, for example, would not need synchronized time if the client would include a "this is my idea of the current time" timestamp in time related requests, e.g. "set mtime".

    The server then does:

    (clients idea of current time) - (clients desired mtime) + (servers idea of current time) = mtime to set on server

    Voila: everything is consistent, clocks don't need synchronized between the client and the server.

    Bonus points: network latency adjustment is automatic; no need to go off and implement PTP to get an even more precise version of NTP.

    So most of this is a problem we've brought on ourselves by stupidly assuming a client and a server need synchronized time values in the first place, and then designing asinine protocol that build this assumption into the infrastructure built on top of those protocols.

    Maybe instead of making NTP more reliable - at a pretty high expense for the small town in Oregon where he lives, and the cost of living is relatively low - we should work to get the rest of our infrastructure away from being addicted to having a synchronized time base in the first place?

    PS: Yes, I brought this issue up in the IETF when NFSv4 was being designed in the first place.

    • by Trepidity ( 597 )

      Didn't the NFSv4 design decision to use Kerberos for authentication mean that some kind of time sync would be needed anyway whether NFS itself mandated it or not, since Kerberos relies on synchronized clocks?

    • Um, don't forget timezone, daylight savings, leap seconds etc...

      I think that the 'synchronized time base' thing becomes an issue with transaction processing, surely there are other issues as well what with it having been accepted as part of the environment for the past three decades

      • by gl4ss ( 559668 )

        time synchro service doesn't need to care about timezones, daylight savings or such.

        the client operating system needs to know it's relation to utc.

        • by jcdr ( 178250 )

          It would be a giant step forward if NTP will be able to broadcast TAI, the leap second table, and the timezone database.

          The leap second table and the timezone database are dynamic informations that need to be updated at least 2 times per years. You can arg that this can be done using the operating system upgrade, but the reality is that many machines will not be updated for whatever bad reasons. So carrying the informations using NTP (or PTP or GPS for that matter) will be an clear advantage.

    • we should work to get the rest of our infrastructure away from being addicted to having a synchronized time base in the first place?

      There are thousands of other uses for accurate clocks on computers besides NFSv4.

      • There are 3 types of time that matter to computers:

        (1) "Now" - which doesn't need time sync

        (2) "Relative to now" - which also does not need time sync

        (3) "Absolute time" -this one needs time sync, and is typically only an issue for calendaring and scheduling.

        If you're an astronomer, absolute time maters - or actually, "Local Apparent Sidereal Time", which also ties it to a specific longitude and latitude, so that you know where to point your telescope.

        Most applications of time on computers fall into category

        • by dAzED1 ( 33635 ) on Friday March 13, 2015 @12:47AM (#49247723) Journal
          I'm just staring at your comment and blinking, because...wow. Even if I ignore #1&2, #3..."and is typically only an issue for calendaring and scheduling." How about queuing? How about clustering? How about expiration of millions of things (tokens, certs, leases, etc). How about practically everything your computer is doing? Unless you're meaning to say that everything really does boil down to "calendaring" and "scheduling," and you're not just making some Outlook comment. If timing wasn't important, there wouldn't be circuits dedicated to keeping it, on practically every electronic device on the planet.
          • I'm just staring at your comment and blinking, because...wow. Even if I ignore #1&2, #3..."and is typically only an issue for calendaring and scheduling." How about queuing? How about clustering? How about expiration of millions of things (tokens, certs, leases, etc). How about practically everything your computer is doing? Unless you're meaning to say that everything really does boil down to "calendaring" and "scheduling," and you're not just making some Outlook comment. If timing wasn't important, there wouldn't be circuits dedicated to keeping it, on practically every electronic device on the planet.

            IT's not an issue for queueing; you enqueue things "now". So, for example, you could modify IBM's MQSeries, if you cared about time-ordering events, and either include the idea of "now" relative to the enqueue time, with another received timestamp on the system where the data was enqueued. This would work for ordering stock transactions, for example, because if your order gets there later than Bob's order, it doesn't matter: you lose.

            I'm uncertain how to respond on clustering; it would really depend on wh

    • I partially agree with the sentiment of point 1, but he does have fixed costs to consider. That 96K isn't just salary. Still, I'm not sure it constitutes being impoverished the way the article paints it

      On point 2 however, I think you are way off base. That statement really glosses over what it means to have synchronized time and why it is necessary. Two computers agreeing on the time between each other is not sufficient to be considered synchronized from a security perspective. To be synchronized for s

      • What kind of hole can be opened in a server due to a bad clock? Serious question.
        • Expired certificates may be presented as valid. Or, in a DOS scenario valid certificates may not be honored.
        • by arth1 ( 260657 )

          What kind of hole can be opened in a server due to a bad clock? Serious question.

          Non-expiry of certificates, tickets and other time-based credentials, for one thing.

          • Stuff dependant upon time of day, ACL restrictions, replay attacks of time based credentials (Tokens I guess in the previous post).

            Even log analysis across systems if the clocks in different systems are drifting faster and slower according the the temp of the system would be a major PITA.

            Let's not start looking at the consequences to financial exchanges (Expiring bond markets, matching trades across disparate systems), telephony (TDMA, billing systems), depending on how far you take it, train signalling, ai

    • The purpose of NTP is to accurately set the clock. There can be many reasons for this, not just network protocols that may depend on it. It may be that some people just like having the computer clock set with close to atomic clock accuracy. It is true that network protocols should be more resiliant to unsynchoronized clocks at either end, but this does NOT negate the need for NTP, since many use it to keep the computer clock accurate to have an accurate clock and not have to constantly readjust it, for thei

    • by dAzED1 ( 33635 ) on Friday March 13, 2015 @12:39AM (#49247699) Journal
      you, know - you're right. Instead of having a simple, lightweight protocol that keeps time accurate across the globe, to the tiniest portion of a second...we should have every single time-sensitive thing on every single machine everywhere re-write their own time service. That way, not only will everything suddenly become substantially more noisy, but risk factors will go through the roof and code complexity across all of the IT universe will dramatically increase! Or, we could just use the tiny, lightweight, extremely accurate tool that's been doing it very well for decades. Damn, such hard decisions...
      • you, know - you're right. Instead of having a simple, lightweight protocol that keeps time accurate across the globe, to the tiniest portion of a second...we should have every single time-sensitive thing on every single machine everywhere re-write their own time service. That way, not only will everything suddenly become substantially more noisy, but risk factors will go through the roof and code complexity across all of the IT universe will dramatically increase! Or, we could just use the tiny, lightweight, extremely accurate tool that's been doing it very well for decades. Damn, such hard decisions...

        How are you writing your own time service? You are sending deltas around.

        Nothing stops you from syncing your clocks if you want, but the main gist if the article was "OMG! NTP might have a vulnerability discovered! Better fund it more than the 100K a year the guy already gets, just in case!".

        If your protocols aren't time-sync fragile as shit, then it doesn't matter if you turn NTP off when/if a vulnerability is found, wait for a fix without your entire business going down because NTP is turned off, and th

    • " by stupidly assuming a client and a server need synchronized time values in the first place"

      Have you worked with Amazon S3?

      If your time is off by more than 15 minutes than Amazon's servers, you get a big ol fat rejection response saying your clocks arent sync.

  • At least accordingly to a comment of his on his latest blog entry.

    So I expect that the fate of NTP isn't so uncertain as all that, though whether Stenn himself will still be the lead is an open question.

    • ESR maintains gpsd, which ntpd can use as a clock source.

      His most recent time-related post is here [ibiblio.org], Introduction to Time Service. Before that, it was a gpsd release [ibiblio.org].

  • time_t has been 64 bits on every *nix system I've used for over a decade.

    Why in the name of any sanity at all would NTP not have been updated by now?

    • time_t has been 64 bits on every *nix system I've used for over a decade.

      all widely used 32-bit linux ports still have 32-bit time_t (x32 has 64-bit time_t but that is not widely used and it's debatable whether it counts as a 32-bit system). While x86-64 is taking over on the desktop and dedicated servers many embedded systems and low cost hosted vms are still 32-bit (the latter due to the lower memory footprint).

      Why in the name of any sanity at all would NTP not have been updated by now?

      Afaict it has, the NTP "DATE" format provides a 32-bit era number and a 32-bit era offset number which between them provide a 64-bit seconds count. The NTP "timestamp"

  • While each of those protocols have some advantages depending on the network availability, there all need to be upgraded to bring all the features required to make almost every applications happy.
    * NTP need to broadcast TAI time, leap second table and timezone database.
    * PTP need to broadcast lead second table, and timezone database.
    * GPS need to broadcast at least the leap second table (serialized into a few bits over a long period), timezone database will probably be too big.

    The TAI time is required to eve

Some people only open up to tell you that they're closed.

Working...