Advanced search FAQ Register Login

It is currently Sun Oct 22, 2017 9:27 am

 

Postby TerryJC » Tue Aug 15, 2017 1:52 pm

Hi,

We have an ongoing project to monitor and control water levels in the 'River' at our local Model Town. To do this, we will have a 'Master' Pi and one or more 'Remote' Pis connected together via Ethernet. For operational, reliability and security reasons this network will not be connected to the Internet, so we need some way to keep all the clocks in sync.

My current idea and preferred solution is to install a RASClock on the master Pi and set the Pi up as an NTP server. I'm sure that this can be done, but searching for help, I mainly seem to be finding info about how to use a GPS card to get the time and somewhere mixed in with all the stuff about setting that up, there is (presumably) how to set up the NTP Server.

I know how to set up RASClock; I've used one before to time the chimes on our model Minster and everyone is very impressed with our timekeeping. What I really need is a step-by-step guide to setting up the server (or a link to one).

Can anyone help?

TerryJC
Initiated

Posts: 36

Joined: Mon Nov 07, 2016 2:23 pm

Location: Wimborne Minster, Dorset

Terry

Postby Dave » Tue Aug 15, 2017 2:10 pm

Just found this - http://raspberrypi.tomasgreno.cz/ntp-cl ... erver.html

There's a section regarding NTP server down the bottom. Assuming you can use this as well as your RTC.

Dave
ModMyPi

User avatar

Posts: 1808

Joined: Wed Jul 22, 2015 11:36 am

Forum Administrator & Technical Support

Postby TerryJC » Tue Aug 15, 2017 2:29 pm

Dave wrote:Just found this - http://raspberrypi.tomasgreno.cz/ntp-cl ... erver.html

There's a section regarding NTP server down the bottom. Assuming you can use this as well as your RTC.

Thanks for that; I'll give it a try. I notice that the section that you refer to begins:

Now when RPi has synchronized its time, you can set it to pass this time information to devices in your local network.


That raises two questions for me:
  1. I presume that the server will still work if it is getting the time from RasClock and not another NTP Server.
  2. Would I need to disable the NTP Client on the 'Master' or will this work anyway?

TerryJC
Initiated

Posts: 36

Joined: Mon Nov 07, 2016 2:23 pm

Location: Wimborne Minster, Dorset

Terry

Postby Dave » Tue Aug 15, 2017 4:01 pm

Yeah I'm not sure, I would assume the NTP server just passes out the current time it has on the system, regardless of where it came from... But that is a big assumption.

I suspect you could leave the NTP client enabled as it'll only work with an internet connection anyway.

Dave
ModMyPi

User avatar

Posts: 1808

Joined: Wed Jul 22, 2015 11:36 am

Forum Administrator & Technical Support

Postby TerryJC » Tue Aug 22, 2017 7:26 am

Dave wrote:Yeah I'm not sure, I would assume the NTP server just passes out the current time it has on the system, regardless of where it came from... But that is a big assumption.

It took us a while to get round to doing this (a key team member was ill), but I tried it yesterday with no success. Here is what I did:

  1. Allocated static IP addresses to both Pis and restricted the DHCP range on the Wireless AP to avoid conflicts. The Master Pi is 192.168.0.2 and the Remote Pi is 192.168.0.3.
  2. Followed the instructions at http://raspberrypi.tomasgreno.cz/ntp-cl ... erver.html setting the Remote Pi as the Client and the Master Pi as the Server.

For the Client we've added:
server 192.168.0.2

to the server pool.

For the Server we've added:
restrict 192.168.0.0 mask 255.255.255.0

and:
broadcast 192.168.0.255

Anyone got any ideas that might help? I've put a screenshot of the output of ntpq -pn at http://hadrian-way.co.uk/Misc/Pi_NTP_Screenshot.png. (I couldn't get it to attach.)

TerryJC
Initiated

Posts: 36

Joined: Mon Nov 07, 2016 2:23 pm

Location: Wimborne Minster, Dorset

Terry

Postby TerryJC » Tue Aug 22, 2017 11:45 am

TerryJC wrote:[For the Server we've added:
restrict 192.168.0.0 mask 255.255.255.0

and:
broadcast 192.168.0.255

Someone on my local Linux User Group suggested:
Everything is sitting at stratum 16 "no trusted clocks", the server won't
offer a syncronisation service at this level.

The server needs a clock it trusts before it will serve the time.

Add the following two lines to your servers config.

server 127.127.1.0
fudge 127.127.1.0 stratum 12

This tells the server to use the system clock as a reference at stratum
12.

I tried this, but still no joy.

TerryJC
Initiated

Posts: 36

Joined: Mon Nov 07, 2016 2:23 pm

Location: Wimborne Minster, Dorset

Terry

Postby TerryJC » Thu Aug 24, 2017 6:08 pm

I thought I would follow up on this to relate what I have discovered. NTP is working on our setup, but it takes up to 10 minutes to sync. This: https://www.eecis.udel.edu/~mills/ntp/html/debug.html is a useful site and gave us the clue that this is normal. In our case, the problem is exacerbated because the server, the client and the network switch all start at the same time and for anything from 5 to 10 minutes the server emits KoD (Kiss of Death) packets to say that the timestamps on the packets and the files are inconsistent with the transmitted message. Once they line up, the system syncs.

In order to stop our software taking measurements and recording them with incorrect timestamps in the file, we are pausing boot-up at the client using ntp-wait. I put it into rc.local and our software, (triggered from a line in .bashrc) cannot start until the clocks are correct.

It's a pain, but nevertheless not a bad workround for us.

If anyone knows the reason why it takes so long for the server to stop emitting KoD packets, we'd love to know. ;)

TerryJC
Initiated

Posts: 36

Joined: Mon Nov 07, 2016 2:23 pm

Location: Wimborne Minster, Dorset

Terry

Postby Dave » Fri Aug 25, 2017 8:34 am

TerryJC wrote:I thought I would follow up on this to relate what I have discovered. NTP is working on our setup, but it takes up to 10 minutes to sync. This: https://www.eecis.udel.edu/~mills/ntp/html/debug.html is a useful site and gave us the clue that this is normal. In our case, the problem is exacerbated because the server, the client and the network switch all start at the same time and for anything from 5 to 10 minutes the server emits KoD (Kiss of Death) packets to say that the timestamps on the packets and the files are inconsistent with the transmitted message. Once they line up, the system syncs.

In order to stop our software taking measurements and recording them with incorrect timestamps in the file, we are pausing boot-up at the client using ntp-wait. I put it into rc.local and our software, (triggered from a line in .bashrc) cannot start until the clocks are correct.

It's a pain, but nevertheless not a bad workround for us.

If anyone knows the reason why it takes so long for the server to stop emitting KoD packets, we'd love to know. ;)


Thank you for the follow up post! Very helpful indeed.

Glad you've got a working setup :)

Dave
ModMyPi

User avatar

Posts: 1808

Joined: Wed Jul 22, 2015 11:36 am

Forum Administrator & Technical Support

Postby TerryJC » Mon Sep 11, 2017 12:17 pm

TerryJC wrote:It's a pain, but nevertheless not a bad workround for us.

Further to my experiences realated above, it has now emerged that our solution for an NTP Server may actually be causing a problem with the Real Time Clock. This post https://forum.modmypi.com/technical-support/rasclock-timekeeping-very-erratic-t1713.html#p7572 relates my problems with getting the RTC to keep time and the current state of affairs which seems to be that running the NTP Server on my Pi causes the time to be corrupted on itself.

I'm open to suggestions as to why this would be.

TerryJC
Initiated

Posts: 36

Joined: Mon Nov 07, 2016 2:23 pm

Location: Wimborne Minster, Dorset

Terry

Who is online

Users browsing this forum: No registered users and 1 guest

Board index

The teamDelete all board cookies • All times are UTC [ DST ]