Rob nom...@example.com wrote:
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)
New tests show it is OK at poll interval 128 (maxpoll 7), and
fails at poll interval 256 (maxpoll 8).
So whatever the
detha de...@foad.co.za wrote:
On Mon, 27 Jan 2014 21:45:22 +, Rob wrote:
[...]
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
On Wed, 29 Jan 2014 08:28:25 +, Rob wrote:
detha de...@foad.co.za wrote:
On Mon, 27 Jan 2014 21:45:22 +, Rob wrote:
[...]
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
detha de...@foad.co.za wrote:
It is apparent that the problem does not occur when the link is busy, but
I still don't know the cause.
It may also be some power-saving mechanism, for example.
First step is to prove that the problem goes away when the link is kept
busy with totally unrelated
On Wed, 29 Jan 2014 17:56:04 +, Rob wrote:
detha de...@foad.co.za wrote:
If keeping the link open with a ping helps, second step is to determine
what times out. Run a ping from somewhere else to the server, or from
the client to somewhere else. If running a ping from the client to
detha de...@foad.co.za wrote:
What distribution and kernel are you running on the wired one? I've got a
spare raspberry somewhere, would be interesting to see if I can reproduce
this.
raspbmc (downloaded bootstrap and installed
and updated using its builtin mechanism).
Linux raspbmc 3.10.21
On 2014-01-29, Rob nom...@example.com wrote:
detha de...@foad.co.za wrote:
It is apparent that the problem does not occur when the link is busy, but
I still don't know the cause.
It may also be some power-saving mechanism, for example.
First step is to prove that the problem goes away when
Brian Utterback brian.utterb...@oracle.com wrote:
Anyway, nothing every came of the discussion.
I commented on that generic situation a while ago.
It seems typical for discussions about ntpd functionality.
Suggestions are always ridiculed, the specs are perfect now,
the code is without bugs.
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-01-27 14:45, Rob wrote:
Rick Jones rick.jon...@hp.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
You don't specify which system and devices you are using,
so here are a couple of articles about changing ARP timeouts:
Brian Utterback brian.utterb...@oracle.com wrote:
I don't know about lost packets. It seems to me that dropping the packet
that triggered an ARP request is not very robust, in fact it is down
right fragile. Are you sure that there really are such implementations?
Typically all cisco
A C agcarver+...@acarver.net wrote:
On 1/27/2014 13:45, Rob wrote:
Rick Jones rick.jon...@hp.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
You don't specify which system and devices you are using,
so here are a couple of articles about changing ARP timeouts:
Le 28 janv. 2014 à 10:02, Rob a écrit :
Brian Utterback brian.utterb...@oracle.com wrote:
I don't know about lost packets. It seems to me that dropping the packet
that triggered an ARP request is not very robust, in fact it is down
right fragile. Are you sure that there really are such
On 28/01/2014 08:57, Rob wrote:
Brian Utterback brian.utterb...@oracle.com wrote:
Anyway, nothing every came of the discussion.
I commented on that generic situation a while ago.
It seems typical for discussions about ntpd functionality.
Suggestions are always ridiculed, the specs are
mike cook michael.c...@sfr.fr wrote:
Le 28 janv. 2014 ? 10:02, Rob a ?crit :
Brian Utterback brian.utterb...@oracle.com wrote:
I don't know about lost packets. It seems to me that dropping the packet
that triggered an ARP request is not very robust, in fact it is down
right fragile. Are
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 28/01/2014 08:57, Rob wrote:
Brian Utterback brian.utterb...@oracle.com wrote:
Anyway, nothing every came of the discussion.
I commented on that generic situation a while ago.
It seems typical for discussions about ntpd
@lists.ntp.org] On Behalf Of
Rob
Sent: Monday, January 27, 2014 4:45 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?
Rick Jones rick.jon...@hp.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
You don't specify which system and devices you are using, so here
Of
Harlan Stenn
Sent: Monday, January 27, 2014 7:55 PM
To: Brian Utterback
Cc: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?
Brian Utterback writes:
On the other hand, I have definitely observed that phenomenon as a
source of asymmetric round trip time. The outgoing
On 28/01/2014 11:24, Rob wrote:
[]
It is all Linux. Both client and server.
I can reproduce the ARP issue on cisco routers and switches.
The first outgoing ping always fails.
I've also seen this when pinging a freshly booted Raspberry Pi (Linux
3.6.11) from Windows (7/64).
I can't
A C agcarver+...@acarver.net wrote:
Because I read your configuration as server and client being on same
network but one is wired and one is wireless.
Ok you got that wrong, then.
Now if you're seeing this
behavior from each device (wired and wireless) to a third server
somewhere else then
Whoever implements this will probably want to see a lot of this
discussion.
Please consider putting the interesting bits of this discussion on a
topic in the Dev web of the NTP support wiki. It will make it *much*
easier for folks to organize the information and much easier for folks
to find and
On Tue, 28 Jan 2014 13:31:51 +, Charles Elliott wrote:
Discussion:
It is definitely, definitely true that offset (error) is highly
correlated with the distance between the client and the server. For a
time, one of the stratum 2 servers in the USA State of New Jersey was
using a
On Mon, 27 Jan 2014 21:45:22 +, Rob wrote:
[...]
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
Marco Marongiu brontoli...@gmail.com wrote:
On 01/26/2014 08:08 PM, Rob wrote:
My hypothesis is that the ARP entry for the NTP server has timed out,
and when ARP has to resolve an entry in some implementations the first
packet is always lost (it is not cached pending a reply).
When the cycle
Hi--
On Jan 27, 2014, at 10:10 AM, Rob nom...@example.com wrote:
Despite lots of tracing I still cannot really pinpoint the problem.
The only thing I see is that ping has absolutely zero loss and all
usual protocols work fine, but ntp indicates a high loss when there
is no other network
Charles Swiger cswi...@mac.com wrote:
Hi--
On Jan 27, 2014, at 10:10 AM, Rob nom...@example.com wrote:
Despite lots of tracing I still cannot really pinpoint the problem.
The only thing I see is that ping has absolutely zero loss and all
usual protocols work fine, but ntp indicates a high
On 2014-01-27, Rob nom...@example.com wrote:
Charles Swiger cswi...@mac.com wrote:
Hi--
On Jan 27, 2014, at 10:10 AM, Rob nom...@example.com wrote:
Despite lots of tracing I still cannot really pinpoint the problem.
The only thing I see is that ping has absolutely zero loss and all
usual
On 2014-01-27, Rob nom...@example.com wrote:
Marco Marongiu brontoli...@gmail.com wrote:
On 01/26/2014 08:08 PM, Rob wrote:
My hypothesis is that the ARP entry for the NTP server has timed out,
and when ARP has to resolve an entry in some implementations the first
packet is always lost (it is
Brian Inglis brian.ing...@systematicsw.ab.ca 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
On 1/26/2014 2:08 PM, Rob wrote:
On a very quiet network, I observe that ntpd sometimes has a very
high loss rate: reach is 6, for example.
When using ping or any other protocol, no packet loss at all is
observed.
My hypothesis is that the ARP entry for the NTP server has timed out,
and when
Rick Jones rick.jon...@hp.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
You don't specify which system and devices you are using,
so here are a couple of articles about changing ARP timeouts:
On 1/27/2014 13:45, Rob wrote:
Rick Jones rick.jon...@hp.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
You don't specify which system and devices you are using,
so here are a couple of articles about changing ARP timeouts:
On 27/01/14 19:33, Rob wrote:
It is unclear to me if an outgoing request
would be shown on the trace when ARP resolution is incomplete.
Needing to do ARP will cause some extra round trip delay, but should not
prevent the packet being transmitted. ARP cache timeout is not a
sufficient cause.
On 2014-01-27 14:45, Rob wrote:
Rick Jones rick.jon...@hp.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
You don't specify which system and devices you are using,
so here are a couple of articles about changing ARP timeouts:
Brian Utterback writes:
On the other hand, I have definitely observed that phenomenon as a
source of asymmetric round trip time. The outgoing request packet gets
delayed for ARP request and reply at each hop, but the return packet has
no such delay. Quite a while ago I suggested a special
On 2014-01-28, Harlan Stenn st...@ntp.org wrote:
Brian Utterback writes:
On the other hand, I have definitely observed that phenomenon as a
source of asymmetric round trip time. The outgoing request packet gets
delayed for ARP request and reply at each hop, but the return packet has
no
] On Behalf Of
Rob
Sent: Monday, January 27, 2014 1:11 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?
Marco Marongiu brontoli...@gmail.com wrote:
On 01/26/2014 08:08 PM, Rob wrote:
My hypothesis is that the ARP entry for the NTP server has timed out,
and when ARP has
On a very quiet network, I observe that ntpd sometimes has a very
high loss rate: reach is 6, for example.
When using ping or any other protocol, no packet loss at all is
observed.
My hypothesis is that the ARP entry for the NTP server has timed out,
and when ARP has to resolve an entry in some
On 01/26/2014 08:08 PM, Rob wrote:
My hypothesis is that the ARP entry for the NTP server has timed out,
and when ARP has to resolve an entry in some implementations the first
packet is always lost (it is not cached pending a reply).
When the cycle is 1024 seconds, the ARP entry has again
On 2014-01-26 12:08, Rob wrote:
On a very quiet network, I observe that ntpd sometimes has a very
high loss rate: reach is 6, for example.
When using ping or any other protocol, no packet loss at all is
observed.
My hypothesis is that the ARP entry for the NTP server has timed out,
and when
39 matches
Mail list logo
