Rob Janssen a écrit : > Guillaume Filion wrote: >> I made a prototype using Border Gate Protocol (BGP) data last April -- >> with mixed results. With hindsight I think that the only factor that >> must be taken into consideration for NTP is latency. BGP had a tendency >> of optimizing for bandwidth. >> >> I played a bit with Maxmind's GeoIP and Great Circle Distance >> calculations recently, but I'm not to the point of testing a prototype. >> > Well, there is a point in using geographical position as a weight > factor, but it should not be too heavy weight because geographical > position does not tell much about latency either. Maybe in a > 1000km grid, or so.
According to my limited testings, geographical position works better than what one would think at first. Most cities have BGP routes exchange centers so if your packets are going into the same city/region, chances are that they won't have to travel very far (most of the times with less than 30 ms RTT). The main problem that I have right now with the system is the unreliability of the IP to lat,lon translation. I'm using MaxMind GeoLiteCity with a failover to hostip.info, but I'm still seeing maybe 10% of obviously bad data. Using the pay-for version of GeoCity instead of the "lite" one would certainly help, along with allowing the NTP server operators to specify their exact coordinates on the www.pool.ntp.org web site. > You could do a traceroute back to the client to find out in what network > neighborhood they live :-) That would slow down the reply and increase > the load on the DNS server a lot, of course. Actually, I think this is what OASIS (http://oasis.coralcdn.org/) is doing. From a theoretical standpoint they have a very sound system, but in practice I haven't seen very good results. > The prototype you demo'd did not work that bad for me. It returned > addresses within my ISP. But that probably is because there are > lots of active pool servers in my ISP's network (xs4all.nl) That's what I meant by mixed results. If there were NTP servers in the same Asynchronous System (AS) as the client, the DNS would work perfectly. However, if there weren't, then the DNS server would try to figure out the route to the closest NTP server and my BGP tables didn't hold enough information to do that properly. It didn't knew the difference between a 10' length of cable and a transatlantic fiber, so you could get a server on the other side of the planet just because you are both peering with TeleGlobe (AS6453). > What I mean by recent history is that we could return 1..3 addresses > from the list of valid replies for that query, and change the reply for every > query. > So when 30 servers are available for some country, we would not be returning > 10 of > those 30 for an hour, then another subset for another hour, but we would be > smoothly returning the entire set (and can even set the likelyhood on every > server > depending on its quality and capacity). I agree, that's exactly what I want to do. I don't want to have spikes of clients like what we see now. I would want each server to have a relatively constant number of clients from the area around it. >[...] > I think there should also be a manually maintained table in the system > where ISP timeservers and the networks they cover (or want to service) are > stored. > Some not-so-retarded ISPs actually have a timeserver that their clients > can use, although it is not always that well published and/or good quality. > When > a client of that ISP requests a timeserver, we might return that address > instead of > a server from the voluntary pool. Of course only for situations where the > ISP > agrees. > This would reduce the load on other servers and give the user a server > that at least is quite local. (for example, xs4all.nl operates the servers > ntp.xs4all.nl and > ntp2.xs4all.nl) Just putting these ISP servers in the pool would have this effect. We maybe could add restriction for some servers so that they would only be returned to queries coming from a particular subnet. I'm not sure if we really want that. I would rather just add these servers to the pool and let the distribution algorithm take care of it. Best, GFK's -- Guillaume Filion, ing. jr Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
