> Within the purview of NTP, there is a much simpler way to do this
> -- use "manycast" instead. The client sends out a multicast query
> with a packet TTL of zero, to see if there are any servers on the
> local segment which are configured to listen to that address and
> provide NTP service. If none, then it tries again with a TTL of 1.
The possibility exists for requesting pool servers to do a cut down
version of this. Each server could, over time, do a traceroute to every
other server, and report back either the number of hops or the whole
result. Pool HQ could then do a clustering and we'd have zones of
some real use. It's a significant data crunching exercise, however,
and it's not obvious how you'd figure out which `zone' a client might
be in. At least it's a minimum of bother to the client.
> A simple round-robin scheme is likely to get you as good
> performance as anything else you could implement, because there are
> always going to be a whole host of factors out of your control, and
> if you try to micro-manage the problem too much then you end up
> creating more problems than you could possibly resolve.
Perhaps we should start advising client writers to reresolve names
periodically to get new servers from the round robin. They can combine
the new servers with the old, sort according to hops, trim, and end
up, eventually, with a list of close servers. We could then provide
a reverse DNS facility for such clients to ensure that their close
servers are still in the pool, as this is still important.
I believe that's a real possibility. No fuss for the user, but rather
the choice of client writers to implement.
Cheers,
- Joel
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
