Hi Philip On 01-06-15 16:08, Philip Homburg wrote: > In your letter dated Sun, 31 May 2015 13:29:16 +0200 you wrote: >> Ok you can make a statistic about the leap second e.g. to show roughly >> how the percentage of servers announcing the leap second is. But is that >> all you want to accomplish? > > Here are a couple of reasons: > - client side monitoring, certainly with an as diverse set of nodes as Atlas > probes may reveal all kinds of things normal monitoring doesn't see.
I can imagine this. Therefore, I'd be interested in the results. For how long do you want to do this additional probing? > - independent reporting is usually appreciated by users of a system This might lead to too much confidence in our pool system. We already have had first aid services asking for help as they could sometimes not synchronise their clocks very well with our pool. Sync'd clocks was essential in their system to make only one car (and at least one...) go to a crash site. We (at least I ;-) ) definitely don't want people to get the idea this is a highly monitored, highly accurate and high availability service. > - a longer term goal for Atlas, finding out if one-way delay measurements are > possible between selected nodes. This is possible, depending on the relative accuracy of the time between the two nodes (they both may have the same unknown offset from absolute time). I cannot imagine this is new to you. So, what method to measure this one way delay do you have in mind? I am interested in all kinds of new methods to measure things :-) >> Personally I don't mind this, as long as you don't have all 8000 probes >> start at once but randomly distribute the load over the 15 minutes. >> 8000 probes multiplied with 3 packets at once is about 1.7 Megabyte and >> could easily annoy servers with weaker links. > > The spread is expected to be 400 seconds. Each probe is doing a new DNS query every 15 minutes, right? Do you mean it spreads out the three packets to the single probed server over 400 seconds (200 s on average between packets)? > Tim Bray wrote: >> In my head, the atlas probes won't monitor the whole pool. > > Quite possible. From a client point of view it is usually enough to know > what you can expect, this is not meant to replace normal monitoring. The normal pool returns 'nearby' servers, being in DNS rotation according to their set bandwidth. Therefore, you most likely end up with 90% of the measurements for a single probe being from the nearest large bandwidth server. On the other hand, we have less than 3000 active servers in the IPv4 network. So, on average, each server is probed by 2.8 probes. For our 1000(!) IPv6 servers the ratio is 8 to 1. How about adding all 8000 probes as (low bandwidth) NTP servers to the pool? :-D >> They will just monitor whatever whether you get a good time from the >> first pool server that looks up? > > The probes will perform a DNS lookup each time they perform a measurement, > so it depends a bit on what variation the DNS server returns. Clear, but what do you look at? Is it offset (relative to local time at the probe), stratum, delay at server, round trip delay, reachability, leap indication, ...? Regards, Arnold _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
