qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "贾庆彤 via" <qemu-devel@nongnu.org>
To: <qemu-devel@nongnu.org>
Subject: RTC time could run slow 3s than host time when clock=vm & base=UTC
Date: Sat, 21 Sep 2024 19:33:31 +0800	[thread overview]
Message-ID: <eba4b2cf-cf64-4237-aaf6-8aa521c77007@huawei.com> (raw)

When start qemu with -rtc base=utc,clock=vm, sometime guest time can 
slower 3s than host.

There's no problem (also didn't be noticed) as we often start ntp 
service, who will adjust our system time.

But let's talk about if we havn't enable NTP service(for example system 
just booted)

After inspect into the code, i found that there are two problem we 
should think about:

1) The RTC time accuracy problem

1. in the call chains 
rtc_realizefn->rtc_set_date_from_host->qemu_get_timedate->qemu_ref_timedate,

the qemu_clock_get_ms(clock) / 1000 will lost ~0.999s at max.

2. In the call chains cmos_ioport_read->rtc_update_time, the guest_sec = 
guest_nsec / NANOSECONDS_PER_SECOND

will also lost ~0.999s at max.

3. after this[1] merged, in configure_rtc, the rtc_ref_start_datetime = 
qemu_clock_get_ms(QEMU_CLOCK_HOST) / 1000

will also lost ~0.999s at max.

Therefore, total about 3s the guest time will behind the host.

So what precision should we offer? the RTC Hardware's precision is 
second(that means the smallest step is 1 second,

not the accurate like time error about 8.6 to 1.7 seconds per day),


2)The ref start datetime

After this[1] merged, which intend to solve the -rtc 
base=DATETIME,clock=vm's problem ("It restores determinism

of guest execution when used with clock=vm and specified base value.").

"-rtc base=utc,clock=vm"'s ref start date time changed from the host 
time of the current executing code to

the const time of executing configure_rtc(rtc_ref_start_datetime = 
qemu_clock_get_ms(QEMU_CLOCK_HOST) / 1000;).

This will add additional time(current approx. 0.4s or other, depend on 
code executing time and how many class_init

  executed etc.),which start from configure_rtc to rtc device init, into 
guest time.

Hence, should we try to split -rtc base=utc,clock=vm's ref start date 
time to the original current host time

qemu_clock_get_ms(QEMU_CLOCK_HOST),not the time(rtc_ref_start_datetime) 
save in configure_rtc,

to achieve more accurate time?(or other better method)


[1] https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03577.html



             reply	other threads:[~2024-09-21 13:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-21 11:33 贾庆彤 via [this message]
2024-09-28 10:47 ` RTC time could run slow 3s than host time when clock=vm & base=UTC Zenghui Yu via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eba4b2cf-cf64-4237-aaf6-8aa521c77007@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=jiaqingtong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).