>> I'm missing something. My setup doesn't die. It just steps the clock,
>> and repeats the drift-off then step dance several times until the drift
>> gets close enough.
>Maybe you aren't running Linux?
That's what I'm running.
--
These are my opinions, not necessarily my employer's. I hate
Hal Murray wrote:
>> And if it is the frequency that is out ( as it always will be these days of
>> linux because of the bugs in the kernel frequency standardisation) then
>> that one step will not kick in until about an hour later ( and the system
>> could die a horrible death, because the phase o
>And if it is the frequency that is out ( as it always will be these days of
>linux because of the bugs in the kernel frequency standardisation) then
>that one step will not kick in until about an hour later ( and the system
>could die a horrible death, because the phase offset intially is correct
Richard B. Gilbert wrote:
> Unruh wrote:
>> I should NOT have to check up on the drift file to see if it is correct.
>> That is the computer's job. ntp should NOT take 10 hours to correct a wrong
>> drift file. With a 16 sec poll, ntp should NOT have a 1 hour time constant.
>
> Your opinion! The
ma...@ntp.isc.org (Danny Mayer) writes:
>Richard B. Gilbert wrote:
>> Unruh wrote:
>>> I should NOT have to check up on the drift file to see if it is correct.
>>> That is the computer's job. ntp should NOT take 10 hours to correct a wrong
>>> drift file. With a 16 sec poll, ntp should NOT have a
Richard B. Gilbert wrote:
> Unruh wrote:
>> I should NOT have to check up on the drift file to see if it is correct.
>> That is the computer's job. ntp should NOT take 10 hours to correct a wrong
>> drift file. With a 16 sec poll, ntp should NOT have a 1 hour time constant.
>
> Your opinion! The
The key seems to be the lines:
etemp = min(mu, (u_long)ULOGTOD(sys_poll));
dtemp = 4 * CLOCK_PLL * ULOGTOD(sys_poll);
plladj = fp_offset * etemp / (dtemp * dtemp);
Ie if we assume that the etemp is determined by the poll interval, we have
plladj=fp_offset /(16*CLOCK_PLL^2*(Sy
Martin Burnicki wrote:
> David J Taylor wrote:
[]
> As mentioned in another reply, AFAIR older versions of the NTP daemon
> did converge quite a bit faster than recent versions.
[]
>> version="ntpd 4.2.0-a Sun May 8 06:01:21 UTC 2005 (1)"
>
> Now the question is how a recent version of ntpd woul
Hal Murray wrote:
>>Note, if you are running gps, why have a poll level 6? The recommendation
>>for ref- clocks is poll level 4?
>
> Where/who does that recommendation come from?
I don't have seen this recommendation on the internet, but from our
experience with the devices we sell initial conver
David J Taylor wrote:
> Unruh wrote:
> []
>> An hour later, it was still 7ms off, another hour, 2.6ms and another
>> hour
>> later, still 1.2 ms off. Ie, only after about 6 hours was it within a
>> ms of
>> the correct time. Now, usually this PPS controls the time to within
>> about 2us (not ms, us
Unruh wrote:
> Evandro Menezes <[EMAIL PROTECTED]> writes:
> Sure. Mine is a stock Linux PC hardware, and running 4.2.4p4, not 4.2.0
>
> It is possible a bug has crept into the software,
AFAIR older versions of ntpd *did* converge quite a bit faster than the
current -stable and -dev versions. I'm
David Woolley wrote:
> Nicola Berndt wrote:
>
>>
>> What really bothers me is that ntp is totally capable of telling me its
>> offset (and so how wrong the time /being served/ is) but not capable of
>
> Careful. The theory behind ntpd is that, in normal operation, offset
> consists only of meas
Nicola Berndt wrote:
[]
> I just recently tested my ntp-(pps-)machine in a large open hall and
> found it to be unable to settle down even after a day! It looks like
> the temperature changes in this open hall environment make the machine
> jitter with values between -200 and 200 ms regularly and
>
I will top post this reply since there is too much garbled nonesense.
ntp is capable of disciplining the local clock on a run of the mill PC with
a $60 GPS receiver to a few microseconds. So lets take that as the
standard.
The question I have is why, given a poll interval of 16 seconds, the tim
Nicola Berndt wrote:
>
> What really bothers me is that ntp is totally capable of telling me its
> offset (and so how wrong the time /being served/ is) but not capable of
Careful. The theory behind ntpd is that, in normal operation, offset
consists only of measurement error, not of real clock
David Woolley schrieb:
> Speechless wrote:
>
>
>> b) you are experiencing a genuine problem not encountered by anyone else
>>
>
> Lots of people report poor startup behaviour. Two have abandoned ntpd
> on this newsgroup in the last few weeks because of this.
>
>
>> It should not be nec
Speechless wrote:
> b) you are experiencing a genuine problem not encountered by anyone else
Lots of people report poor startup behaviour. Two have abandoned ntpd
on this newsgroup in the last few weeks because of this.
>
> It should not be necessary to spell it out for you that if you are
>
On Mon, 03 Nov 2008 06:25:15 +, Unruh wrote:
> Speechless <[EMAIL PROTECTED]> writes:
>
>>On Sat, 01 Nov 2008 03:17:15 +, Unruh wrote:
>
>>> Just another data point on the behaviour of ntp. My ntp went down (
>>> due to something removing the ntp user from the password file).
>
>>Someth
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>> David Woolley wrote:
>>> Richard B. Gilbert wrote:
>>>
Your opinion! The designers/developers evidently disagree.
>>> Designer, singular, as far as these issues are concerned.
>>>
>>> At least two new people have disagreed
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>David Woolley wrote:
>> Richard B. Gilbert wrote:
>>
>>>
>>> Your opinion! The designers/developers evidently disagree.
>>
>> Designer, singular, as far as these issues are concerned.
>>
>> At least two new people have disagreed with the design
David Woolley wrote:
> Richard B. Gilbert wrote:
>
>>
>> Your opinion! The designers/developers evidently disagree.
>
> Designer, singular, as far as these issues are concerned.
>
> At least two new people have disagreed with the designer, recently, on
> the newsgroup, and decided that NTP is
Richard B. Gilbert wrote:
>
> Your opinion! The designers/developers evidently disagree.
Designer, singular, as far as these issues are concerned.
At least two new people have disagreed with the designer, recently, on
the newsgroup, and decided that NTP is unsuitable for their application
be
On Sun, Nov 2, 2008 at 3:27 PM, David Woolley
<[EMAIL PROTECTED]> wrote:
> Richard B. Gilbert wrote:
>> The internet of today is similar. It may be a little better but I
>> wouldn't count on it!
> For one thing, the components from which it is made are 1,000 times
> faster and have 1,000 times the
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>> Unruh wrote:
>>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>>
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>> Unruh wrote:
>>> "David J Taylor" <[EMAIL PROTECTED]> writes:
>>>
Speechless <[EMAIL PROTECTED]> writes:
>On Sat, 01 Nov 2008 03:17:15 +, Unruh wrote:
>> Just another data point on the behaviour of ntp. My ntp went down ( due
>> to something removing the ntp user from the password file).
>Something? FULL STOP! I'd consider the machine to be compromised
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>
>>> Unruh wrote:
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
> Unruh wrote:
>> "David J Taylor" <[EMAIL PROTECTED]> writes:
>>
>>> Hal Murray wrote:
On Sat, 01 Nov 2008 03:17:15 +, Unruh wrote:
> Just another data point on the behaviour of ntp. My ntp went down ( due
> to something removing the ntp user from the password file).
Something? FULL STOP! I'd consider the machine to be compromised and
in need of a rebuild from scratch.
Roo
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>> Unruh wrote:
>>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>>
Unruh wrote:
> "David J Taylor" <[EMAIL PROTECTED]> writes:
>
>> Hal Murray wrote:
> Try switching it off, changing the value int he d
David Woolley wrote:
> Richard B. Gilbert wrote:
>
>>
>> The internet of today is similar. It may be a little better but I
>> wouldn't count on it!
>>
> For one thing, the components from which it is made are 1,000 times
> faster and have 1,000 times the memory.
>
> (There are other difference
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>
>>> Unruh wrote:
"David J Taylor" <[EMAIL PROTECTED]> writes:
> Hal Murray wrote:
Try switching it off, changing the value int he drift file by say
Richard B. Gilbert wrote:
>
> The internet of today is similar. It may be a little better but I
> wouldn't count on it!
>
For one thing, the components from which it is made are 1,000 times
faster and have 1,000 times the memory.
(There are other differences, like the de-skilling of sytem ma
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>> Unruh wrote:
>>> "David J Taylor" <[EMAIL PROTECTED]> writes:
>>>
Hal Murray wrote:
>>> Try switching it off, changing the value int he drift file by say
>>> 50PPM and
>>> then switching it on again, and see how
David Woolley wrote:
> Richard B. Gilbert wrote:
>
>> preferred algorithm! Dave designed ntpd to cope with the, usually
>> horrible, behavior of the internet. This is not necessarily the best
>
> That was the internet of some 20 years ago.
The internet of today is similar. It may be a littl
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "David J Taylor" <[EMAIL PROTECTED]> writes:
>>
>>> Hal Murray wrote:
>> Try switching it off, changing the value int he drift file by say
>> 50PPM and
>> then switching it on again, and see how long it takes to recover
Richard B. Gilbert wrote:
> preferred algorithm! Dave designed ntpd to cope with the, usually
> horrible, behavior of the internet. This is not necessarily the best
That was the internet of some 20 years ago.
___
questions mailing list
questions@li
Unruh wrote:
> "David J Taylor" <[EMAIL PROTECTED]> writes:
>
>> Hal Murray wrote:
> Try switching it off, changing the value int he drift file by say
> 50PPM and
> then switching it on again, and see how long it takes to recover
> from that.
Why would I do that? The drift va
"David J Taylor" <[EMAIL PROTECTED]> writes:
>Hal Murray wrote:
Try switching it off, changing the value int he drift file by say
50PPM and
then switching it on again, and see how long it takes to recover
from that.
>>
>>> Why would I do that? The drift values rarely change by
"David J Taylor" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>[]
>> So how long does it take your system to correct a bad drift file?
>Oh, much longer, but that just suggests that your drift file is bad, not
>any inherent fault in NTP.
Note, if you are running gps, why have a poll level 6?
Unruh wrote:
[]
> So how long does it take your system to correct a bad drift file?
Oh, much longer, but that just suggests that your drift file is bad, not
any inherent fault in NTP.
>>> Note, if you are running gps, why have a poll level 6? The
>>> recommendation
>>> for ref- clocks is poll l
Hal Murray wrote:
>>> Try switching it off, changing the value int he drift file by say
>>> 50PPM and
>>> then switching it on again, and see how long it takes to recover
>>> from that.
>
>> Why would I do that? The drift values rarely change by more than
>> five, certainly not by 50. If you are
"David J Taylor" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>[]
>> Nope, it is not my "ssytem" if by that you mean my computer. The
>> convergence is a beautiful exponential convergence with a time scale
>> of 1
>> hour almost exactly. That is not hardware. That is the software ntp
>> protocol.
>J
>Note, if you are running gps, why have a poll level 6? The recommendation
>for ref- clocks is poll level 4?
Where/who does that recommendation come from?
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing li
>> Try switching it off, changing the value int he drift file by say
>> 50PPM and
>> then switching it on again, and see how long it takes to recover from
>> that.
>Why would I do that? The drift values rarely change by more than five,
>certainly not by 50. If you are seeing a change of 50, the
Unruh wrote:
[]
> Nope, it is not my "ssytem" if by that you mean my computer. The
> convergence is a beautiful exponential convergence with a time scale
> of 1
> hour almost exactly. That is not hardware. That is the software ntp
> protocol.
Just along the lines that if my system converges in 10
"David J Taylor" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>[]
>> An hour later, it was still 7ms off, another hour, 2.6ms and another
>> hour
>> later, still 1.2 ms off. Ie, only after about 6 hours was it within a
>> ms of
>> the correct time. Now, usually this PPS controls the time to within
>>
Evandro Menezes <[EMAIL PROTECTED]> writes:
>Could it be a poor crystal being affected by the temperature change?
>After all, even with a solid PPS, the system time is controlled by its
>crystals.
Nope. As I said it is a beautiful exponential convergence of the phase
offset with a time scale of a
Could it be a poor crystal being affected by the temperature change?
After all, even with a solid PPS, the system time is controlled by its
crystals.
David showed data for his Sun system and even x86 systems by Sun have
pretty good crystals.
HTH
___
qu
David J Taylor wrote:
[]
> As a comparison, I have a very old Pentium 133 system here running
> FreeBSD with local GPS PPS and some other Internet-based stratum 2/3
> servers (probably NTP pool and a fixed name). I'm sure it's well
> within a few minutes for it to reach it's full accuracy (tens of
Unruh wrote:
[]
> An hour later, it was still 7ms off, another hour, 2.6ms and another
> hour
> later, still 1.2 ms off. Ie, only after about 6 hours was it within a
> ms of
> the correct time. Now, usually this PPS controls the time to within
> about 2us (not ms, usec) but it is apparently going t
Just another data point on the behaviour of ntp. My ntp went down ( due to
something removing the ntp user from the password file). When I brought it
back up again, the time was out and I think the drift file was out.
I have three sources-- a stratum 2 nearby server, a distant stratum 1 server
50 matches
Mail list logo
