On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca wrote:
[ ... ]
Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has
done a lot of testing comparing chrony to ntpd ( which showed that
chrony controlled the
On 04/12/2014 20:03, Rob wrote:
[]
It is not good practice to use pool on 100-1000 internal systems,
presumably via NAT, to poll time from internet.
Simple advice is: setup 1 NTP server when you are always monitoring,
or 2 servers when you cannot always be on watch to fix the one server,
and
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 04/12/2014 20:03, Rob wrote:
[]
It is not good practice to use pool on 100-1000 internal systems,
presumably via NAT, to poll time from internet.
Simple advice is: setup 1 NTP server when you are always monitoring,
or 2 servers
David Taylor wrote:
On 04/12/2014 20:03, Rob wrote:
[]
It is not good practice to use pool on 100-1000 internal systems,
presumably via NAT, to poll time from internet.
Simple advice is: setup 1 NTP server when you are always monitoring,
or 2 servers when you cannot always be on watch to fix
On Dec 5, 2014, at 3:42 AM, William Unruh un...@invalid.ca wrote:
On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca wrote:
[ ... ]
Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has
done a lot of testing
On 05/12/14 08:42, William Unruh wrote:
Nope. ntp changes the rate of the local clock to correct offsets. That
is all it does. It does not make the rate correct, and then the offset.
Not true. It applies a correction for the offset, such that if that
were the only error, it would be
On 2014-12-05, Rob nom...@example.com wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 04/12/2014 20:03, Rob wrote:
[]
It is not good practice to use pool on 100-1000 internal systems,
presumably via NAT, to poll time from internet.
Simple advice is: setup 1 NTP server
William Unruh un...@invalid.ca wrote:
For internal systems I would want four servers minimum, two on-site, and
two on the company WAN,
I think that is ridiculous. Introducing too many safeguards often
results in more failures due to extra complexity in the system.
The problem with two is
On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger cswi...@mac.com wrote:
I also make sure that my
timeservers are running in temperature-controlled environments so that
such daily drifts you mention are minimized.
I'm starting to think that people answering questions are unsure of the
real
On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
On Dec 5, 2014, at 3:42 AM, William Unruh un...@invalid.ca wrote:
On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca wrote:
[ ... ]
Actually Miroslav Lichvar IS an expert. He is
On 2014-12-05, David Woolley david@ex.djwhome.demon.invalid wrote:
On 05/12/14 08:42, William Unruh wrote:
Nope. ntp changes the rate of the local clock to correct offsets. That
is all it does. It does not make the rate correct, and then the offset.
Not true. It applies a correction for the
On 05/12/2014 13:15, Martin Burnicki wrote:
[]
You may run into problems if your WAN connection has asymmetric delays,
and thus to 2 servers on the WAN *seem* to have the same offset which
differs from the offset provided by the 2 servers on the local network.
Martin
Yes, I can see what you
On Dec 5, 2014, at 11:47 AM, Paul tik-...@bodosom.net wrote:
On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger cswi...@mac.com wrote:
I also make sure that my
timeservers are running in temperature-controlled environments so that
such daily drifts you mention are minimized.
I'm starting to
On Dec 5, 2014, at 11:53 AM, William Unruh un...@invalid.ca wrote:
[ ... ]
It simply alters the rate at any time so as to decrease the offset, and
it does this measurement by measurement. It has no memory.
This is obviously false. What do you think /etc/ntp.drift is?
It is the offset
On Fri, Dec 5, 2014 at 3:35 PM, Charles Swiger cswi...@mac.com wrote:
Well, we do have time enthusiasts around who like to achieve the best
precision they can, regardless of whether there is a specific business
justification or not. :-)
Sure but that doesn't help someone that just wants a
On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net wrote:
[ ... ]
Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
able to achieve accuracy measured to ~260 nanoseconds:
H. So phk uses a $1,500 rubidium standard as a system oscillator and
you call it inexpensive
On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net wrote:
[ ... ]
Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
able to achieve accuracy measured to ~260 nanoseconds:
H. So phk uses a $1,500 rubidium standard as a system oscillator and
you call it inexpensive
On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net wrote:
[ ... ]
Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
able to achieve accuracy measured to ~260 nanoseconds:
H. So phk uses a $1,500 rubidium standard as a system oscillator and
you call it inexpensive
On 2014-12-05, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
For internal systems I would want four servers minimum, two on-site, and
two on the company WAN,
I think that is ridiculous. Introducing too many safeguards often
results in more failures due to extra
On 2014-12-05, David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 05/12/2014 13:15, Martin Burnicki wrote:
[]
You may run into problems if your WAN connection has asymmetric delays,
and thus to 2 servers on the WAN *seem* to have the same offset which
differs from the offset
On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
On Dec 5, 2014, at 11:53 AM, William Unruh un...@invalid.ca wrote:
[ ... ]
It simply alters the rate at any time so as to decrease the offset, and
it does this measurement by measurement. It has no memory.
This is obviously false. What
21 matches
Mail list logo
