How are incorrect time servers handled in the NTP pool? And a question regarding Windows NTP setup

1

Hi everyone,

Is there any mechanism that ensures servers with incorrect time are not part of the NTP pool?
Or is it reactive - meaning it´s theoretical possible to get a bad server (and thus wrong time) until it’s identified and removed from the pool?

A bit OT:
So far, on non-domain Windows machines I’ve been using just “de.pool.ntp.org,0x9”.
During testing I had a server which had connection issues and then went offline.
So it’s probably better not to rely on just the pool address, but to specify multiple servers directly - right?

Here are two example NTP configurations (registry value name: “NTPServer”):

A: Equal priority
0.de.pool.ntp.org^,0x9 1.de.pool.ntp.org^,0x9 2.de.pool.ntp.org^,0x9

B: Fallback setup
0.de.pool.ntp.org^,0x9 1.de.pool.ntp.org^,0xA 2.de.pool.ntp.org^,0xA

Please ignore the caret – I had to escape the links because new users are only allowed to post two links.

For reference:
0x9 = 0x1 (SpecialInterval) + 0x8 (Client)
0xA = 0x8 (Client) + 0x2 (UseAsFallbackOnly)

In example A, does Windows actually query all three servers and choose (with some kind of internal logic?) the best?
Or does it behave basically like B - just using the first available one?
Is “0xA” sufficient at all for backup servers, or does “SpecialInterval” also need to be specified here and thus 0xB (0x1 + 0x2 + 0x8):
0.de.pool.ntp.org^,0x9 1.de.pool.ntp.org^,0xB 2.de.pool.ntp.org^,0xB

Thanks in advance for any insights!
Best regards,
Martin

2

There is a monitoring system that tries to keep inaccurate servers out of the Pool, and to remove servers that become inaccurate. So it’s somewhat reactive, in that it will take a few minutes for the monitoring system to detect that a previously good server has gone rogue and to remove it. But a server that continuously reports bad times will not be advertised as part of the pool in the first place.

You can see this system at work on the individual server pages. pool.ntp.org: Statistics for 2a05:b400:c::123:60 shows one of my servers, and that most of its offsets are less than 10 ms. But around 12:00 on 30 August, monitor “nlams3-1a6a7hp” saw some offsets around 30 ms and one dropped packet, which caused it to reduce its score a little. Other monitors didn’t see any problem, so the overall score didn’t change and the server remained in the Pool.

There’s a longer description of the monitoring system at Technical details | NTP Pool News , but I think it’s ahead of the implementation and actually describes the new monitoring system that isn’t quite deployed yet.

2 Likes