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
On Fri, Jan 24, 2014 at 10:13:15PM +, William Unruh wrote:
On 2014-01-24, David Woolley david@ex.djwhome.demon.invalid wrote:
If there is a prefer peer and it survives, it uses that one, otherwise
as per clock_combine in ntp_proto.c, i.e. weighted by synchronisation
distance (which
The only way that NTPD works well is to find 4 to 9 stratum 2 servers
near your location by searching the server lists at www.ntp.org.
Then observe the servers over a few days so that none of the ones you
pick have highly variable transit times.
Then set your clients facing external servers to
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 server at a technical university in Poland as a source of
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
16 matches
Mail list logo
