Hello,

I have a requirement to sync multiple pieces of proprietary lab
instruments TO EACH OTHER ONLY via NTP.  In other words, no external
internet connectivity.  Is this possible with NTP?  I have read the
NTP documentation but have found no mention of this type of scenario;
would I simply choose a 'master' to act as a private stratum '1' ?  I
understand the implications of this; over time there could be massive
skew, but my requirements are that all devices keep the same time even
if its way off from UTC so they may correlate measurements.  These
instruments run a modern linux and have ntp v4.1.2.  Any help
appreciated.

Thanks!

Sean Langford

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clinging to sanity, hine yorg mumbled in his beard:

> Hello,
> 
> I have a requirement to sync multiple pieces of proprietary lab
> instruments TO EACH OTHER ONLY via NTP.  In other words, no external
> internet connectivity.  Is this possible with NTP?  I have read the
> NTP documentation but have found no mention of this type of scenario;
> would I simply choose a 'master' to act as a private stratum '1' ?

Set your local clock to be a stratum 10 on one of the devices.

server 127.127.1.0
fudge 127.127.1.0 stratum 10

then have the others take time from that one. (I believe doing this with
more than one device and have them peer with each other increases
reliability.)


Please don't fudge to a low stratum: you *will* forget that one of your
devices acts as low-stratum server when you connect that network to the
internet at some point in the future (and you will probably want to
automatically switch to a better time source when one becomes available,
not to speak of the possibility of suddenly serving bad time.)

cheers
- -- vbi

- -- 
Protect your privacy - encrypt your email: http://fortytwo.ch/gpg/intro

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iKcEARECAGcFAkBzAf5gGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWhS0AoLHb3MXfBxtEWvqGJOFKbnkO
KisGAKDFXASF6WLJPbdUeELuzdj4dGZ6sQ==
=r5zK
-----END PGP SIGNATURE-----

In article <2872348.fDYRts2bdr@altfrangg.fortytwo.ch>,
Adrian 'Dagurashibanipal' von Bidder <grazdan@fortytwo.ch> wrote:

> then have the others take time from that one. (I believe doing this with
> more than one device and have them peer with each other increases
> reliability.)

The correct solution is to use an appropriate protocol, like the timed
protocol.  However, if you must abuse NTP, you should not peer and you
should not fudge to the same stratum if you have more than one machine
with a local clock configured.  One should be a client relative to the
other and should be fudged to a stratum that is at least one more than
the number of hops between them greater than the other.

Note that abusing ntpd for such isolated time islands is an FAQ (whether
or not it is in the actual FAQ documentation).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clinging to sanity, David Woolley mumbled in his beard:


> Note that abusing ntpd for such isolated time islands is an FAQ (whether
> or not it is in the actual FAQ documentation).

David, I'd find it polite if you either do not put in a FAQ disclaimer at
all, or *know* that it is in the FAQ and put in the FAQ disclaimer
unconditionally, ideally with an URL.

greets
- -- vbi

- -- 
Today is Boomtime, the 24th day of Discord in the YOLD 3170

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iKcEARECAGcFAkBzpE9gGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWmxcAoK9Wco4Buag9dL5fpQ1Wo86U
+B8jAJ9HJ5uEKOoHzxHEdBTGmI1XXgwbrw==
=9pHP
-----END PGP SIGNATURE-----

hine yorg wrote:

> Hello,
> 
> I have a requirement to sync multiple pieces of proprietary lab
> instruments TO EACH OTHER ONLY via NTP.  In other words, no external
> internet connectivity.  Is this possible with NTP?  I have read the
> NTP documentation but have found no mention of this type of scenario;
> would I simply choose a 'master' to act as a private stratum '1' ?  I
> understand the implications of this; over time there could be massive
> skew, but my requirements are that all devices keep the same time even
> if its way off from UTC so they may correlate measurements.  These
> instruments run a modern linux and have ntp v4.1.2.  Any help
> appreciated.
> 

I'd say to configure these devices as each others peers. Then they see each 
other as equal in the time hierarchy and they somehow sync the time at both ends.

If you somewhere in the future find a better clock, just point that as server 
with a lower update frequency (higher minpoll value) and off you go.

Here at our site, we have some servers that have a similar configuration. There 
are some external servers defined but in the end, they sync on each other and 
external sync gets less and less but no problem if the external connection drops.

The ntp.conf file contains a bunch of the next lines with ip-addresses of all 
systems to sync (even itself to ease configuration):
# the next 2 lines for each IP address
peer IP.AD.RE.SS prefer
restrict IP.AD.RE.SS mask 255.255.255.255

#And for external sync (optional):
server IP.AD.RE.SS minpoll 15 maxpoll 17
restrict IP.AD.RE.SS mask 255.255.255.255 nomodify notrap noquery




CBee

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clinging to sanity, CBee mumbled in his beard:

> I'd say to configure these devices as each others peers. Then they see
> each other as equal in the time hierarchy and they somehow sync the time
> at both ends. 

Won't work. A server will not accept time from an unsynchronized time server
- - and so all servers in the network will never become synchronzed.

You can have them peer time with each other, but at least one client will
need an outside time source (the local clock of one of the boxes does also
count as an external time source in this context).

cheers
- -- vbi

- -- 
The content of this message may or may not reflect the opinion of me, my
employer, my girlfriend, my cat or anybody else, regardless of the fact
whether such an employer, girlfriend, cat, or anybody else exists.  I
(or my employer, girlfriend, cat or whoever) disclaim any legal
obligations resulting from the above message.  You, as the reader of
this message, may or may not have the permission to redistribute this
message as a whole or in parts, verbatim or in modified form, or to
distribute any message at all.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iKcEARECAGcFAkB0EO5gGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWKoYAoPEyju93FR1snSzzdX9PO0V5
+MRIAJ0Q1SwdKScoLDOBUk8If4HunZiUcw==
=HrAX
-----END PGP SIGNATURE-----

david@djwhome.demon.co.uk (David Woolley) wrote in message news:<T1081318750@djwhome.demon.co.uk>...
> In article <2872348.fDYRts2bdr@altfrangg.fortytwo.ch>,
> Adrian 'Dagurashibanipal' von Bidder <grazdan@fortytwo.ch> wrote:
> 
> > then have the others take time from that one. (I believe doing this with
> > more than one device and have them peer with each other increases
> > reliability.)
> 
> The correct solution is to use an appropriate protocol, like the timed
> protocol.  However, if you must abuse NTP, you should not peer and you
> should not fudge to the same stratum if you have more than one machine
> with a local clock configured.  One should be a client relative to the
> other and should be fudged to a stratum that is at least one more than
> the number of hops between them greater than the other.
> 
> Note that abusing ntpd for such isolated time islands is an FAQ (whether
> or not it is in the actual FAQ documentation).

David,

I agree that Sean should use an appropriate protocol. After 
re-reading a few paragraphs of RFC1305, I come to the 
conclusion that NTP is an appropriate protocol. Admittedly, 
a number of NTP features, such as its ability to select the 
best subset from a number of timeservers and reject 
falsetickers, are not needed in this application. And 
there's always more than one way to do it -- SNTP might be 
an alternative, for example. However, from reading the RFC I 
get the impression that in the early days NTP synchronized a 
number of 'time islands', which subsequently grew and 
amalgamated, so that they now encompass a significant 
fraction of all Internet nodes. So Sean's requirement is 
just another case of something that was done routinely with 
NTP years ago.

Sean: The difference between your case and the 'typical' NTP 
setup is that you can only use one timesource, whereas an 
NTP net that's synced to UTC should have multiple refclocks. 
Configure one of your instruments to use the LOCAL refclock, 
and fudge its stratum to 10 (for example). Do not configure 
more than one machine with the LOCAL refclock. Configure the 
other instruments as clients. You don't have to fudge their 
stratum -- NTP will work it out automagically. If you want 
to peer between them, go ahead. Don't worry about protocol 
abuse :-)

Paul

Adrian 'Dagurashibanipal' von Bidder wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Clinging to sanity, CBee mumbled in his beard:
> 
> 
>>I'd say to configure these devices as each others peers. Then they see
>>each other as equal in the time hierarchy and they somehow sync the time
>>at both ends. 
> 
> 
> Won't work. A server will not accept time from an unsynchronized time server
> - - and so all servers in the network will never become synchronzed.

Then sync them to the local clock (server 127.127.1.0) and twiggle a little with 
the stratum.

Correct me if I'm wrong, I have the impression the next is kind of default:

server 127.127.1.0
fudge 127.127.1.0 startum 4

> 
> You can have them peer time with each other, but at least one client will
> need an outside time source (the local clock of one of the boxes does also
> count as an external time source in this context).

You can always configure one but there is no need to have it available all the 
time hence never can be an option: just define it and see where it goes.




CBee

> 
> cheers
> - -- vbi
> 
> - -- 
> The content of this message may or may not reflect the opinion of me, my
> employer, my girlfriend, my cat or anybody else, regardless of the fact
> whether such an employer, girlfriend, cat, or anybody else exists.  I
> (or my employer, girlfriend, cat or whoever) disclaim any legal
> obligations resulting from the above message.  You, as the reader of
> this message, may or may not have the permission to redistribute this
> message as a whole or in parts, verbatim or in modified form, or to
> distribute any message at all.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: get my key from http://fortytwo.ch/gpg/92082481
> 
> iKcEARECAGcFAkB0EO5gGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
> aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
> NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWKoYAoPEyju93FR1snSzzdX9PO0V5
> +MRIAJ0Q1SwdKScoLDOBUk8If4HunZiUcw==
> =HrAX
> -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clinging to sanity, CBee mumbled in his beard:


> Correct me if I'm wrong, I have the impression the next is kind of
default:
> 
> server 127.127.1.0
> fudge 127.127.1.0 startum 4

It depends on where you get ntpd from - some vendors ship an ntp.conf with
something like that, others leave it out entirely, or have it commented
out. Perhaps the default ntp.conf in stock ntpd has changed at some time,
too - I don't know (I don't even know what the default config file *is* for
anything, since I always just take my config file, which right now doesn't
have a local refclock).

Btw, stratum 4 seems quite low. I'd recommend using 10 or more.

greetings
- -- vbi

- -- 
whatever

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iKcEARECAGcFAkB1mmNgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWRA4AoNpBgp0UQHHqSdwi9atuMnqj
v0B2AKCizUB9w2uOfH84AiM8DboTwfCMoQ==
=5o+H
-----END PGP SIGNATURE-----