0

I paused the virtual machine on the VM and disconnected its internet connection without rebooting the system. When I started the system from sleep mode without rebooting, the system clock continued where it left off and could not show the correct time? What will I do in such a situation?

  • my time data for the hour before I paused my virtual machine (it is also real time for my host)

% chronyc sourcestats
---------------------
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
131.153.171.22              6   4   139 -46792.738  67288.219   -326ms   890ms
108.175.15.67               6   3   140 -44764.793  61909.766   -188ms   961ms
gopher.fart.website         6   3   140 -49022.652  84747.266   -217ms  1224ms
edge-iad.txryan.com         6   3   139 -45642.164  67798.562   -230ms  1032ms


% chronyc tracking
------------------
Reference ID    : 8399AB16 (131.153.171.22)
Stratum         : 3
Ref time (UTC)  : Mon Dec 25 09:55:11 2023
System time     : 0.000000000 seconds slow of NTP time
Last offset     : -5.681410313 seconds
RMS offset      : 1.796643019 seconds
Frequency       : 5.307 ppm fast
Residual freq   : -46792.738 ppm
Skew            : 8.997 ppm
Root delay      : 0.147369087 seconds
Root dispersion : 0.769112766 seconds
Update interval : 7.0 seconds
Leap status     : Normal

% date
-----------------
Mon Dec 25 12:55:18 PM +03 2023

% hwclock
-----------------
2023-12-25 12:55:13.078474+03:00
  • After disconnecting from the internet, I waited for a while and then when I opened the VM, the clock did not show the correct time. Also, when I get this output; my real host date (Monday, December 25, 2023 1:28:58 PM)

(in short, when I disconnected the internet connection and started the system again, it could not be started synchronously with the time of my main host.)

% chronyc sourcestats
---------------------
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
131.153.171.22              6   4   139 -46792.738  67288.219  -5592ms   890ms
108.175.15.67               6   3   140 -44764.793  61909.766  -5226ms   961ms
gopher.fart.website         6   3   140 -49022.652  84747.266  -5734ms  1224ms
edge-iad.txryan.com         6   3   139 -45642.164  67798.562  -5367ms  1032ms

% chronyc tracking
------------------
Reference ID    : 8399AB16 (131.153.171.22)
Stratum         : 3
Ref time (UTC)  : Mon Dec 25 09:55:11 2023
System time     : 0.000000000 seconds fast of NTP time
Last offset     : -5.681410313 seconds
RMS offset      : 1.796643019 seconds
Frequency       : 5.307 ppm fast
Residual freq   : -46792.738 ppm
Skew            : 8.997 ppm
Root delay      : 0.147369087 seconds
Root dispersion : 6.036798477 seconds
Update interval : 7.0 seconds
Leap status     : Normal

% date
-----------------
Mon Dec 25 12:57:11 PM +03 2023

% hwclock
-----------------
2023-12-25 12:57:05.629692+03:00
  • After Internet Connection

Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
131.153.171.22              6   4   343   -5616574     341926   -1958s   15.7s
108.175.15.67               6   4   343   -5631052     251508   -1960s   12.1s
gopher.fart.website         6   4   343   -5618134     301975   -1963s   14.2s
edge-iad.txryan.com         6   4   343   -5635317     275298   -1964s   13.2s

Reference ID    : 8399AB16 (131.153.171.22)
Stratum         : 3
Ref time (UTC)  : Mon Dec 25 09:55:11 2023
System time     : 0.000000001 seconds fast of NTP time
Last offset     : -5.681410313 seconds
RMS offset      : 1.796643019 seconds
Frequency       : 5.307 ppm fast
Residual freq   : -46792.738 ppm
Skew            : 8.997 ppm
Root delay      : 0.147369087 seconds
Root dispersion : 16.738962173 seconds
Update interval : 7.0 seconds
Leap status     : Normal

Mon Dec 25 01:01:00 PM +03 2023
2023-12-25 13:01:00.293480+03:00

Also, How often does my system time refresh via Chrony? When the system is turned on or as long as it is connected to the internet? How can I set this?

10
  • 1
    Show us your observations, e.g. output from date and other commands. When you pause a VM, time stops elapsing for it. What is your complaint? Upon resuming it takes more than K seconds for chrony to send a time query? chrony behaves differently from ntpd? ntpdate showed an odd response? Guest OS in the VM didn't ask the hypervisor for the current time? Something else?
    – J_H
    Dec 24, 2023 at 3:01
  • ok, now, I added more details about it @J_H In fact, in short My Guest OS on the VM didn't ask the hypervisor for the current time. Dec 24, 2023 at 9:28
  • You possibly did not take into account what I had written in my answer to your other question unix.stackexchange.com/questions/765252/… about setting the time on a VM ? (extremely high skews which is precisely what you show)
    – MC68020
    Dec 24, 2023 at 9:33
  • I wanted to ask through a live example to understand the subject. There are still things I don't understand and can't understand. @MC68020 Dec 24, 2023 at 9:38
  • please post the output of sourcestats (before pausing)
    – MC68020
    Dec 24, 2023 at 9:57

1 Answer 1

1

tl;dr: Your VM guest's clock is unsuitable for chrony, which caused you grief. Stop using it.

There are two approaches for guest OS to keep time:

  • internet
  • host OS

bad way: internet client

Your VM guest could be an NTP client of server1b.meinberg.de and other internet servers. Don't do this.

The VM suffers from long pauses which make external servers appear to rapidly timewarp into the future, every time the guest resumes. You have to do a "step" correction upon resumption, rather than a "run 10% fast" skew correction. Typically a startup script would accomplish this with a command like hwclock -s --utc, or perhaps by asking ntpdate to step the clock from some NTP server.

Chrony documentation section 3.4 points out that makestep 1 -1 is needed for a client in the unusual situation of being frequently suspended for minutes or hours at a time.

good way: host OS clock

When guest wants to know the time, it should ask that of the host it's running on.

Host OS presumably has a decent clock and can on occasion make {offset, frequency} estimates from internet NTP servers, when net is available.

VMware advises that it's

important to not use the local clock as a time source, often referred to as the Undisciplined Local Clock.

You didn't tell us about your hypervisor, so it's not clear what knobs we would have to frob. You may be able to benefit from Benjamin Bryan's experiences.


EDIT

Chrony (or other NTP daemon) is trying to measure {offset, frequency}. So for example, we might be four seconds slow and running 1% fast. Having made a few observations we can estimate both of those and correct for them.

Now suppose the guest suspends for half an hour. We might be able to report "we're 1804 seconds slow and still running 1% fast". But the gross offset is going to disturb any measurement of frequency error. What the daemon really needs to know is that from t_0 to t_1 we heard several NTP responses consistent with the "4 sec behind, 1% fast", then until t_2 we were dead to the world (suspended), and then observations after t_3 are consistent with "1804 sec behind, 1% fast". At which point we would certainly need to step by 1804 seconds.

OP made it pretty clear that chronyd is not syslogging that it knows about "suspend" and "resume" events. So the local undisciplined clock is unsuitable for use as a time base.

As a separate matter, if we listen to an hour's worth of internet NTP responses in order to sync up, then we suspend for half an hour, disconnect from internet, and expect a resumed guest to know what time it is, that information fundamentally has to come the host's clock. OP offers no evidence that the guest can distinguish between a 29-minute or 31-minute suspension interval, since the host's clock is not being accessed, not via hwclock and not via UDP port 123.

That's a config detail which the hypervisor + guest configs will need to fix, if we want to know the time after resuming.

ATM, it sounds like the only way for guest to reliably know the time upon resuming is to insist on being internet attached, and for a resume script to restart chronyd, encouraging a step update. (BTW, iburst initial burst in the config is a good match for that.)

8
  • I would agree with you as per my answer in the other thread ( unix.stackexchange.com/questions/765252/… ) However, OP stated that they wanted to experiment and learn from experiment v.g. not to know what best practice is. So be it. This said, I fail to understand what, precisely, (apart from the huge skew) from the data OP provided tells you that "Your VM guest's clock is unsuitable for chrony"
    – MC68020
    Dec 24, 2023 at 19:09
  • My hypervisor is "virtualbox" and in my wm "enable hardware clock as UTC" is also selected. What I expect from the NTP server when I disconnect my server from the internet and stop the server Isn't it automatically detecting this? Or do I need a VM plugin for this? I still don't understand what the problem is. @J_H Dec 24, 2023 at 20:20
  • can you give more details about "offset, frequency" terms in chrony. I've been seriously confusing these terms and haven't seen a simple example.. I need a simple example of these terms so that I can understand you. Can you provide them as a comment? @J_H Dec 25, 2023 at 1:35
  • Pretty sure I gave an example in the answer. At any given moment, while connected to internet, you can measure a time "offset", with precision limited by the ~40 msec of roundtrip latency you observe. So we can certainly do much better than e.g. 4 seconds or 1804 seconds of error. OTOH a 1% "frequency" error says that in 100 s of external wall clock time your clock advances maybe 99 s, or maybe 101 s. Chrony can compensate for that. However, if chrony doesn't know about suspend / resume events, they will inject so much measurement noise that we cannot adequately compensate, and need host's clk
    – J_H
    Dec 25, 2023 at 8:24
  • Is there a parameter that adjusts the system time to not update quickly when I connect to the internet? I tried "makestep 1 -1" but it did not update quickly.? @J_H Dec 25, 2023 at 14:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .