>> If I were pulling numbers out of the air, I'd call under 10-15 ms "good",
>> and under 30-50 ms "tolerable", and beyond that "bad".

> Personally, I would like to see the tolerances increased, but probably
> not quite as tight as you are asking for.  However, I would much
> rather see the problem with the growth rate of clients per server
> fixed first.  (And, Ask seems to be doing just that, so no complaints
> from here about priorities.)

Um... did you you mean to write "tightened"?  "Increased" tolerances
are generally looser.

Agreed on priorities, but I've never measured an offset > 20 ms that
wasn't due to a configuration problem.  General broadband performance
is around 2-4 ms in my experience.  It seems at least worth *telling*
people that things are a little dubious.  This is not about kicking
people out of the pool, but helping them run good servers.

If you don't want to change the current criteria, maybe add a category
above "okay" like "really good"?

Of course, there are the sympathies expressed in
https://fortytwo.ch/mailman/pipermail/timekeepers/2003/000104.html

> One of the problems was that Adrian did not have the ability to test
> the pool servers from several places around the world.  So, if a given
> ntp server happened to have bad connectivity to Switzerland, but good
> connectivity from the rest of the world, Adrian's scripts could give
> your server a bad score.

> As a result, the tolerances are very large.  IIRC, anything under
> 250ms is considered "good".

Ah.  I usually do it using ntpq to peer servers.  Heck, the server
itself can usually tell you via ntpq, if any of its peers are sane.
Look at 24.172.8.162 for example.  It's in the U.S., and most of its
problems are that it picked servers in Israel, Poland and Guatemala with
200 ms round-trip times.  ntpd knows it has a big offset, it's just
so unstable it can't correct it.

Pick a couple of reliable NTP servers in each area, have them ping
everyone nearbywith minpoll 1024, and you can suck your statistics out
of the loop filters.

In fact, judging by old mailing list traffic about monitoring servers,
that's pretty much exactly how it's done...
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to