3

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! ;-)

Human
  • 1,138
  • 3
  • 14
  • 35
aqk
  • 79
  • 1
  • 9
  • Hello and welcome to the Raspberry Pi corner of the Stack Exchange network. As user of `nptd` myself I do wonder about your use of only two time-servers, both seemingly very close to each other. – SlySven Feb 09 '16 at 22:27
  • Ah, I stand corrected in that you ARE using a couple of servers from the official Canadian Time Reference organisation (but having spotted that you are *right* on the border perhaps you are further from them than a US one? 8-P) – SlySven Feb 09 '16 at 23:01
  • The DISTANCE matters?? Are these NTP servers ping-dependent? I mean, more than 100ms off matters? Why? FWIW, I'm using a satellite connection here in the deep dark rural woods. An average ping is about 650-700 ms! And Windows has no problem keeping the correct internet time, whether it's time.nrc.ca, time.dist.gov or time.windows.... – aqk Feb 10 '16 at 01:23
  • Instead of the default time server pools it is certainly best to use the atomic clock directly: https://raspberrypi.stackexchange.com/questions/68811/how-do-i-set-raspbian-to-use-the-primary-time-server-time-nist-gov/68812https://raspberrypi.stackexchange.com/questions/68811/how-do-i-set-raspbian-to-use-the-primary-time-server-time-nist-gov/68812 – SDsolar Sep 25 '17 at 07:17

3 Answers3

2

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:

Community
  • 1
SlySven
  • 3,581
  • 1
  • 15
  • 44
  • DISTANCE matters?? Are these NTP servers ping-dependent? More than 100ms off matters?\r\n FWIW, I'm using a satellite connection in the deep darkwoods of Southern Quebec. An average ping is 650-700 ms! Windows has no problem keeping correct internet time, whether it's time.nrc.ca, time.dist.gov or time.windows ... I DID comment out the following- #server 0.debian.pool.ntp.org iburst ##server 1.debian.pool.ntp.org iburst ##server 2.debian.pool.ntp.org iburst ##server 3.debian.pool.ntp.org iburst Not familiar with the iburst operand. Maybe this is needed? – aqk Feb 10 '16 at 01:37
  • I added the iburst, and no diference.... But- I just thought of it!! I gave my raspberry a static ip! And if DHCP isn't running, you are supposed to use another .conf file - I shall look up this info and see if I can configure it. – aqk Feb 10 '16 at 01:59
  • Well, I have killed, no DELETED all DHCP, rebooted and added two more NTP servers Still the clock is ~45 min slow. I suppose this is more than 1000 seconds... See- – aqk Feb 10 '16 at 07:54
  • Well, I have DELETED all DHCP, rebooted & added 2 more NTP servers Still the clock is ~45 min slow. more than 1000 seconds? See- remote refid st t when poll reach delay offset jitter ================================================== time.nrc.ca .INIT. 16 u - 1024 0 0.000 0.000 0.000 time1.chu.nrc.c .INIT. 16 u - 1024 0 0.000 0.000 0.000 time-c.timefreq .INIT. 16 u - 1024 0 0.000 0.000 0.000 host-24-56-178- .INIT. 16 u - 1024 0 0.000 0.000 0.000 – aqk Feb 10 '16 at 08:00
  • How does one enter a "newline" in this editor?? **EXTREMELY ANNOYING! WORSE THAN FACEBOOK! ** – aqk Feb 10 '16 at 08:04
  • You cannot enter a newline in comments and the formatting options are very limited - perhaps so major stuff goes into Answers or is edited into the original Question? You CAN delete comments if you wish or edit them for up to 5 minutes after their initial entry... BTW how long after (re)starting `ntpd` are you getting results where the `reach` figure is still `0`? – SlySven Feb 10 '16 at 23:56
  • Thanx. I have added, and will add more updates to my original post. I hope this is satisfactory. Is this *%$# syntax just for raspberry forum, or all of stackexchange? ;-) – aqk Feb 11 '16 at 07:05
  • @aqk you can get to a new line by pressing enter twice. – Aloha Feb 11 '16 at 12:44
  • @PandaLion98 I think he means *in a comment*. You can use shift-enter, but it won't make any difference in the display. **This is *not* a discussion forum, aqk,** comments are not intended for you to drag people into long back-and-forth dialogues with elaborate content. If you want to add information to your question **edit you question**. – goldilocks Feb 11 '16 at 13:22
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.
Aloha
  • 7,078
  • 1
  • 25
  • 52
  • I agree that the protocol can compensate for that jitter - but the averaging must take time so why make it work harder than it needs to! 8-P. The other minor consideration is that each packet adds an infinitesimal amount to network traffic and, unless you are using broadcast messages, lots and lots of very small packets do start to add up. Although the packets are small, if everyone uses them and the maximum poll interval is artificially set to a ridiculously low value it all does mount up. – SlySven Feb 11 '16 at 19:44
  • Indeed there were bugs in older versions of the daemon that could under certain *crafted* conditions be made to perform **DDOS** attacks using `ntp` packets IIRC. – SlySven Feb 11 '16 at 19:45
2

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.

Chad Farmer
  • 111
  • 5
  • The `when` of `-` and the `reach` of `0` are also both strong indications that the Pi isn't in contact with either NTP server. – Mark Jun 24 '17 at 02:29