On 2014-01-27 14:45, Rob wrote:
Rick Jones <[email protected]> wrote:
Brian Inglis <[email protected]> wrote:
You don't specify which system and devices you are using,
so here are a couple of articles about changing ARP timeouts:
http://www.embeddedsystemtesting.com/2013/01/arp-timeout-value-for-linux-windows.html
http://support.microsoft.com/kb/949589
And if indeed these are all the OP's own systems, he can add
hardwired, "permanent" ARP cache entries via the arp command (under
most *nixes at least).
I'm still not sure if ARP is really the problem, but fixing the
clients to maxpoll 6 seems to cure it.
(at least the reach now sticks at 377)
If a mix of wired and wireless is involved, if there is some way to get
traces at the point where the two join that would be goodness.
If both would be WiFi, I would point at the WiFi. However, one is
connected to the wired network (a switch where the server is connected
as well).
I can ping it as much as I like, no loss:
1571 packets transmitted, 1571 received, 0% packet loss, time 20468ms
rtt min/avg/max/mdev = 0.702/0.845/1.168/0.090 ms
But when ntpd is allowed to climb to 1024-second polls, it gets almost
no replies.
Check the server wrappers/firewall/switch allowing incoming unsolicited
packets on port 123. If you "enable stats"+"statistics rawstats" or watch
packets on the server, you should see whether requests are making it into
the server and replies out. As other posters have suggested, it could be
a port blocking timeout anywhere along either path between the two ntpds.
--
Take care. Thanks, Brian Inglis
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
