At 4:52 PM -0500 2005-09-09, wayne wrote:
I think you are overstating the problem and I haven't heard a lot of
complaints about the current {europe,asia,north-america}.pool.ntp.org.
Western Europe and North America aren't such problems, but Asia
is known to be a serious morass of networking issues, where countries
that are neighbors and have been enemies for hundreds or thousands of
years, do not have any kind of good connectivity between them.
Eastern Europe, the Middle East, South America, Africa, etc... all
share many of the same problems as Asia.
Building any kind of geographical knowledge into client-side
configuration scripts is therefore likely to run afoul of all sorts
of problems that you could not have foreseen, because you didn't know
that Eastern-Upper-Clockwise Timor was a deadly enemy of
Western-Lower-CounterClockwise Timor, and that if any packets were
allowed to pass directly between them that the laws in the respective
countries required them to launch nuclear weapons at each other.
Build whatever knowledge is appropriate into the system regarding
where the servers are located (more or less), but don't try to make
any assumptions in client-side configuration scripts. After all,
they may be there today, and somewhere totally different tomorrow.
Yes, you want to make client-side configuration as simple as
possible. But the clients should be able to see all the same DNS
zones that everyone else can see, and the person who administrates or
controls that machine should be able to make decisions as to which
set of servers are likely to be the best for them. And that may or
may not change on a day-to-day basis.
When I travel to Singapore, Thailand, Finland, Sweden, Norway,
Latvia, Lithuania, Estonia, Russia, Poland, Germany, Denmark, the
Netherlands, the UK, France, Spain, the US, Canada, or any other
country that I have ever traveled to or ever will travel to, I know
that my previous settings for server choices may no longer be
appropriate, and I may have to make some changes.
Setting me up to use just the two known servers located here in
Belgium and then keeping that configuration everywhere I go, is
probably a bad idea.
And no, I don't always remember to change the timezone settings,
so basing everything off the timezone isn't going to work, either.
Moreover, I might prefer to run everything in UTC, and have only my
user-level timezone displayed in some other value. In fact, I do run
all my servers in UTC, with a TZ variable over-riding that in my
.cshrc file.
Even in the cases of bad routing in a given region, filling out
country code, continental and timezone entries would be unlikely to
make things *worse*. Filling out the zones, in the limiting case, is
identical to using just the global pools.
The worst possible thing we could do is to create situations that
could cause an existing good configuration to become a bad
configuration, as a result of fiddling under the hood and moving
stuff around in the DNS.
There's a rule in business, which I think is very appropriate
here -- Standard is better than "better". We need to be very
careful what kinds of changes we're recommending putting into the
system, because the potential consequences could be huge. Moreover,
we need to consider not only the pool as a isolated object, we also
need to consider *how* the pool is used by the various NTP-related
projects.
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
