chrony vs. systemd-timesyncd – What are the differences and use cases as NTP clients?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












12















Somehow but not quite building upon the older question "ntpd vs. systemd-timesyncd - How to achieve reliable NTP syncing?", I'd like to ask about the differences between chrony and systemd-timesyncd in terms of an NTP client.



I know that systemd-timesyncd is a more or less minimal ntp client implementation whereas chrony is a full fledged NTP daemon solution that happens to include an NTP client.



The ubuntu Bionic Beaver release notes state the following:




For simple time sync needs the base system already comes with systemd-timesyncd. Chrony is only needed to act as a time server or if you want the advertised more accurate and efficient syncing.




I like the idea of using a minimal preinstalled tool to do the job and I am pretty sure systemd-timesyncd will do the job for my use cases, still I am curious:



  • What are the real world differences between the two in terms of accuracy?

  • What are the differences in efficiency?

  • What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?









share|improve this question


























    12















    Somehow but not quite building upon the older question "ntpd vs. systemd-timesyncd - How to achieve reliable NTP syncing?", I'd like to ask about the differences between chrony and systemd-timesyncd in terms of an NTP client.



    I know that systemd-timesyncd is a more or less minimal ntp client implementation whereas chrony is a full fledged NTP daemon solution that happens to include an NTP client.



    The ubuntu Bionic Beaver release notes state the following:




    For simple time sync needs the base system already comes with systemd-timesyncd. Chrony is only needed to act as a time server or if you want the advertised more accurate and efficient syncing.




    I like the idea of using a minimal preinstalled tool to do the job and I am pretty sure systemd-timesyncd will do the job for my use cases, still I am curious:



    • What are the real world differences between the two in terms of accuracy?

    • What are the differences in efficiency?

    • What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?









    share|improve this question
























      12












      12








      12








      Somehow but not quite building upon the older question "ntpd vs. systemd-timesyncd - How to achieve reliable NTP syncing?", I'd like to ask about the differences between chrony and systemd-timesyncd in terms of an NTP client.



      I know that systemd-timesyncd is a more or less minimal ntp client implementation whereas chrony is a full fledged NTP daemon solution that happens to include an NTP client.



      The ubuntu Bionic Beaver release notes state the following:




      For simple time sync needs the base system already comes with systemd-timesyncd. Chrony is only needed to act as a time server or if you want the advertised more accurate and efficient syncing.




      I like the idea of using a minimal preinstalled tool to do the job and I am pretty sure systemd-timesyncd will do the job for my use cases, still I am curious:



      • What are the real world differences between the two in terms of accuracy?

      • What are the differences in efficiency?

      • What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?









      share|improve this question














      Somehow but not quite building upon the older question "ntpd vs. systemd-timesyncd - How to achieve reliable NTP syncing?", I'd like to ask about the differences between chrony and systemd-timesyncd in terms of an NTP client.



      I know that systemd-timesyncd is a more or less minimal ntp client implementation whereas chrony is a full fledged NTP daemon solution that happens to include an NTP client.



      The ubuntu Bionic Beaver release notes state the following:




      For simple time sync needs the base system already comes with systemd-timesyncd. Chrony is only needed to act as a time server or if you want the advertised more accurate and efficient syncing.




      I like the idea of using a minimal preinstalled tool to do the job and I am pretty sure systemd-timesyncd will do the job for my use cases, still I am curious:



      • What are the real world differences between the two in terms of accuracy?

      • What are the differences in efficiency?

      • What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?






      systemd ntp chrony






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Mar 4 at 23:46









      wediwedi

      1636




      1636




















          2 Answers
          2






          active

          oldest

          votes


















          8














          The announcement of systemd-timesyncd in the systemd NEWS file does a good job of explaining the differences of this tool in comparison with Chrony and tools like it. (emphasis mine):




          A new "systemd-timesyncd" daemon has been added for
          synchronizing the system clock across the network. It
          implements an SNTP client. In contrast to NTP
          implementations such as chrony or the NTP reference server
          this only implements a client side, and does not bother with
          the full NTP complexity, focusing only on querying time from
          one remote server and synchronizing the local clock to
          it
          . Unless you intend to serve NTP to networked clients or
          want to connect to local hardware clocks this simple NTP
          client should be more than appropriate for most
          installations. [...]




          This setup is a common use case for most hosts in a server fleet. They will usually get synchronized from local NTP servers, which themselves get synchronized from multiple sources, possibly including hardware. systemd-timesyncd tries to provide an easy-to-use solution for that common use case.




          Trying to address your specific questions:




          What are the real world differences between the two in terms of accuracy?




          I believe you can get higher accuracy by getting synchronization data from multiple sources, which is specifically not a supported use case for systemd-timesyncd. But when you're using it to get synchronization data from central NTP servers connected to your reliable internal network, using multiple sources isn't really that relevant and you get good accuracy from a single source.



          If you're synchronizing your server from a trusted server in a local network and in the same datacenter, the difference in accuracy between NTP and SNTP will be virtually non-existent. NTP can take RTT into account and do timesmearing, but that's not that beneficial when your RTT is really small, which is the case of a fast local network and a nearby machine. You also don't need multiple sources if you can trust the one you're using.




          What are the differences in efficiency?




          Getting synchronization from a single source is much simpler than getting it from multiple sources, since you don't have to make decisions about which sources are better than others and possibly combine information from multiple sources. The algorithms are much simpler and will require less CPU load for the simple case.




          What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?




          That's addressed in the quote above, but in any case these are use cases for Chrony that are not covered by systemd-timesyncd:



          • running NTP server (so that other hosts can use this host as a source for synchrnoization);

          • getting NTP synchronization information from multiple sources (which is important for hosts getting that information from public servers on the Internet); and

          • getting synchronization information from the local clock, which usually involves specialized hardware such as GPS devices which can get accurate time information from satellites.

          These use cases require Chrony or ntpd or similar.






          share|improve this answer




















          • 1





            Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

            – wedi
            Mar 5 at 11:47







          • 2





            @wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

            – TooTea
            Mar 5 at 12:19






          • 1





            Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

            – wedi
            Mar 5 at 12:56











          • I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

            – filbranden
            Mar 5 at 13:01











          • @wedi Updated the answer to explicitly mention using a trusted server on a local network.

            – filbranden
            Mar 5 at 13:49


















          10














          As the other answer correctly states, chrony implements NTP and systemd-timesyncd SNTP.



          From the point of view of a time service client:



          SNTP is a much more simple protocol to implement;

          NTP allows for step-by-step increments/corrections on time. One major advantage of NTP is that it also takes on account the RTT of the answer to get a more exact time.



          From https://www.meinbergglobal.com/english/faq/faq_37.htm




          While a full featured NTP server or client reaches a very high level
          of accuracy and avoids abrupt time steps as much as possible by using
          different mathematical and statistical methods and smooth clock speed
          adjustments, SNTP can only be recommended for simple applications,
          where the requirements for accuracy and reliability are not too
          demanding. By disregarding drift values and using simplified ways of
          system clock adjustment methods (often simple time stepping), SNTP
          achieves only a low quality time synchronisation when compared with a
          full NTP implementation.



          SNTP adopts a much simpler approach. Many of the complexities of the
          NTP algorithm are removed. Rather than skewing time, many SNTP clients
          step time. This is fine for many applications where a simple
          time-stamp is required. Additionally, SNTP lacks the ability to
          monitor and filter multiple NTP servers. Often a simple round-robin
          approach is used, where if one server fails, the next one in a list is
          used




          From https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp




          NTP is far more accurate and precise than SNTP, and this makes it the
          de facto winner in most enterprise applications. On the other hand,
          the simplicity of SNTP makes it more appropriate for things like IP
          cameras, DVRs and some network switches. These types of hardware lack
          the processing resources to handle more complex protocols, but as
          connected devices become increasingly powerful, that may change.



          One major weak point of SNTP is that you can't make it more accurate
          by retrieving time from multiple sources like Network Time Protocol does by default.




          One other major point I can see SNTP implementations giving more problems than NTP is in virtualisation, when you have both the hypervisor and NTP daemon trying to change the VM time. Specially with them not agreeing on time with some misconfiguration causes them to be both active, it might cause big problems. (Whilst competent system administrators will only keep active one method for synchronisation with time, it can happen they are both active by a configuration error).



          P.S. systemd-timesyncd should not be an advised alternative when not using systemd.






          share|improve this answer




















          • 1





            It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

            – JdeBP
            Mar 5 at 8:50












          • @JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

            – Rui F Ribeiro
            Mar 5 at 9:41












          • (edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

            – Rui F Ribeiro
            Mar 5 at 9:43







          • 1





            @wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

            – Rui F Ribeiro
            Mar 5 at 12:03







          • 1





            I am glad you pointed out the possible time sync race! Good to keep this in mind!

            – wedi
            Mar 5 at 22:14











          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504381%2fchrony-vs-systemd-timesyncd-what-are-the-differences-and-use-cases-as-ntp-cli%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          8














          The announcement of systemd-timesyncd in the systemd NEWS file does a good job of explaining the differences of this tool in comparison with Chrony and tools like it. (emphasis mine):




          A new "systemd-timesyncd" daemon has been added for
          synchronizing the system clock across the network. It
          implements an SNTP client. In contrast to NTP
          implementations such as chrony or the NTP reference server
          this only implements a client side, and does not bother with
          the full NTP complexity, focusing only on querying time from
          one remote server and synchronizing the local clock to
          it
          . Unless you intend to serve NTP to networked clients or
          want to connect to local hardware clocks this simple NTP
          client should be more than appropriate for most
          installations. [...]




          This setup is a common use case for most hosts in a server fleet. They will usually get synchronized from local NTP servers, which themselves get synchronized from multiple sources, possibly including hardware. systemd-timesyncd tries to provide an easy-to-use solution for that common use case.




          Trying to address your specific questions:




          What are the real world differences between the two in terms of accuracy?




          I believe you can get higher accuracy by getting synchronization data from multiple sources, which is specifically not a supported use case for systemd-timesyncd. But when you're using it to get synchronization data from central NTP servers connected to your reliable internal network, using multiple sources isn't really that relevant and you get good accuracy from a single source.



          If you're synchronizing your server from a trusted server in a local network and in the same datacenter, the difference in accuracy between NTP and SNTP will be virtually non-existent. NTP can take RTT into account and do timesmearing, but that's not that beneficial when your RTT is really small, which is the case of a fast local network and a nearby machine. You also don't need multiple sources if you can trust the one you're using.




          What are the differences in efficiency?




          Getting synchronization from a single source is much simpler than getting it from multiple sources, since you don't have to make decisions about which sources are better than others and possibly combine information from multiple sources. The algorithms are much simpler and will require less CPU load for the simple case.




          What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?




          That's addressed in the quote above, but in any case these are use cases for Chrony that are not covered by systemd-timesyncd:



          • running NTP server (so that other hosts can use this host as a source for synchrnoization);

          • getting NTP synchronization information from multiple sources (which is important for hosts getting that information from public servers on the Internet); and

          • getting synchronization information from the local clock, which usually involves specialized hardware such as GPS devices which can get accurate time information from satellites.

          These use cases require Chrony or ntpd or similar.






          share|improve this answer




















          • 1





            Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

            – wedi
            Mar 5 at 11:47







          • 2





            @wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

            – TooTea
            Mar 5 at 12:19






          • 1





            Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

            – wedi
            Mar 5 at 12:56











          • I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

            – filbranden
            Mar 5 at 13:01











          • @wedi Updated the answer to explicitly mention using a trusted server on a local network.

            – filbranden
            Mar 5 at 13:49















          8














          The announcement of systemd-timesyncd in the systemd NEWS file does a good job of explaining the differences of this tool in comparison with Chrony and tools like it. (emphasis mine):




          A new "systemd-timesyncd" daemon has been added for
          synchronizing the system clock across the network. It
          implements an SNTP client. In contrast to NTP
          implementations such as chrony or the NTP reference server
          this only implements a client side, and does not bother with
          the full NTP complexity, focusing only on querying time from
          one remote server and synchronizing the local clock to
          it
          . Unless you intend to serve NTP to networked clients or
          want to connect to local hardware clocks this simple NTP
          client should be more than appropriate for most
          installations. [...]




          This setup is a common use case for most hosts in a server fleet. They will usually get synchronized from local NTP servers, which themselves get synchronized from multiple sources, possibly including hardware. systemd-timesyncd tries to provide an easy-to-use solution for that common use case.




          Trying to address your specific questions:




          What are the real world differences between the two in terms of accuracy?




          I believe you can get higher accuracy by getting synchronization data from multiple sources, which is specifically not a supported use case for systemd-timesyncd. But when you're using it to get synchronization data from central NTP servers connected to your reliable internal network, using multiple sources isn't really that relevant and you get good accuracy from a single source.



          If you're synchronizing your server from a trusted server in a local network and in the same datacenter, the difference in accuracy between NTP and SNTP will be virtually non-existent. NTP can take RTT into account and do timesmearing, but that's not that beneficial when your RTT is really small, which is the case of a fast local network and a nearby machine. You also don't need multiple sources if you can trust the one you're using.




          What are the differences in efficiency?




          Getting synchronization from a single source is much simpler than getting it from multiple sources, since you don't have to make decisions about which sources are better than others and possibly combine information from multiple sources. The algorithms are much simpler and will require less CPU load for the simple case.




          What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?




          That's addressed in the quote above, but in any case these are use cases for Chrony that are not covered by systemd-timesyncd:



          • running NTP server (so that other hosts can use this host as a source for synchrnoization);

          • getting NTP synchronization information from multiple sources (which is important for hosts getting that information from public servers on the Internet); and

          • getting synchronization information from the local clock, which usually involves specialized hardware such as GPS devices which can get accurate time information from satellites.

          These use cases require Chrony or ntpd or similar.






          share|improve this answer




















          • 1





            Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

            – wedi
            Mar 5 at 11:47







          • 2





            @wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

            – TooTea
            Mar 5 at 12:19






          • 1





            Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

            – wedi
            Mar 5 at 12:56











          • I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

            – filbranden
            Mar 5 at 13:01











          • @wedi Updated the answer to explicitly mention using a trusted server on a local network.

            – filbranden
            Mar 5 at 13:49













          8












          8








          8







          The announcement of systemd-timesyncd in the systemd NEWS file does a good job of explaining the differences of this tool in comparison with Chrony and tools like it. (emphasis mine):




          A new "systemd-timesyncd" daemon has been added for
          synchronizing the system clock across the network. It
          implements an SNTP client. In contrast to NTP
          implementations such as chrony or the NTP reference server
          this only implements a client side, and does not bother with
          the full NTP complexity, focusing only on querying time from
          one remote server and synchronizing the local clock to
          it
          . Unless you intend to serve NTP to networked clients or
          want to connect to local hardware clocks this simple NTP
          client should be more than appropriate for most
          installations. [...]




          This setup is a common use case for most hosts in a server fleet. They will usually get synchronized from local NTP servers, which themselves get synchronized from multiple sources, possibly including hardware. systemd-timesyncd tries to provide an easy-to-use solution for that common use case.




          Trying to address your specific questions:




          What are the real world differences between the two in terms of accuracy?




          I believe you can get higher accuracy by getting synchronization data from multiple sources, which is specifically not a supported use case for systemd-timesyncd. But when you're using it to get synchronization data from central NTP servers connected to your reliable internal network, using multiple sources isn't really that relevant and you get good accuracy from a single source.



          If you're synchronizing your server from a trusted server in a local network and in the same datacenter, the difference in accuracy between NTP and SNTP will be virtually non-existent. NTP can take RTT into account and do timesmearing, but that's not that beneficial when your RTT is really small, which is the case of a fast local network and a nearby machine. You also don't need multiple sources if you can trust the one you're using.




          What are the differences in efficiency?




          Getting synchronization from a single source is much simpler than getting it from multiple sources, since you don't have to make decisions about which sources are better than others and possibly combine information from multiple sources. The algorithms are much simpler and will require less CPU load for the simple case.




          What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?




          That's addressed in the quote above, but in any case these are use cases for Chrony that are not covered by systemd-timesyncd:



          • running NTP server (so that other hosts can use this host as a source for synchrnoization);

          • getting NTP synchronization information from multiple sources (which is important for hosts getting that information from public servers on the Internet); and

          • getting synchronization information from the local clock, which usually involves specialized hardware such as GPS devices which can get accurate time information from satellites.

          These use cases require Chrony or ntpd or similar.






          share|improve this answer















          The announcement of systemd-timesyncd in the systemd NEWS file does a good job of explaining the differences of this tool in comparison with Chrony and tools like it. (emphasis mine):




          A new "systemd-timesyncd" daemon has been added for
          synchronizing the system clock across the network. It
          implements an SNTP client. In contrast to NTP
          implementations such as chrony or the NTP reference server
          this only implements a client side, and does not bother with
          the full NTP complexity, focusing only on querying time from
          one remote server and synchronizing the local clock to
          it
          . Unless you intend to serve NTP to networked clients or
          want to connect to local hardware clocks this simple NTP
          client should be more than appropriate for most
          installations. [...]




          This setup is a common use case for most hosts in a server fleet. They will usually get synchronized from local NTP servers, which themselves get synchronized from multiple sources, possibly including hardware. systemd-timesyncd tries to provide an easy-to-use solution for that common use case.




          Trying to address your specific questions:




          What are the real world differences between the two in terms of accuracy?




          I believe you can get higher accuracy by getting synchronization data from multiple sources, which is specifically not a supported use case for systemd-timesyncd. But when you're using it to get synchronization data from central NTP servers connected to your reliable internal network, using multiple sources isn't really that relevant and you get good accuracy from a single source.



          If you're synchronizing your server from a trusted server in a local network and in the same datacenter, the difference in accuracy between NTP and SNTP will be virtually non-existent. NTP can take RTT into account and do timesmearing, but that's not that beneficial when your RTT is really small, which is the case of a fast local network and a nearby machine. You also don't need multiple sources if you can trust the one you're using.




          What are the differences in efficiency?




          Getting synchronization from a single source is much simpler than getting it from multiple sources, since you don't have to make decisions about which sources are better than others and possibly combine information from multiple sources. The algorithms are much simpler and will require less CPU load for the simple case.




          What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?




          That's addressed in the quote above, but in any case these are use cases for Chrony that are not covered by systemd-timesyncd:



          • running NTP server (so that other hosts can use this host as a source for synchrnoization);

          • getting NTP synchronization information from multiple sources (which is important for hosts getting that information from public servers on the Internet); and

          • getting synchronization information from the local clock, which usually involves specialized hardware such as GPS devices which can get accurate time information from satellites.

          These use cases require Chrony or ntpd or similar.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 5 at 13:48

























          answered Mar 5 at 0:27









          filbrandenfilbranden

          10.7k21847




          10.7k21847







          • 1





            Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

            – wedi
            Mar 5 at 11:47







          • 2





            @wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

            – TooTea
            Mar 5 at 12:19






          • 1





            Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

            – wedi
            Mar 5 at 12:56











          • I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

            – filbranden
            Mar 5 at 13:01











          • @wedi Updated the answer to explicitly mention using a trusted server on a local network.

            – filbranden
            Mar 5 at 13:49












          • 1





            Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

            – wedi
            Mar 5 at 11:47







          • 2





            @wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

            – TooTea
            Mar 5 at 12:19






          • 1





            Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

            – wedi
            Mar 5 at 12:56











          • I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

            – filbranden
            Mar 5 at 13:01











          • @wedi Updated the answer to explicitly mention using a trusted server on a local network.

            – filbranden
            Mar 5 at 13:49







          1




          1





          Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

          – wedi
          Mar 5 at 11:47






          Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

          – wedi
          Mar 5 at 11:47





          2




          2





          @wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

          – TooTea
          Mar 5 at 12:19





          @wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

          – TooTea
          Mar 5 at 12:19




          1




          1





          Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

          – wedi
          Mar 5 at 12:56





          Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

          – wedi
          Mar 5 at 12:56













          I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

          – filbranden
          Mar 5 at 13:01





          I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

          – filbranden
          Mar 5 at 13:01













          @wedi Updated the answer to explicitly mention using a trusted server on a local network.

          – filbranden
          Mar 5 at 13:49





          @wedi Updated the answer to explicitly mention using a trusted server on a local network.

          – filbranden
          Mar 5 at 13:49













          10














          As the other answer correctly states, chrony implements NTP and systemd-timesyncd SNTP.



          From the point of view of a time service client:



          SNTP is a much more simple protocol to implement;

          NTP allows for step-by-step increments/corrections on time. One major advantage of NTP is that it also takes on account the RTT of the answer to get a more exact time.



          From https://www.meinbergglobal.com/english/faq/faq_37.htm




          While a full featured NTP server or client reaches a very high level
          of accuracy and avoids abrupt time steps as much as possible by using
          different mathematical and statistical methods and smooth clock speed
          adjustments, SNTP can only be recommended for simple applications,
          where the requirements for accuracy and reliability are not too
          demanding. By disregarding drift values and using simplified ways of
          system clock adjustment methods (often simple time stepping), SNTP
          achieves only a low quality time synchronisation when compared with a
          full NTP implementation.



          SNTP adopts a much simpler approach. Many of the complexities of the
          NTP algorithm are removed. Rather than skewing time, many SNTP clients
          step time. This is fine for many applications where a simple
          time-stamp is required. Additionally, SNTP lacks the ability to
          monitor and filter multiple NTP servers. Often a simple round-robin
          approach is used, where if one server fails, the next one in a list is
          used




          From https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp




          NTP is far more accurate and precise than SNTP, and this makes it the
          de facto winner in most enterprise applications. On the other hand,
          the simplicity of SNTP makes it more appropriate for things like IP
          cameras, DVRs and some network switches. These types of hardware lack
          the processing resources to handle more complex protocols, but as
          connected devices become increasingly powerful, that may change.



          One major weak point of SNTP is that you can't make it more accurate
          by retrieving time from multiple sources like Network Time Protocol does by default.




          One other major point I can see SNTP implementations giving more problems than NTP is in virtualisation, when you have both the hypervisor and NTP daemon trying to change the VM time. Specially with them not agreeing on time with some misconfiguration causes them to be both active, it might cause big problems. (Whilst competent system administrators will only keep active one method for synchronisation with time, it can happen they are both active by a configuration error).



          P.S. systemd-timesyncd should not be an advised alternative when not using systemd.






          share|improve this answer




















          • 1





            It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

            – JdeBP
            Mar 5 at 8:50












          • @JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

            – Rui F Ribeiro
            Mar 5 at 9:41












          • (edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

            – Rui F Ribeiro
            Mar 5 at 9:43







          • 1





            @wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

            – Rui F Ribeiro
            Mar 5 at 12:03







          • 1





            I am glad you pointed out the possible time sync race! Good to keep this in mind!

            – wedi
            Mar 5 at 22:14















          10














          As the other answer correctly states, chrony implements NTP and systemd-timesyncd SNTP.



          From the point of view of a time service client:



          SNTP is a much more simple protocol to implement;

          NTP allows for step-by-step increments/corrections on time. One major advantage of NTP is that it also takes on account the RTT of the answer to get a more exact time.



          From https://www.meinbergglobal.com/english/faq/faq_37.htm




          While a full featured NTP server or client reaches a very high level
          of accuracy and avoids abrupt time steps as much as possible by using
          different mathematical and statistical methods and smooth clock speed
          adjustments, SNTP can only be recommended for simple applications,
          where the requirements for accuracy and reliability are not too
          demanding. By disregarding drift values and using simplified ways of
          system clock adjustment methods (often simple time stepping), SNTP
          achieves only a low quality time synchronisation when compared with a
          full NTP implementation.



          SNTP adopts a much simpler approach. Many of the complexities of the
          NTP algorithm are removed. Rather than skewing time, many SNTP clients
          step time. This is fine for many applications where a simple
          time-stamp is required. Additionally, SNTP lacks the ability to
          monitor and filter multiple NTP servers. Often a simple round-robin
          approach is used, where if one server fails, the next one in a list is
          used




          From https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp




          NTP is far more accurate and precise than SNTP, and this makes it the
          de facto winner in most enterprise applications. On the other hand,
          the simplicity of SNTP makes it more appropriate for things like IP
          cameras, DVRs and some network switches. These types of hardware lack
          the processing resources to handle more complex protocols, but as
          connected devices become increasingly powerful, that may change.



          One major weak point of SNTP is that you can't make it more accurate
          by retrieving time from multiple sources like Network Time Protocol does by default.




          One other major point I can see SNTP implementations giving more problems than NTP is in virtualisation, when you have both the hypervisor and NTP daemon trying to change the VM time. Specially with them not agreeing on time with some misconfiguration causes them to be both active, it might cause big problems. (Whilst competent system administrators will only keep active one method for synchronisation with time, it can happen they are both active by a configuration error).



          P.S. systemd-timesyncd should not be an advised alternative when not using systemd.






          share|improve this answer




















          • 1





            It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

            – JdeBP
            Mar 5 at 8:50












          • @JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

            – Rui F Ribeiro
            Mar 5 at 9:41












          • (edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

            – Rui F Ribeiro
            Mar 5 at 9:43







          • 1





            @wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

            – Rui F Ribeiro
            Mar 5 at 12:03







          • 1





            I am glad you pointed out the possible time sync race! Good to keep this in mind!

            – wedi
            Mar 5 at 22:14













          10












          10








          10







          As the other answer correctly states, chrony implements NTP and systemd-timesyncd SNTP.



          From the point of view of a time service client:



          SNTP is a much more simple protocol to implement;

          NTP allows for step-by-step increments/corrections on time. One major advantage of NTP is that it also takes on account the RTT of the answer to get a more exact time.



          From https://www.meinbergglobal.com/english/faq/faq_37.htm




          While a full featured NTP server or client reaches a very high level
          of accuracy and avoids abrupt time steps as much as possible by using
          different mathematical and statistical methods and smooth clock speed
          adjustments, SNTP can only be recommended for simple applications,
          where the requirements for accuracy and reliability are not too
          demanding. By disregarding drift values and using simplified ways of
          system clock adjustment methods (often simple time stepping), SNTP
          achieves only a low quality time synchronisation when compared with a
          full NTP implementation.



          SNTP adopts a much simpler approach. Many of the complexities of the
          NTP algorithm are removed. Rather than skewing time, many SNTP clients
          step time. This is fine for many applications where a simple
          time-stamp is required. Additionally, SNTP lacks the ability to
          monitor and filter multiple NTP servers. Often a simple round-robin
          approach is used, where if one server fails, the next one in a list is
          used




          From https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp




          NTP is far more accurate and precise than SNTP, and this makes it the
          de facto winner in most enterprise applications. On the other hand,
          the simplicity of SNTP makes it more appropriate for things like IP
          cameras, DVRs and some network switches. These types of hardware lack
          the processing resources to handle more complex protocols, but as
          connected devices become increasingly powerful, that may change.



          One major weak point of SNTP is that you can't make it more accurate
          by retrieving time from multiple sources like Network Time Protocol does by default.




          One other major point I can see SNTP implementations giving more problems than NTP is in virtualisation, when you have both the hypervisor and NTP daemon trying to change the VM time. Specially with them not agreeing on time with some misconfiguration causes them to be both active, it might cause big problems. (Whilst competent system administrators will only keep active one method for synchronisation with time, it can happen they are both active by a configuration error).



          P.S. systemd-timesyncd should not be an advised alternative when not using systemd.






          share|improve this answer















          As the other answer correctly states, chrony implements NTP and systemd-timesyncd SNTP.



          From the point of view of a time service client:



          SNTP is a much more simple protocol to implement;

          NTP allows for step-by-step increments/corrections on time. One major advantage of NTP is that it also takes on account the RTT of the answer to get a more exact time.



          From https://www.meinbergglobal.com/english/faq/faq_37.htm




          While a full featured NTP server or client reaches a very high level
          of accuracy and avoids abrupt time steps as much as possible by using
          different mathematical and statistical methods and smooth clock speed
          adjustments, SNTP can only be recommended for simple applications,
          where the requirements for accuracy and reliability are not too
          demanding. By disregarding drift values and using simplified ways of
          system clock adjustment methods (often simple time stepping), SNTP
          achieves only a low quality time synchronisation when compared with a
          full NTP implementation.



          SNTP adopts a much simpler approach. Many of the complexities of the
          NTP algorithm are removed. Rather than skewing time, many SNTP clients
          step time. This is fine for many applications where a simple
          time-stamp is required. Additionally, SNTP lacks the ability to
          monitor and filter multiple NTP servers. Often a simple round-robin
          approach is used, where if one server fails, the next one in a list is
          used




          From https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp




          NTP is far more accurate and precise than SNTP, and this makes it the
          de facto winner in most enterprise applications. On the other hand,
          the simplicity of SNTP makes it more appropriate for things like IP
          cameras, DVRs and some network switches. These types of hardware lack
          the processing resources to handle more complex protocols, but as
          connected devices become increasingly powerful, that may change.



          One major weak point of SNTP is that you can't make it more accurate
          by retrieving time from multiple sources like Network Time Protocol does by default.




          One other major point I can see SNTP implementations giving more problems than NTP is in virtualisation, when you have both the hypervisor and NTP daemon trying to change the VM time. Specially with them not agreeing on time with some misconfiguration causes them to be both active, it might cause big problems. (Whilst competent system administrators will only keep active one method for synchronisation with time, it can happen they are both active by a configuration error).



          P.S. systemd-timesyncd should not be an advised alternative when not using systemd.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 5 at 9:41

























          answered Mar 5 at 0:58









          Rui F RibeiroRui F Ribeiro

          41.8k1483142




          41.8k1483142







          • 1





            It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

            – JdeBP
            Mar 5 at 8:50












          • @JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

            – Rui F Ribeiro
            Mar 5 at 9:41












          • (edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

            – Rui F Ribeiro
            Mar 5 at 9:43







          • 1





            @wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

            – Rui F Ribeiro
            Mar 5 at 12:03







          • 1





            I am glad you pointed out the possible time sync race! Good to keep this in mind!

            – wedi
            Mar 5 at 22:14












          • 1





            It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

            – JdeBP
            Mar 5 at 8:50












          • @JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

            – Rui F Ribeiro
            Mar 5 at 9:41












          • (edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

            – Rui F Ribeiro
            Mar 5 at 9:43







          • 1





            @wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

            – Rui F Ribeiro
            Mar 5 at 12:03







          • 1





            I am glad you pointed out the possible time sync race! Good to keep this in mind!

            – wedi
            Mar 5 at 22:14







          1




          1





          It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

          – JdeBP
          Mar 5 at 8:50






          It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

          – JdeBP
          Mar 5 at 8:50














          @JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

          – Rui F Ribeiro
          Mar 5 at 9:41






          @JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

          – Rui F Ribeiro
          Mar 5 at 9:41














          (edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

          – Rui F Ribeiro
          Mar 5 at 9:43






          (edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

          – Rui F Ribeiro
          Mar 5 at 9:43





          1




          1





          @wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

          – Rui F Ribeiro
          Mar 5 at 12:03






          @wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

          – Rui F Ribeiro
          Mar 5 at 12:03





          1




          1





          I am glad you pointed out the possible time sync race! Good to keep this in mind!

          – wedi
          Mar 5 at 22:14





          I am glad you pointed out the possible time sync race! Good to keep this in mind!

          – wedi
          Mar 5 at 22:14

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504381%2fchrony-vs-systemd-timesyncd-what-are-the-differences-and-use-cases-as-ntp-cli%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown






          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?