John Winters kirjoitti:
On Mon, 6 Jun 2011 04:03:42 -0700, Ask Bjørn Hansen <[email protected]>
wrote:
The system running http://www.beta.grundclock.com/ is now monitoring the
IPv6 servers. If you added one, please have a look!
I'm currently seeing about every other query packet getting no response
and thus my score (after a brief flirtation with positive values) has
plummeted. Is it just me? I find IPv6 communication perfectly reliable in
normal use, and when I've done small tests myself I haven't had a single
failed response.
"Me too", about half of the probes end up getting lost somewhere.
One of my IPv6 NTP servers is at 2001:41d0:1:7f42::1. I started running
tcpdump on that server at 16:12:10 UTC. There's also an oddity that the
monitoring server seems to send queries which are not recorded in the
CSV. All queries were answered by my server.
16:18:25 -- extra query
16:18:27 -- extra query
16:18:29 -- not seen in tcpdump, -5 in CSV
16:18:44 -- seen in tcpdump, OK in CSV
16:19:01 -- extra query
16:19:03 -- extra query
16:19:05 -- not seen in tcpdump, -5 in CSV
16:19:23 -- extra query
16:19:25 -- extra query
16:19:27 -- not seen in tcpdump, -5 in CSV
16:19:46 -- seen in tcpdump, OK in CSV
16:19:53 -- extra query
16:19:55 -- seen in tcpdump, OK in CSV
16:20:13 -- seen in tcpdump, OK in CSV
So it appears that some queries don't even end up on my server, but
there are some extra queries which are not recorded anywhere. I'm
assuming that the monitoring server should send only one query per
probe, at least I think that's how it used to work.
The probing frequency is also substantially higher than previously, but
perhaps it's because of this development phase.
It is also possible (or even likely) that e.g. the query I received at
16:18:27 is actually related to CSV's 16:18:29 failed probe (ie. it
takes a few seconds to record the time to the database).
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
