-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Shoppa wrote:
> Jan writes:
>> Uninteresting to you maybe, but it is the answer to Tims question: 
>> "don't use the pool stats to monitor your own server".
>> That's the point you missed.
> 
> I know (and most, but not all, server maintainers know) that it
> is monitoring not just the server, but the asymmetric latency
> between the server and the monitoring site.

I know that the monitoring system can't be used as an absolute measure
of the server performance. However for many server admins there are no
other way to at least have an indication of how your server is
performing. In this case I didn't know the IP of the monitoring system
and thus could test the RTT to rule it out as the cause of the strange
behavior. A plot of the RTT would help and the IP of the monitoring
server would make it easier to diagnostic the problem. Even better would
be a distributed monitoring system to reduce the chance that a random
network problem kick servers out of the pool.

> Of course there are millions of TCP/IP addresses, so really
> the grand latency matrix consists of millions times millions of
> numbers at any point in time, but having just a single measure
> of a route is better than nothing!

The route between different machines is fairly constant. You can do a
traceroute hours, days, weeks or even month or years apart and the route
is approximately the same.

> (In fact there are other global projects to measure WAN latencies,
> and most of them use ntpd with a local refclock to get timing
> resolutions in the microsecond range... with some provisos! Lotsa
> little things pop up once you expect to do this good.)
> 
> If, like ntpd, the monitoring site also plotted round-trip-time as a
> function of time of day, it would be even more useful.

/Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG6q1agy5P5/GLfoQRAthPAKDAJQB388zzOrS3O81rzUOTi4Qb8QCcCZUR
dzQq8jytQkzntP0MsQhLe7g=
=Li2e
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to