Is there a rule for the network delay for which you would overwrite the NTP settings for a member

[#1]

Hi;

Is there a rule for the network delay for which you would overwrite the NTP settings for a member. For example of all grid members are in Australia feeding their Grid time from NTP servers in Australia. However, only one member is in India and we decide to overwrite the grid settings, so that this member in India can feed off NTP servers in India.

The question is, is there a network delay figures at which you would do that. For example the Round trip time for a ping between the Grid Master in Australia and the Grid Member in India is larger than 500ms.

Kindly

Wasfi

[#2 · Accepted solution]

As long as the updates are working reliably, NTP actually handles this pretty well by itself. The key is to poll as many different sources as possible, allowing NTP to factor this in more accurately when calculating the time. Three to five (reliable) sources as ideal. Additional sources can also be configured as backups, but only the first five most reliable sources will be used at any given time.

Regards,

Tony

[#3]

Overriding settings for grid members or any other inherrited settings is not based on rules.  If a DNS setting is made gridwide, when you override it at a lower level (say a zone), it's either overridden or inherrited.  You can not configure the override such that it is based on location, delay, or an extensible attribute value.

[#4]

To be honest, I would include both Australia and India NTP servers in your NTP config and just let the NTP algorithm figure out which one to use. It will normally latch onto the one with the lowest "delay"/"stratum" combination, so the Oz Infoblox appliances with latch onto Australian sources, whilst the box in India *should* latch onto India, although to avoid confusing the issue it would make sense to ensure both Oz and India NTP sources are at the same stratum. If India is at stratum 2 and Australia is at stratum 3, then it's possible that the Oz devices might use the India NTP servers, even though they are farther away.

Here's an example from some Linux based servers we have...

This device is located in UK and has latched onto a local stratum 1 clock that is also in UK (highlighted in red):

# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 12 l 15d 64 0 0.000 0.000 0.000
+10.244.10.9 10.244.10.11 2 u 133 512 376 0.983 -0.107 0.274
-10.245.130.9 10.245.130.11 2 u 336 512 376 184.460 -0.284 0.310
*10.244.2.11 .GNSS. 1 u 42 512 377 0.085 0.141 0.365
+10.244.10.11 .GNSS. 1 u 198 512 377 1.001 0.058 0.322
+10.245.130.11 .GNSS. 1 u 36 512 377 184.361 0.338 0.381

This next device is located in Hong Kong, and has latched onto a local stratum 1 clock in HK:

# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 12 l 15d 64 0 0.000 0.000 0.000
-10.244.2.9 10.244.2.11 2 u 35 512 277 184.762 -0.184 0.258
-10.244.10.9 10.244.10.11 2 u 296 1024 376 184.581 -0.144 0.128
+10.244.2.11 .GNSS. 1 u 475 1024 377 184.348 0.127 0.066
+10.244.10.11 .GNSS. 1 u 547 1024 377 183.999 0.110 0.077
*10.245.130.11 .GNSS. 1 u 558 1024 377 0.090 -0.077 0.065

Don't forget you can use the "preferred" tick box to influence which source gets picked, you can set this on a member by member basis to direct appliances in India to use their local clock, and vice versa with Australia.

[#5]

Thank you Paul. This is very useful and explanatory.