Thor,The RTC time is a few hundred milliseconds ahead of the system time

The RTC time is a few hundred milliseconds ahead of the system time

timedatectl
Local time: Tue 2025-10-21 13:49:48 CST
Universal time: Tue 2025-10-21 05:49:48 UTC
RTC time: Tue 2025-10-21 05:49:49
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
NTP service: active
RTC in local TZ: no

It’s known behavior.

Dear :

How to solve this problem, is there a patch
Tks

It’s known behavior due to the RTCUP system start before the kernel launch.

You can get the diff by the readOffsetNs()

Dear:
readOffsetNs()
offset_ns:18597448328
offset_ns:18597453719
offset_ns:18597453142
offset_ns:18597452775
timedatectl
Local time: Tue 2025-10-21 11:33:52 UTC
Universal time: Tue 2025-10-21 11:33:52 UTC
RTC time: Tue 2025-10-21 11:33:53
Time zone: UTC (UTC, +0000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
==》Calculate the value using the ns function
Is this result correct; 18597452775ns?

Yes, that is the ns offset with system monotonic raw time.

Dear:

Thank you very much for your reply
There are some differences. In our application scenarios, we use RTC time on one side, system time on the other side, and time aligned data transmission on both sides; However, the timedatectl reads a difference of about 1 second between the RTC and the system time.
If the offset offset_ns value is used to directly compensate for the system time (18.6 s), the difference between the offset and RTC time will be even greater.
Thanks

You need to compare with CLOCK_MONOTONIC_RAW.

Dear :

The direction of the problem is somewhat different; The question we encountered is the difference between RTC time and system time, not TSC timestamp timer;
Can you help us to check if the difference between RTC time and system time (such as 300ms or 500ms, etc.) is normal,
Tks

OK, you may need to disable the NTP service to confirm.

Thanks

Dear:

Both systemdate and systemtimesync are disabled, and the timedatectl verification result still shows a significant difference in seconds
tks

Do you see the time drift after hwclock to sync the time?

Dear :

yes,After executing the heclock –systohc command and checking the data with timedatectl, there is still a difference between RTC and system time;
Can you also try it on your devkit; I used Thor Devkit to verify that there is still a difference between RTC and system time

We would like to ask within what milliseconds this difference is considered normal

tks

Hwclock does not show any drift so we can safely ignore few milliseconds drift shown in timedatectl

root@jetson:/home/ubuntu# hwclock --verbose && date; cat /sys/class/rtc/rtc0/time; cat /sys/class/rtc/rtc1/time;

hwclock from util-linux 2.39.3

System Time: 1764841209.562802

Trying to open: /dev/rtc0

Using the rtc interface to the clock.

Last drift adjustment done at 1764839371 seconds after 1969

Last calibration done at 1764839371 seconds after 1969

Hardware clock is on UTC time

Assuming hardware clock is kept in UTC time.

Waiting for clock tick…

…got clock tick

Time read from Hardware Clock: 2025/12/04 09:40:10

Hw clock time : 2025/12/04 09:40:10 = 1764841210 seconds since 1969

Time since last adjustment is 1839 seconds

Calculated Hardware Clock drift is 0.000000 seconds

2025-12-04 09:40:09.565495+00:00

Thu Dec 4 09:40:09 UTC 2025

09:40:10

09:40:10

root@jetson:/home/ubuntu# date; cat /sys/class/rtc/rtc0/time; cat /sys/class/rtc/rtc1/time

Thu Dec 4 09:41:14 UTC 2025

09:41:14

09:41:14

root@jetson:/home/ubuntu# date; cat /sys/class/rtc/rtc0/time; cat /sys/class/rtc/rtc1/time

Thu Dec 4 09:41:18 UTC 2025

09:41:18

09:41:18

root@jetson:/home/ubuntu# timedatectl

           Local time: Thu 2025-12-04 09:44:15 UTC

       Universal time: Thu 2025-12-04 09:44:15 UTC

             RTC time: Thu 2025-12-04 09:44:15