This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3354: frequency error -506 PPM exceeds tolerance 500 PPM

Part Number: AM3354

Hello,

On my Embedian AM335X SMARC module, I am running against some issues with timekeeping. My NTPD deamon wont make time corrections because the frequency exceed the allowed PPM maximum. 

Jan 30 10:45:49 D22-460 ntpd[567]: frequency error -17413 PPM exceeds tolerance 500 PPM
Jan 30 10:53:28 D22-460 ntpd[567]: frequency error -564 PPM exceeds tolerance 500 PPM
Jan 30 10:53:30 D22-460 ntpd[567]: frequency error -501 PPM exceeds tolerance 500 PPM
Jan 30 10:56:53 D22-460 ntpd[567]: frequency error -566 PPM exceeds tolerance 500 PPM

I don't want it to do a timejump, I want it to slew, but it won't. 

timedatectl
               Local time: Fri 2026-01-30 11:05:47 CET
           Universal time: Fri 2026-01-30 10:05:47 UTC
                 RTC time: Fri 2026-01-30 10:05:47
                Time zone: Europe/Amsterdam (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no
root@D22-460 (1) ~# 
root@D22-460 (1) ~# hwclock -r
2026-01-30 11:05:59.887288+01:00
root@D22-460 (1) ~# 
root@D22-460 (1) ~# cat /etc/ntp.conf 
# Driftfile location (keeps track of the local clock's drift)
driftfile /var/lib/ntp/drift

# Disable clock jump, always use clock slew. 1 sec diff could take 2000s to correct.
tinker step 0

# NTP servers from the internet to synchronize the time
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

# Disable syncing with the local system clock; we are using network servers
# Remove the fallback to 127.127.1.0 (local clock) and its stratum 14.
# server 127.127.1.0
# fudge 127.127.1.0 stratum 14

# Default security settings to restrict access
restrict -4 default notrap nomodify nopeer noquery
#restrict -6 default notrap nomodify nopeer noquery

# Allow the local host to access the NTP server
restrict 127.0.0.1    # Allow local host
#restrict ::1          # Allow local host

----- 

Is this a know issue? 

I am using processor SDK: processor-sdk-09.01.00-legacy-config.txt

Kind regards,

Raymond. 

  • Your questions appear to be more related to software than hardware, which I cannot address. I will only be able to comment after the software team has looked at your concern and explains which hardware functions are being used for time keeping.

    What is your reference clock source to the device and what is its operating frequency?

    Regards,
    Paul

  • Hello,

    NTP uses the dmtimer. 

     dmesg | grep timer
    [    0.000000] TI gptimer clocksource: always-on /ocp/interconnect@44c00000/segment@200000/target-module@31000
    [    0.000025] clocksource: dmtimer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
    [    0.000461] TI gptimer clockevent: 24000000 Hz at /ocp/interconnect@48000000/segment@0/target-module@40000
    [    0.170958] clocksource: Switched to clocksource dmtimer
    root@D22-460 (1) ~# dmesg | grep clock
    [    0.000000] TI gptimer clocksource: always-on /ocp/interconnect@44c00000/segment@200000/target-module@31000
    [    0.000002] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
    [    0.000025] clocksource: dmtimer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
    [    0.000461] TI gptimer clockevent: 24000000 Hz at /ocp/interconnect@48000000/segment@0/target-module@40000
    [    0.111291] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
    [    0.165988] PTP clock support registered
    [    0.170958] clocksource: Switched to clocksource dmtimer
    [    1.960871] rtc-s35390a 0-0030: setting system clock to 2026-02-04T09:33:35 UTC (1770197615)

    ---- 

    After some more investigation, when I log date in a loop of 0.1s, I see the timer is very jittery, the kernel is always late. What I learned is that NTP does not like this, and these frequency errors are probably caused by, this timer interrupt latency. 
    So I changed my setup to use Chrony instead, which seems much more forgiving, and correctly slews the time when my RTC clock is ahead after boot. 

  • As I mentioned before, I only support hardware questions. Therefore, I do not fully understand what you are saying. It sounds like you are saying, you changed something in software and the issue was resolved. If so, does this mean we can close this thread?

    Regards,
    Paul