From: "Tim" <ignored_mailbox@xxxxxxxxxxxx>
Terry Polzin:
It's generally a bad idea to try to sync to a time server outside your
TZ.
Tim:
Why do you think this? NTP doesn't work with local time.
jdow:
Basically I'd suggest that merely in the interest of trying to
minimize the packet transit time as a "rule of thumb".
I wouldn't assume that for a moment. The route between you and
something on the internet mayn't have any correlation to physical
closeness.
For instance, just within Australia, a connection to a service in a city
only 10 kms away from me (in Adelaide) gets routed from one side of the
country to the other, zig-zag style (from Adelaide to Perth, to Sydney,
back to Adelaide).
That is why I use it as a starting point, only. As you learn your
network topology you must deal with you elect the paths that have the
best short term stability. GENERALLY these are also the paths with
the lowest return times. But you must start somewhere. So looking
within your time zone "generally" makes sense, roughly speaking.
Of course, if traceroutes show dozens of hops for the selected site
investigating a wider collection of choices seems wise. A traceroute
output (mtr seems to be VERY good for this) can help a lot. I'd look
for sites that appear along the path to the one that's really far away.
Sadly there's no nifty traceroute for both ways available. I've seen
situations with 20 hops to get to a site and three (!) to get back.
Go figure. But you have to start somewhere. Within your timezone may
be worthwhile if you have no other information upon which to base
your initial choices.
By the way, for awhile "gtei" ran ntp servers on each of their DSL
hubs. I found their time was very consistently 80 ms off from all the
other time servers around this area, CalTech, UCSD, UCLA, and so forth.
They had VERY quick ping times, though.
{^_-}
