Jetson TX2 time is wrong at every boot


I am using a Jetson TX2 and I am not able to get an ntp server running. I know that this question has already been asked but the solutions proposed did not work for me.

My TX2 is connected in Ethernet to a laptop computer on which ntp is running flawlessly.

If I run on my laptop

sudo service ntp status

I get

* NTP server is running

On my TX2 I have, in the


file the following (where is the IP of the Laptop I am connected through ethernet):

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Specify one or more NTP servers.

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See for
# more information.
#pool iburst
#pool iburst
#pool iburst
#pool iburst

# Use Ubuntu's ntp server as a fallback.

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <>
# might also be helpful.
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict mask notrust

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth

#Changes recquired to use pps synchonisation as explained in documentation:

#server mode 135 prefer    # Meinberg GPS167 with PPS
#fudge time1 0.0042        # relative to PPS for my hardware

#server                   # ATOM(PPS)
#fudge flag3 1            # enable PPS API

When I do, on the TX2,

sudo service ntp status

I get:

nvidia@tegra-ubuntu:~$ sudo service ntp status 
● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
   Active: active (running) since Tue 2018-04-24 23:47:34 CEST; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 4160 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS)
  Process: 4172 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/ntp.service
           └─4183 /usr/sbin/ntpd -p /var/run/ -g -u 122:128

Apr 24 23:47:34 tegra-ubuntu ntp[4172]:    ...done.
Apr 24 23:47:34 tegra-ubuntu systemd[1]: Started LSB: Start NTP daemon.
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: proto: precision = 0.128 usec (-23)
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: Listen and drop on 0 v6wildcard [::]:123
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: Listen and drop on 1 v4wildcard
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: Listen normally on 2 lo
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: Listen normally on 3 eth0
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: Listen normally on 4 lo [::1]:123
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: Listen normally on 5 eth0 [fe80::6ba6:b029:830a:516a%3]:123
Apr 24 23:47:34 tegra-ubuntu ntpd[4183]: Listening on routing socket on fd #22 for interface updates

Anyway, if I remove power from my TX2 and then plug it in again I have always the wrong time set .

Someone can help me please?

First, the Jetson should have a supercap backed real-time clock (if you’re using the standard motherboard.)
If this doesn’t work, your supercap may be broken.
If you’re using another carrier board, check with the documentation for whether you need to hook up a battery or a supercap.

Second, starting a service doesn’t mean that it will stay running across reboot. Ubuntu is a systemd release, and you need to enable the service. And, on ubuntu, it’s called “systemd-timesyncd.service” not “ntpd.”

sudo systemctl enable systemd-timesyncd.service

However, this should already be enabled. You can check the status for whether it is running correctly:

systemctl status systemd-timesyncd.service

Chances are, the problem you’re seeing is with the real-time clock or your carrier board, and not with the time synchronizer.

I’ve been having this same issue.
Could I have some guide to the differences between the ntp service and the system timesync status?
What would be the best way to ensure the correct date always shows on reboot of the system?

When I run the status I get
systemctl status systemd-timesyncd.service
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendo
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
Active: inactive (dead)
Condition: start condition failed at vie 2016-02-12 01:47:53 CET; 5min ago
Docs: man:systemd-timesyncd.service(8)

So I try to enable it but doesn’t seem to work.

Later I normally use the ntp service like this
ntp service stop
ntp service start


I don’t remember all of the changes to ntp configuration, but there do seem to be some differences between “older” and “newer” Ubuntu releases. I’m assuming you are using Ubuntu 16.04 (which is what most of the TX2 releases are…a near future release will be Ubuntu 18.04), but configuration is basically no different on a Jetson versus any other computer. What differs is that the Jetson has only a supercap and can discharge before starting again which turned off (a PC can do that too…after five or more years or so or whenever the button battery dies). You might see if this answers your questions since it is specific to Ubuntu 16.04:

FYI, one of the biggest issues someone might run into is whether the network is up and available at the time of the NTP request, or if proxy or firewalls get in the way.