Re: [ntp:questions] NTP offset doesn't change.

Charles Swiger wrote: On Feb 12, 2015, at 1:56 AM, Rob wrote: However, what I observe is that the plots of the offset show the derivative of the environment temperature, which unfortunately cannot be controlled any better. I am considering to locate the crystal that is responsible for the tim

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-13, Paul wrote: > On Thu, Feb 12, 2015 at 7:27 PM, William Unruh wrote: > >> It was based on measurements I made with ntpd >> > > Are you assuming the numbers I provided are based on theory or were you > looking over my shoulder when I perturbed system time by two milliseconds > and wa

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-13, Harlan Stenn wrote: > William Unruh writes: >> On 2015-02-12, Harlan Stenn wrote: > > It would have been far better for folks with those broken kernels to > have simply removed any drift file before starting ntpd. The code to > remove the drift file could have been removed once t

Re: [ntp:questions] NTP offset doesn't change.

On Thu, Feb 12, 2015 at 7:27 PM, William Unruh wrote: > It was based on measurements I made with ntpd > Are you assuming the numbers I provided are based on theory or were you looking over my shoulder when I perturbed system time by two milliseconds and watched it converge to O(10) microseconds

Re: [ntp:questions] NTP offset doesn't change.

On Thu, Feb 12, 2015 at 7:16 PM, William Unruh wrote: > Not really. But it should be distrubing that chrony disciplines clocks > much better ( lower jitter) than does ntpd in normal situations. Why? > And does that have lessons that ntpd could learn from? > If you don't stop fixating on NTPd you

Re: [ntp:questions] NTP offset doesn't change.

William Unruh writes: > On 2015-02-12, Harlan Stenn wrote: > > Bill, > > > > So you believe: > > > > - the broken linux kernel behavior is an acceptable (or at least > > excusable) fact of life, > > Of course not. However, it IS a fact of life, and I have to live in the > real world. nptd spend

Re: [ntp:questions] NTP offset doesn't change.

William Unruh writes: > > Chrony and ntpd have fundamentally different definitions of what it > > means to "provide good time". > > Not really. But it should be distrubing that chrony disciplines clocks > much better ( lower jitter) than does ntpd in normal situations. Why? > And does that have le

Re: [ntp:questions] NTP offset doesn't change.

William Unruh wrote: On 2015-02-12, Charles Swiger wrote: On Feb 12, 2015, at 1:56 AM, Rob wrote: Charles Swiger wrote: On Feb 11, 2015, at 7:23 AM, Rob wrote: However, what I observe is that the plots of the offset show the derivative of the environment temperature, which unfortunately

Re: [ntp:questions] NTP offset doesn't change.

On Feb 12, 2015, at 4:02 PM, William Unruh wrote: >> You're describing a TCXO; using a temperature sensor to compensate for >> thermal >> drift would gain perhaps a factor of 5 accuracy. > > No, that is a hardware solution. There are software solutions-- a > termistor to meaure the temperature o

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Paul wrote: > On Thu, Feb 12, 2015 at 12:00 PM, William Unruh wrote: > >> This means that if you are using say a PPS source, which gives >> microsecond long term offset, it can take many hours to get there >> > > This has been asserted and corrected before -- as in years ago*. A >

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Harlan Stenn wrote: > Bill, > > So you believe: > > - the broken linux kernel behavior is an acceptable (or at least > excusable) fact of life, Of course not. However, it IS a fact of life, and I have to live in the real world. nptd spends many lines of code correcting for rare c

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Harlan Stenn wrote: > William Unruh writes: >> ... And what happens to B when A suddenly begins to >> slew at 2000PPM? > > And how often does this happen? Why does it happen? > > I'm pretty sure that ntpd will notice this and declare that source a > falseticker quickly enough. I

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Charles Swiger wrote: > On Feb 12, 2015, at 1:56 AM, Rob wrote: >> Charles Swiger wrote: >>> On Feb 11, 2015, at 7:23 AM, Rob wrote: > >> However, what I observe is that the plots of the offset show the derivative >> of the environment temperature, which unfortunately cannot be

Re: [ntp:questions] How to adjust clock frequency in FreeBSD 10.1 ?

Rick Thomas writes: > Thanks, Harlan, for the quick reply! > > On Feb 12, 2015, at 1:57 PM, Harlan Stenn wrote: > > > Rick Thomas writes: > >> Hi All, > >>=20 > >> I have a machine with a really bad clock. When I run NTP on it, the > >> freq goes straight to 500.0 (over a period of a few days)

Re: [ntp:questions] How to adjust clock frequency in FreeBSD 10.1 ?

On Feb 12, 2015, at 3:15 PM, Rick Thomas wrote: > Also, googling around a bit seems to indicate that tickadj would not > be appropriate for the “tickles” kernel in FreeBSD-10.1. Sorry, spelling-corrector malfunction! Should be “tickless” kernel. Rick _

Re: [ntp:questions] How to adjust clock frequency in FreeBSD 10.1 ?

Thanks, Harlan, for the quick reply! On Feb 12, 2015, at 1:57 PM, Harlan Stenn wrote: > Rick Thomas writes: >> Hi All, >> >> I have a machine with a really bad clock. When I run NTP on it, the >> freq goes straight to 500.0 (over a period of a few days) and stays there, >> while the offset gro

Re: [ntp:questions] Updating ntpd OSX10.4

Hi, Geoff-- Yes, testing whether your build of ntpd starts and runs normally can be done before rebooting the system. It's not likely that you would encounter any problems after rebooting if the initial test run is fine. Even if ntpd suddenly fails, that's not going to prevent you from starting

Re: [ntp:questions] NTP offset doesn't change.

On Thu, Feb 12, 2015 at 12:00 PM, William Unruh wrote: > This means that if you are using say a PPS source, which gives > microsecond long term offset, it can take many hours to get there > This has been asserted and corrected before -- as in years ago*. A properly configured Linux system with

Re: [ntp:questions] How to adjust clock frequency in FreeBSD 10.1 ?

Rick Thomas writes: > Hi All, > > I=92ve got a machine with a really bad clock. When I run NTP on it, the fr= > eq goes straight to 500.0 (over a period of a few days) and stays there, wh= > ile the offset grows and grows. > > I recently switched this machine from Debian Linux to FreeBSD (wantin

Re: [ntp:questions] NTP offset doesn't change.

William Unruh writes: > ... (Ie something equivalent to ntpd's arbitrary 1000 sec rule-- ie if > the clock is out by 1000 sec ntpd gives up). But whether or not it > should give up, or try its best is something that should be left to > the user, not to some arbitrary rules by the designer. Stateme

[ntp:questions] How to adjust clock frequency in FreeBSD 10.1 ?

Hi All, I’ve got a machine with a really bad clock. When I run NTP on it, the freq goes straight to 500.0 (over a period of a few days) and stays there, while the offset grows and grows. I recently switched this machine from Debian Linux to FreeBSD (wanting to learn more about FreeBSD). Unde

[ntp:questions] Updating ntpd OSX10.4

Hello list, I hope I have the right place to ask this :) I've installed Macports ntp @4.2.8_0 on my OSX10.4 machine (without upgrading dependencies as I don't want gettext breaking bash...). It's built without apparent error and only needs 'sudo port load ntp' to be included in the boot sequenc

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Charles Swiger wrote: > On Feb 12, 2015, at 12:49 AM, William Unruh wrote: >> On 2015-02-11, Charles Swiger mailto:cswi...@mac.com>> >> wrote: >>> On Feb 11, 2015, at 7:23 AM, Rob >> > wrote: But I see it has also been explained elsewhere in the thr

Re: [ntp:questions] NTP offset doesn't change.

William Unruh writes: > ... And what happens to B when A suddenly begins to > slew at 2000PPM? And how often does this happen? Why does it happen? I'm pretty sure that ntpd will notice this and declare that source a falseticker quickly enough. Chrony and ntpd have fundamentally different defin

Re: [ntp:questions] NTP offset doesn't change.

catherine.wei1...@gmail.com writes: > Yes,I just tested it and found that the synchronization of NTP is > really slow. It's well documented. Adjustments are made at the rate of 500ppm. By default that will happen for corrections of up to 128ms. 500ppm is about 43 seconds/day, and a correction o

Re: [ntp:questions] NTP offset doesn't change.

David Taylor wrote: > On 12/02/2015 17:00, William Unruh wrote: > [] >> This means that if you are using say a PPS source, which gives >> microsecond long term offset, it can take many hours to get there, even >> if you or I looking at the offsets could see that it is off by ms after >> the first

Re: [ntp:questions] NTP offset doesn't change.

Charles Swiger wrote: >> However, what I observe is that the plots of the offset show the derivative >> of the environment temperature, which unfortunately cannot be controlled >> any better. I am considering to locate the crystal that is responsible >> for the timing and see if it could be oveni

Re: [ntp:questions] Authenticated TLS "constraints" in ntpd

Miroslav Lichvar writes: > On Wed, Feb 11, 2015 at 02:29:54PM +0100, Terje Mathisen wrote: > > Jan Ceuleers wrote: > > >I'd like to draw this list's attention to an idea that Reyk Floeter > > >floated, namely to use TLS to help sanity-check NTP timestamps: > > > > > >http://marc.info/?l=openbsd-tec

Re: [ntp:questions] NTP offset doesn't change.

Bill, So you believe: - the broken linux kernel behavior is an acceptable (or at least excusable) fact of life, - that should have been predicted and accommodated by stable-running software and algorithms that have been around for decades, - where no other kernel has ever misbehaved in this

Re: [ntp:questions] NTP offset doesn't change.

On 12/02/2015 17:00, William Unruh wrote: [] This means that if you are using say a PPS source, which gives microsecond long term offset, it can take many hours to get there, even if you or I looking at the offsets could see that it is off by ms after the first few poll intervals. [] Almost all

Re: [ntp:questions] NTP offset doesn't change.

On Feb 12, 2015, at 1:56 AM, Rob wrote: > Charles Swiger wrote: >> On Feb 11, 2015, at 7:23 AM, Rob wrote: >>> But I see it has also been explained elsewhere in the thread: ntpd has >>> a maximum on the momentary drift of 500ppm, no matter if it is static >>> or dynamic or the sum of two. I thi

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Rob wrote: > William Unruh wrote: >> On 2015-02-12, Rob wrote: >>> Brian Inglis wrote: On 2015-02-12 03:00, Rob wrote: > catherine.wei1...@gmail.com wrote: >> Yes,I just tested it and found that the synchronization of NTP is really >> slow. > > That is

Re: [ntp:questions] NTP offset doesn't change.

In article , William Unruh wrote: >The complaint of the ntpd people is not the stability of the machine >itself, but the stability of the network, where for example A could use >B and B use A in determining its own time. Is the whole network stable >under this kind of loop. And what happens to B

Re: [ntp:questions] NTP offset doesn't change.

On Feb 12, 2015, at 12:49 AM, William Unruh wrote: > On 2015-02-11, Charles Swiger mailto:cswi...@mac.com>> > wrote: >> On Feb 11, 2015, at 7:23 AM, Rob > > wrote: >>> But I see it has also been explained elsewhere in the thread: ntpd has >>> a maximum on the momentary

Re: [ntp:questions] NTP offset doesn't change.

William Unruh wrote: > On 2015-02-12, Rob wrote: >> Brian Inglis wrote: >>> On 2015-02-12 03:00, Rob wrote: catherine.wei1...@gmail.com wrote: > Yes,I just tested it and found that the synchronization of NTP is really > slow. That is because ntpd is not designed to corre

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Rob wrote: > Charles Swiger wrote: >> On Feb 11, 2015, at 7:23 AM, Rob wrote: > Yes I would prefer that, but chrony does not support local references > so it is useless to me. Yes, it does and has for about 3 or 4 years now. > >>> In practice a changing drift is often caused b

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Philip Homburg wrote: > In article <54db57a8.4030...@oracle.com>, > brian utterback wrote: >>Dr. Mills crafted a wonderful piece of software, amazing for its time, >>but he no longer actively engages us much at all. I understand, that >>isn't his fault. But no one who does activel

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, Rob wrote: > Brian Inglis wrote: >> On 2015-02-12 03:00, Rob wrote: >>> catherine.wei1...@gmail.com wrote: Yes,I just tested it and found that the synchronization of NTP is really slow. >>> >>> That is because ntpd is not designed to correct arbitrary errors that >>> yo

Re: [ntp:questions] NTP offset doesn't change.

In article <54db57a8.4030...@oracle.com>, brian utterback wrote: >Dr. Mills crafted a wonderful piece of software, amazing for its time, >but he no longer actively engages us much at all. I understand, that >isn't his fault. But no one who does actively engage really understands >it or knows how

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12, catherine.wei1...@gmail.com wrote: > On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote: >> On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: >> > However, when I wait for several minutes, the time can be adjusted to >> > the right time. I couldn't see

[ntp:questions] kern does not show in ntpq -crv after ntpd is restarted

Rasberry Pi Raspian 3.18.5 ntp 4.2.6 Using a gps module with PPS, "kern" shows up when doing ntpq -crv. But If ntpd is stop and started, kern does not appear in the output. Just an annoying bug or a major problem? Thanks, Walter ___ questions mailin

Re: [ntp:questions] NTP offset doesn't change.

Brian Inglis wrote: > On 2015-02-12 03:00, Rob wrote: >> catherine.wei1...@gmail.com wrote: >>> Yes,I just tested it and found that the synchronization of NTP is really >>> slow. >> >> That is because ntpd is not designed to correct arbitrary errors that >> you have applied externally. It is de

Re: [ntp:questions] NTP offset doesn't change.

On Thu, Feb 12, 2015 at 3:43 AM, William Unruh wrote: > It is hard to complain about a non-existant product. As has been previously mentioned ntimed(-client) is in early release. I've been running it since late December. ___ questions mailing list qu

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-12 03:00, Rob wrote: catherine.wei1...@gmail.com wrote: Yes,I just tested it and found that the synchronization of NTP is really slow. That is because ntpd is not designed to correct arbitrary errors that you have applied externally. It is designed to lock to the correct time and

Re: [ntp:questions] NTP offset doesn't change.

catherine.wei1...@gmail.com wrote: > Yes,I just tested it and found that the synchronization of NTP is really slow. That is because ntpd is not designed to correct arbitrary errors that you have applied externally. It is designed to lock to the correct time and stay locked to that (within a few

Re: [ntp:questions] NTP offset doesn't change.

Charles Swiger wrote: > On Feb 11, 2015, at 7:23 AM, Rob wrote: >> But I see it has also been explained elsewhere in the thread: ntpd has >> a maximum on the momentary drift of 500ppm, no matter if it is static >> or dynamic or the sum of two. I think that is not warranted. > > Do you believe th

Re: [ntp:questions] NTP offset doesn't change.

On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote: > On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: > > However, when I wait for several minutes, the time can be adjusted to > > the right time. I couldn't see the gradual changes of offset. Is that > > normal? > >

Re: [ntp:questions] Authenticated TLS "constraints" in ntpd

On Wed, Feb 11, 2015 at 02:29:54PM +0100, Terje Mathisen wrote: > Jan Ceuleers wrote: > >I'd like to draw this list's attention to an idea that Reyk Floeter > >floated, namely to use TLS to help sanity-check NTP timestamps: > > > >http://marc.info/?l=openbsd-tech&m=142356166731390&w=2 > > > Isn't p

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-11, Paul wrote: > On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn wrote: > >> There are times "repair" is perfectly acceptable, and we do that. >> >> There are times "replace" is better, and we do that. >> > > My point is a long drawn-out discussion of changes to the core of ntp seem > l

Re: [ntp:questions] NTP offset doesn't change.

On 2015-02-11, Charles Swiger wrote: > On Feb 11, 2015, at 7:23 AM, Rob wrote: >> But I see it has also been explained elsewhere in the thread: ntpd has >> a maximum on the momentary drift of 500ppm, no matter if it is static >> or dynamic or the sum of two. I think that is not warranted. > > Do