RTC time could run slow 3s than host time when clock=vm & base=UTC

RTC time could run slow 3s than host time when clock=vm & base=UTC

[贾庆彤 via]

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

Re: RTC time could run slow 3s than host time when clock=vm & base=UTC

[Zenghui Yu via]

+Cc maintainers and author of [1]

On 2024/9/21 19:33, 贾庆彤 via wrote:
> 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
> 
> 
> .