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

On Mon, Feb 16, 2015 at 1:11 AM, William Unruh wrote: > But that is not what you said. When I asked how ntimed works you > answered that it disciplines the computer clock. > BZZT! You said: "Be interesting to see how and what it does." To which I replied: "Since I've told you how it does an

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

On 2015-02-16, Paul wrote: > On Sun, Feb 15, 2015 at 1:18 PM, William Unruh wrote: > >> It I say to someone-- I hear you are trying out the new >> Subaru, I wonder how it works >> > > If you ask me how my new Subaru works I'd say fine. If you ask me how much But that is not what you said. When

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

On Sun, Feb 15, 2015 at 1:18 PM, William Unruh wrote: > Thank you. I had no idea what the new version was called, and saw > someone call it timed. Sorry if it confused you. > This means you're not paying attention to details. It also means you're not reading PHK's notes. > I wanted YOUR summa

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

Harlan Stenn wrote: David Lord writes: ... The one big flaw with ntpd is that when motherboard temperature changes too quickly the ntpd control loop is broken and ntp offset can rise from < 300u to > 10ms. That might have been a false alarm. I've not yet been able to search all the logs. I'

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

In article , William Unruh wrote: >The documentation has some, but much is in the code. I think that's bad situation if you want the ideas embedded in the code to be adopted by other implementations. -- We just programmed the computers to revive us when it was all over... they were index lin

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

On 2015-02-15, Philip Homburg wrote: > In article , > William Unruh wrote: >>I bring up chrony not to discuss it as a program but todiscuss its >>philosophy of clock control and its design. It presents an alternative >>to the approach of ntpd, which ntimed appears to be following. > > There is

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

In article , William Unruh wrote: >I bring up chrony not to discuss it as a program but todiscuss its >philosophy of clock control and its design. It presents an alternative >to the approach of ntpd, which ntimed appears to be following. There is plenty of documentation on how NTP was designed.

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

On 2015-02-15, Paul wrote: > On Sat, Feb 14, 2015 at 11:21 PM, William Unruh wrote: > >> If you demand that I give >> detailed explanation > > > You started off down the ntpd versus chrony path again. > "To get the discussion started, lets compare some of the differences > between chrony and nt

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

On Sat, Feb 14, 2015 at 11:21 PM, William Unruh wrote: > If you demand that I give > detailed explanation You started off down the ntpd versus chrony path again. "To get the discussion started, lets compare some of the differences between chrony and ntpd" That's not useful. You've spent year

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

On 2015-02-15, David Lord wrote: > William Unruh wrote: >> On 2015-02-14, Paul wrote: >>> On Sat, Feb 14, 2015 at 2:09 PM, William Unruh wrote: >>> >>> >>> Yes but you said >>> "This means that if you are using say a PPS source, which gives >>> microsecond long term offset, it can take many hou

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

David Lord writes: > ... The one big flaw with ntpd is that when motherboard temperature > changes too quickly the ntpd control loop is broken and ntp offset can > rise from < 300u to > 10ms. Assuming the above is true (and I have no reason to doubt David's numbers) I have to wonder if it would be

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

On Sat, Feb 14, 2015 at 6:38 PM, William Unruh wrote: > > When timed is actually out I may be interested in testing it again. > Ntimed-client. Again? So you've installed the code? < https://github.com/bsdphk/Ntimed> That seems unlikely. Read this:

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

William Unruh wrote: On 2015-02-14, Paul wrote: On Sat, Feb 14, 2015 at 2:09 PM, William Unruh wrote: Yes but you said "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" and I was responding to that. If you ref

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

On 2015-02-14, Paul wrote: > On Sat, Feb 14, 2015 at 2:09 PM, William Unruh wrote: > > > Yes but you said > "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" > and I was responding to that. If you refuse to accep

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

On Sat, Feb 14, 2015 at 2:09 PM, William Unruh wrote: > Because ntpd is what I know. Except you've admitted you don't know NTPd. > If you are saying that this is all up in the air again with > the new replacement, that would be great. But I have seen no evidence > thereof in discussions here.

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

On 2015-02-14, Paul wrote: > On Fri, Feb 13, 2015 at 8:48 PM, William Unruh wrote: > > However you've not responded to my question regarding your deep concerns. > For years you've complained about the ntpd pll and on occasion suggested > chrony. Now a replacement is being developed. So why do y

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

On Fri, Feb 13, 2015 at 8:48 PM, William Unruh wrote: > > > > I had a properly set up PPS source to do the comparison. > > As did I. > Ooops, I see that the text/plain part of the message was damaged. I was quoting you saying: " I had a properly set up PPS source" and my response was we have no

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

On 2015-02-13, Paul wrote: > On Fri, Feb 13, 2015 at 12:42 AM, William Unruh wrote: > >> OK, so we seem to have two different sets of experiments with very >> different results. Note that I did not erase the drift file, or restart >> ntpd after my perturbation. >> > > Okay, I offset my clock by 1

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

David Lord wrote: > Rob wrote: >> Terje Mathisen wrote: >>> 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 control

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

On Feb 12, 2015, at 11:21 PM, Terje Mathisen wrote: > I've considered packing some insulation around the crystal, this would tend > to stabilize (while also increasing) the temperature, but this would also be > likely to reduce its lifetime, and the motherboard would probably conduct > heat too

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

On Fri, Feb 13, 2015 at 12:42 AM, William Unruh wrote: > OK, so we seem to have two different sets of experiments with very > different results. Note that I did not erase the drift file, or restart > ntpd after my perturbation. > Okay, I offset my clock by 100ms without restarting ntpd. It took

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

Rob wrote: Terje Mathisen wrote: 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 cry

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

Terje Mathisen wrote: > 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

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

On Fri, Feb 13, 2015 at 05:42:54AM +, William Unruh wrote: > 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

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

William Unruh wrote: > No, that is a hardware solution. There are software solutions-- a > termistor to meaure the temperature of the crystal ( or somethign > nearby) which feeds that measurement to the OS. the revised ntp then > reads the temperature, and corrects the drift rate as a function of

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

David Lord wrote: Solutions that measure the temperature require calibration for the individual crystal as with the cheap crystals used the drift per deg C can be either positive or negative and also depending on "cut" of the crystal can follow a parabolic or "lazy S" curve. The only reasonable

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] 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] 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

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] 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

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] 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

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

Paul writes: > 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 > less than prod

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

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 that a clock which loses or gains

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

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 less than productive when the announced w

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

Paul writes: > On Wed, Feb 11, 2015 at 8:22 AM, brian utterback > wrote: > > > But no one who does actively engage really understands > > it or knows how to improve it. Unruh has a point, we don't know if there > > isn't a better way built on statistical analysis. > > > > > Since it seems the NTF

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

On 2015-02-11, Terje Mathisen wrote: > William Unruh wrote: >> On 2015-02-11, Harlan Stenn wrote: >>> William Unruh writes: On 2015-02-10, Terje Mathisen wrote: And as far as I can see, 500 or 5000 makes little difference to the control loop. Yes, it is harder for other systems to

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

On 2015-02-11, Harlan Stenn wrote: > William Unruh writes: >> On 2015-02-11, Harlan Stenn wrote: >> > It's one thing if a system rarely steps. It's a bit different if those >> > steps happen more frequently. >> >> Yes. And it is either equally rare that the system will go over 500PPM, >> but so

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

On 2015-02-11, Jochen Bern wrote: > On 02/11/2015 10:01 AM, Rob wrote: >> Terje Mathisen wrote: >>> The 500 ppm limit is not at all arbitrary! >>> >>> In fact, it was originally just 100 ppm, but when too many systems >>> turned up with a system clock which was a bit too far out, Prof Mills >>>

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

Jochen Bern wrote: > However, I've also seen hardware occasionally flip-flopping from -900 to > +1100 and back, complete with the developers of the firmware blaming "a > bug in ntpd" for failure to discipline *that*. Ok that is different, it is not a static drift. But I see it has also been expl

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

On 02/11/2015 10:01 AM, Rob wrote: > Terje Mathisen wrote: >> The 500 ppm limit is not at all arbitrary! >> >> In fact, it was originally just 100 ppm, but when too many systems >> turned up with a system clock which was a bit too far out, Prof Mills >> redid the control loop to allow a 500 ppm

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

On Wed, Feb 11, 2015 at 8:22 AM, brian utterback wrote: > But no one who does actively engage really understands > it or knows how to improve it. Unruh has a point, we don't know if there > isn't a better way built on statistical analysis. > > Since it seems the NTF "proposal" is to replace rathe

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

William Unruh wrote: On 2015-02-11, Harlan Stenn wrote: William Unruh writes: On 2015-02-10, Terje Mathisen wrote: And as far as I can see, 500 or 5000 makes little difference to the control loop. Yes, it is harder for other systems to follow one with a large drift, but it is even harder to f

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

On 2/11/2015 2:12 AM, Harlan Stenn wrote: > William Unruh writes: >> > On 2015-02-10, Terje Mathisen wrote: >>> > > William Unruh wrote: > >> No. It only does that for "offsets from Hades". The Ones from Hell, > >> ntpd > >> abandons all hope and quits. ( Hades is 128ms to 1000 se

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

William Unruh writes: > On 2015-02-11, Harlan Stenn wrote: > > It's one thing if a system rarely steps. It's a bit different if those > > steps happen more frequently. > > Yes. And it is either equally rare that the system will go over 500PPM, > but sometimes a computer can have a large "natural

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

Terje Mathisen wrote: > The 500 ppm limit is not at all arbitrary! > > In fact, it was originally just 100 ppm, but when too many systems > turned up with a system clock which was a bit too far out, Prof Mills > redid the control loop to allow a 500 ppm range. > > It could have been a lot more,

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

On 2015-02-11, Harlan Stenn wrote: > William Unruh writes: >> On 2015-02-10, Terje Mathisen wrote: >> > William Unruh wrote: >> >> No. It only does that for "offsets from Hades". The Ones from Hell, ntpd >> >> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is >> >> >1000 se

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

William Unruh writes: > On 2015-02-10, Terje Mathisen wrote: > > William Unruh wrote: > >> No. It only does that for "offsets from Hades". The Ones from Hell, ntpd > >> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is > >> >1000 sec) > >> Ie, for <128ms, ntp will try to sle

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

On 2015-02-10, Brian Inglis wrote: > On 2015-02-10 13:26, William Unruh wrote: >> However if this is the first time this running of ntpd has encountered >> this, eg at startup, if you use -x option it will jump the time even if the >-g (panicGate) Oops, you are

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

On 2015-02-10, Terje Mathisen wrote: > William Unruh wrote: >> On 2015-02-10, 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 off

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

William Unruh wrote: On 2015-02-10, 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? Assuming that you're using a m

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

On 2015-02-10 13:26, William Unruh wrote: However if this is the first time this running of ntpd has encountered this, eg at startup, if you use -x option it will jump the time even if the -g (panicGate) offset is >1000 sec. -- Take care. Thanks, Brian Inglis

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

On 2015-02-10, 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? > > Assuming that you're using a minimalistic

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

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? Assuming that you're using a minimalistic configuration: Yes. ntpd would take almost

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

On 10/02/15 05:15, catherine.wei1...@gmail.com wrote: Hi, I'm using the ntpd to sync time. When I change the current date for exampe to 0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10 03:02, then I run "ntpq -p" for several times, the offset doesn't change at all. Garba

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

catherine.wei1...@gmail.com wrote: > Hi, I'm using the ntpd to sync time. When I change the current date for > exampe to 0210020215 (2015-02-10 02:02), the actually current time is > 2015-02-10 03:02, then I run "ntpq -p" for several times, the offset doesn't > change at all. ntpd is not desig

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

By the way, the ntp version I'm using is 4.2.8p1. Catherine. On Tuesday, February 10, 2015 at 1:15:21 PM UTC+8, catherin...@gmail.com wrote: > Hi, I'm using the ntpd to sync time. When I change the current date for > exampe to 0210020215 (2015-02-10 02:02), the actually current time is > 2015-02

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

Hi, I'm using the ntpd to sync time. When I change the current date for exampe to 0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10 03:02, then I run "ntpq -p" for several times, the offset doesn't change at all. ~ # ntpq -p remote refid st t when poll re