Does it matter which NTP time server I choose in Windows?
Does it matter which time server I choose?
Short answer: Yes
Whilst all NTP servers strive to maintain synchronisation with UTC, their distance from you, and the intervening networks, affect NTP factors such as latency and jitter. There is also the question of availability, not all servers are available continuously forever.
So far as I know, UTC and the stratum-0 NTP service is not overseen, regulated or provided by USNO, even within the USA. UTC was defined by the ITU and is based on TAI plus leap seconds (I believe determined by ERS) TAI is maintained by an international set of 70 laboratories (of which USNO is one but also including NRL in Washington and NIST at Boulder) and coordinated by BIPM in France.
I would use the ntp pool for your locale.
How would I know if one was "better" than the others?
By running a real NTP client on a suitable system and looking at the stats
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
connorw600.info europium.canoni 16 u 182d 1024 0 0.000 0.000 4000.00
*dns0.rmplc.co.u ntp1.ja.net 2 u 659 1024 377 27.015 -4.936 1.034
+82.113.154.206 ntp4.ja.net 2 u 700 1024 377 24.853 -4.827 0.788
+dawn.rt.uk.eu.o ntp1.nl.uu.net 2 u 913 1024 377 29.364 -5.614 0.691
Looks like connorw600.info… would be a bad choice.
According to Wikipedia, the Network Time protocol works as follows:
To synchronize its clock with a remote server, the NTP client must compute the round-trip delay time and the offset. The round-trip delay is computed as , where is the time of the request packet transmission, is the time of the request packet reception, is the time of the response packet transmission and is the time of the response packet reception. is the time elapsed on the client side between the emission of the request packet and the reception of the response packet, while is the time the server waited before sending the answer. The offset is given by .
The NTP synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times.
From this explanation we can admit that to have an accurate clock synchronization you must have low difference in the delay time that the server respond to your request and the time delay that you answer to the server completing the synchronization. So, if the server that you are running are far away from you (I mean, there are a lot of "points" or routers between you and the NTP server) the probability to have a different "path" for the NTP packets that you receive and you send is increased.
So, from my interpretation of the case, the best server to synchronize your clock is the "closer" one. I mean, if you get a trace of the "points" between you and the server you would choose the one that have fewer jumps. You could use the "tracert" command from Windows to resolve the best public NTP Server for you.
Also, remember that beyond these standard options, there are a lot of public NTP Servers on the Internet.