Raspberry Pi Time is off by 45 min

Question

I'm currently running a Pi as a file and Webserver on my small home network. My two Windows-10 PCs have the correct time, but I noticed the Pi time is approx 45 minutes off. No big deal, but when I save a file there, I'd like to see the correct time-stamp on it.

I have unplugged and replugged the PI, and also tried a sudo /etc/init.d/ntp restart ..... but the clock is still slow.
/etc/ntp.conf is as follows (I've eliminated the # lines for brevity)

driftfile /var/lib/ntp/ntp.drift  
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  
server  time.nrc.ca   
server  time.chu.nrc.ca   
restrict -4 default kod notrap nomodify nopeer noquery   
restrict -6 default kod notrap nomodify nopeer noquery**   

Running a sudo ntpq -p shows....

remote           refid      st t when poll reach   delay   offset  jitter  
==============================================================================  
time.nrc.ca     .INIT.          16 u    -  512    0    0.000    0.000   0.000  
time1.chu.nrc.c .INIT.          16 u    -  512    0    0.000    0.000   0.000    

Anyone have an idea as to what my problem is?

UPDATE #2, Feb 11....
As the Raspberry time was more than 1000 seconds behind, I manually corrected it with sudo date -s "(date and time)" but deliberately made it 5 minutes slow, just to see if I could get it updated via internet.
No luck so far. I have also removed DHCP from the Raspberry Pi.
And have rebooted it as well as run
sudo /etc/init.d/ntp restart a couple of times I have 4 ntp servers now- with an iburst attached.

#server ntp.your-provider.example

server time.nrc.ca iburst
server time.chu.nrc.ca iburst
server time.nist.gov iburst
server wwv.nist.gov iburst

But the Pi time is still 5 minutes slow. FWIW, I dual-boot Ubuntu systems with my Win-10 Pcs. Ubuntu has no problem getting correct internet time. I'll reboot one of these and attempt to see how Ubuntu has no problem acquiring the internet time via the edits and cmmds I used on the Pi. Stand by for more input here! ;-)

Answer 1

Ah, ha! Further to my comment to your question I think I have an answer for you. First, if you are using the RPi at home I'd suggest having a explicitly named server from your ISP, if they provide one for their customers.

It was when I was checking my entries that I realised that your server lines are missing a trailing argument of iburst which is recommended - see the output of man ntp.conf . I think this causes the system to respond faster on step changes that will be required e.g. on start-up when the system is not yet locked on.

After a local server to your ISP I would have three or four from your country's pool at ntp.org e.g. for my UK based systems they have:

server 0.uk.pool.ntp.org iburst
server 1.uk.pool.ntp.org iburst
server 2.uk.pool.ntp.org iburst

Obviously you will want to change uk to something more suitable for your location.

I think the problem you are having is that without the (i)burst argument your system is slowly adjusting the clock rate to bring it into line and those 45 minutes you speak of is not enough at the rate it uses without the go ahead to do it faster on start-up...

---

Edit: inspecting your output from ntpq -p suggests that it has only just started - the reach value is a 3+8+8 (19) bit field shown as 3 octal values of past successful polls of the server (LSB i.e 2^0 is most recent attempt and MSB i.e. 2^18 is the nineteenth most recent attempt, so you are looking for a value of 377 ideally) - a value of 0 means NO contact has been made in the last nineteen attempts. Those attempts are currently once every 512 seconds - my RPi that has been up for several days has backed off its interval as ntp daemons do when they are stable and is currently using the normal maximum interval of 1024. The PC I am using to type this has been up for a short while and that is still using a 64 second poll interval that it starts with.

---

Edit2 The OP asks:

DISTANCE matters??

it does, but only in that the jitter will be larger - more variation in the time and route the packets take to get between the server and your daemon - and that you should spread your choice of servers around to minimise the load on any one server. If you use the "virtual" (if that is the word for it) pool ones ntp.org will auto-magically select random real ones each time. In terms of distance, this is why using your own ISPs one is a good starting point as that will be close to your machine in terms of network hops!

One other thing that may be worth checking if you are not getting any connection to Servers is whether there are any odd firewall rules in your machine or your router that is disabling traffic on the UDP port 123 that ntpd uses! For what it is worth older versions of Windows did not use ntp directly but newer ones can do (but I am not sure that they do by default) - there is an excellent GPL Windows binary package (with GUI) port of ntp offered by Meinbergh which I use whenever I have to use a MicroSoft OS - which you might like to experiment with, on one of your PCs (with the same configuration file) to help to determine whether it is a generic configuration problem or an Raspberry Pi specific one.

Related Q&A that may also be helpful:

• Timezone correctly set but incorrect output might offer some pointers to sysv init users (Raspbian Wheezy by default)
• Time and date on clean install of raspbian is very wrong
• Incorrect time until I restart the ntp server (multiple times) which includes a mention of the issue of static IPs that the OP referred to - but this is outside of my experience so I cannot comment on this.

Answer 2

Contrary to an answer posted, NTP is quite ping and jitter tolerant since it can compensate for it, but selecting a close one should't hurt. Also, selecting the right NTP server doesn't really matter since NTP only uses UTC time and the operating system does the time zone calculation.

As a rule of thumb, just select reliable NTP servers.

---

With that said, maybe you should:

1. Redo the time zone setup since /etc/localtime or some other files can get corrupted (especially with overclockers)
   • Run sudo dpkg-reconfigure tzdata and simply select your country/city or the time zone itself (by selecting None of the above)
   • Check the file using sudo cat /etc/localtime. The second line should resemble your time zone.

2. Add even more NTP servers or replace the existing ones.

   • Add these new ntppool servers into the /etc/ntp.conf file just below the line that says server 3.debian.pool.ntp.org iburst. After that, save the file.

     server 0.pool.ntp.org iburst
     server 1.pool.ntp.org iburst
     server 2.pool.ntp.org iburst
     server 3.pool.ntp.org iburst
     

     Give ntp a small nudge by running the command sudo service ntp restart

3. If the above fails, try to do the time update manually by running sudo sntp -s 0.pool.ntp.org. It will use NTPPool's server. As it's running, you will see the compensation algorithm in action. Your 700ms ping won't bother it.

Answer 3

The .INIT. status shows that the RPi has not been able to exchange messages with the configured timeservers.

Firewalls are a frequent cause of this problem. Some public ntp servers block requests from system that have not registered. Using pool.ntp.org will avoid a registration issue, but not a firewall issue. From a firewall perspective, ping uses ICMP messages while ntpd uses UDP port 123 (not TCP). Consequently, a successful ping is not a guarantee that firewalls are allowing ntp messages through.

It is also a good practice to use a command to set the local date/time from the timeservers before starting ntpd. One command that did this was ntpdate. Ntpd is designed to handle the minor variations in clock frequency that occur over time. It works in frequency changes in parts-per-million, not 15 minute or even 15 second changes.