Dave,
Thanks for the test. I verified the same thing. Note that the measured
offset at the end of the frequency measurement phase was very small, so
the net frequency measurement should be the same as Solaris. Obviously,
FreeBSD is doing something very different than Solaris. I suspect Linux
On Mon, Nov 8, 2010 at 3:54 PM, Miroslav Lichvar wrote:
> No, it really is about the 500ppm limit. In loopstats is only the
> measured clock frequency, it doesn't contain the phase
> adjustments which are included in the adjtime() argument.
Miroslav shared the following patch with me, which limit
On Mon, Nov 08, 2010 at 03:09:57PM +, David L. Mills wrote:
> It is not an issue of limiting the slew rate to less than
> 500 PPM, as that is in fact the result shown in the looopstats
> trace.
No, it really is about the 500ppm limit. In loopstats is only the
measured clock frequency, it does
Dave,
Notice toward the end of the calibration period adjtime() is called with
only a small offset, so issues like the slew rate and residual offset
are moot. Those calls should minimize the residual and the actual clock
time should be within the measuement offset. Apparentyl, at least the
Fr
On Mon, Nov 08, 2010 at 05:30:22AM +, Dave Hart wrote:
> On Mon, Nov 8, 2010 at 05:14 UTC, David L. Mills wrote:
> > At this point I am prepared to
> > abandon the mission entirely, as I don't want to get bogged down with the
> > specifics of each idiosyncratic operating system. Accordingly, I
On Mon, Nov 8, 2010 at 05:14 UTC, David L. Mills wrote:
> Thanks for the test. I verified the same thing. Note that the measured
> offset at the end of the frequency measurement phase was very small, so the
> net frequency measurement should be the same as Solaris. Obviously, FreeBSD
> is doing so
I regret to report ntpd 4.2.7p79, with the freq_mode fix, is still
unable to estimate the frequency on the FreeBSD 6.4 test machine. I
repeated yesterday's tests after updating ntpd, still using the daemon
loop and four sources with iburst and maxpoll 6.
55507 47027.172 0.000131624 80.505 0.00029
On 2010-11-05, David L. Mills wrote:
> Bo;;.
>
> At the time the clock is read and the adjustment has not completed, the
> current offset is known, regardless of the residual offset not yet
> amortized. At this point there is no need to consider the residual
> offset, as a new offset has been d
Dave,
I think I have hunted down what is going on. It takes some serious
investigation. Turns out the modern adjtime(), at least in some systems,
is far from what I knew some years back. I have already described that
era from what I knew of SunOS, Ultrix, OSF/1 and Tru64, since I or my
gradua
On Sat, Nov 6, 2010 at 03:34 UTC, David L. Mills wrote:
> Now to the apparent initial frequency error. This is new, as tests in the
> past have not confirmed that. I need to plant some debug code in
> direct-freq().
I ran several more tests without a drift file on the same FreeBSD 6.4
machine, bu
Dave,
We need some order here, as what you report with a pre-existing
frequency file is quite dubious. Consider the two runs here, both with
an existing frequency file and starting at both plus and minus 90 ms
offsets:
howland initial offset -91.7 ,s
55505 63959.804 -0.01000 -7.250 0.00
I said:
> Try it without the drift file and with -100ms if your natural drift is
> a positive number, or +100ms if your drift is negative.
I neglected to notice my prior test with the erroneous frequency
calculation was with the kernel loop. It may be better with "disable
kernel", I'm checking.
On Fri, Nov 5, 2010 at 20:43 UTC, David L. Mills wrote:
> The test I did was to run two tests using initial offsets of +90 ms and -90
> s. The tests use ntptime -f 500 or -f -500 for three minutes in order to
> change the offset to about +-90 ms, then start ntpd normally. The frequency
> file was
Dave,
Further investigation continues; however, you have a fundamental
misunderstanding of the "slew limit" in Soalris or any other
BSD-semantics system. The slew is not a limit, it is an intrinsic
constant equal to 500 PPM. The slew is implemented in this way. When
adjtime() is called, it co
On Nov 5, 11:53 am, "David L. Mills" wrote:
>
> If linux does not agree with the standard Unix semanitcs, which I know
> for a fact has been in BSD Unix since 1986 at least, Linux will not work
> properly. However, absent second-order effects, performance will be no
> worse than if the training pe
I have reproduced the problems Miroslav reports with the new startup
behavior on FreeBSD, indicating the problem is not isolated to Linux.
My guess is Solaris is the outlier here, because its adjtime() doesn't
enforce a 500 PPM cap. The system I'm using is psp-fb2, a FreeBSD 6.4
x86 machine with t
Bo;;.
At the time the clock is read and the adjustment has not completed, the
current offset is known, regardless of the residual offset not yet
amortized. At this point there is no need to consider the residual
offset, as a new offset has been determined regardless of the residual
offset. Th
On 2010-11-05, David L. Mills wrote:
> Bill,
>
> You have absolutely no idea what you are talking about and you do reveal
> an abysmal lack of understudying of control theory. To incorporate past
Not if done properly.
> history in future controls when the current control variable is measured
Dave,
How does this issue persist? NTP does not limit the slew rate, adjtime()
does, and NTP does not care. The adjtime() semantics is the same whether
or not the slew rate is "exceeded" and for any programmed offset. The
only issue is whether the programmed offset is complete in the time
al
Bill,
You have absolutely no idea what you are talking about and you do reveal
an abysmal lack of understudying of control theory. To incorporate past
history in future controls when the current control variable is measured
violates the time delay constrain. Go back to the books.
Dave
unruh
On Thu, Nov 4, 2010 at 22:22 UTC, David L. Mills wrote:
> Miroslav,
>
> IT IS NOT S BUG. Specifically, the Unix adjtime() semantics allows any
> argument, even if bizarre. The slew rate is constant at 500 PPM; the
> duration of the slew is calculate to amortize the argument as given. There
> is no
On 2010-11-04, David L. Mills wrote:
> Miroslav,
>
> The NTP daemon purposely ignores the leftover from adjtime(). To do
> otherwise would invite massive instability. Each time an NTP update is
> received, a new offset estimate is available regardless of past history.
> Therefore, the intent is
Miroslav,
IT IS NOT S BUG. Specifically, the Unix adjtime() semantics allows any
argument, even if bizarre. The slew rate is constant at 500 PPM; the
duration of the slew is calculate to amortize the argument as given.
There is no way to "exceed" the slew rate; it is constant. You and Linux
m
On Thu, Nov 04, 2010 at 08:32:06PM +, David L. Mills wrote:
> Wrong. The damon starts off be setting the frequency to zero, as you
> can see in the protostats. When the frequency calibration is
> complete, the frequency is set directly, as you can also see in the
> protostats. It could be a mas
Miroslav,
Wrong. The damon starts off be setting the frequency to zero, as you can
see in the protostats. When the frequency calibration is complete, the
frequency is set directly, as you can also see in the protostats. It
could be a massively broken motherboard might set the frequency larger
Miroslav,
The NTP daemon purposely ignores the leftover from adjtime(). To do
otherwise would invite massive instability. Each time an NTP update is
received, a new offset estimate is available regardless of past history.
Therefore, the intent is to ignore all past history and start with a
fr
On Wed, Nov 03, 2010 at 03:54:33PM +, David L. Mills wrote:
> The daemon clamps the adjtime() (sic) offset to 500 PPM, which is
> consistent with ordinary Unix semantics.
No, during that new fast phase correction on start it's not clamped to
anything. That's the bug I'm hitting here.
If 500
On Wed, Nov 03, 2010 at 04:06:39PM +, Dave Hart wrote:
> On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar
> wrote:
> > On Tue, Nov 02, 2010 at 10:03:30PM +, David L. Mills wrote:
> >> I ran the same test here on four different machines with the
> >> expected results. These included Sola
David,
In Mirsolav's test, the frequency was computed at 172 PPM, which is well
within the capabilities of the algorithm. On the other hand, even if the
intrinsic hardware frequency error is more than 500 PPM, the frequency
will be set to 500 PPM and the daemon will continue normally, but will
David L. Mills wrote:
I don't think that is right. The adjtime() call can be in principle
anything, accoridng to the Solaris and FreeBSD man pages, but the rate
of adjustment is fixed at 500 PPM in the Unix implementation. If the
Linux argument is limited to 500 microseconds, Linux is essentia
David L. Mills wrote:
> > I don't think that is right. The adjtime() call can be in
> > principle anything, accoridng to the Solaris and FreeBSD
> > man pages, but the rate of adjustment is fixed at 500 PPM
> > in the Unix implementation. If the Linux argument is
> > limited to 500 microsecond
David L. Mills wrote:
> I don't think that is right. The adjtime() call can be in
> principle anything, accoridng to the Solaris and FreeBSD
> man pages, but the rate of adjustment is fixed at 500 PPM
> in the Unix implementation. If the Linux argument is
> limited to 500 microseconds, Linux i
Dave,
I don't think that is right. The adjtime() call can be in principle
anything, accoridng to the Solaris and FreeBSD man pages, but the rate
of adjustment is fixed at 500 PPM in the Unix implementation. If the
Linux argument is limited to 500 microseconds, Linux is essentially
unusable wi
On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar wrote:
> On Tue, Nov 02, 2010 at 10:03:30PM +, David L. Mills wrote:
>> I ran the same test here on four different machines with the
>> expected results. These included Solaris on both SPARC and Intel
>> machines, as well as two FreeBSD machin
Mirosalv,
Why didn't you tell me you are using Linux? All bets are off. You are on
your own.
The daemon clamps the adjtime() (sic) offset to 500 PPM, which is
consistent with ordinary Unix semantics. The Unix adjtime() syscall can
return the amount of time not amortized since the lasdt call
On Tue, Nov 02, 2010 at 10:03:30PM +, David L. Mills wrote:
> I ran the same test here on four different machines with the
> expected results. These included Solaris on both SPARC and Intel
> machines, as well as two FreeBSD machines. I tested with and without
> the kernel, with initial offset
Miroslav,
I ran the same test here on four different machines with the expected
results. These included Solaris on both SPARC and Intel machines, as
well as two FreeBSD machines. I tested with and without the kernel, with
initial offset 300 ms (including step correction) and 100 ms. I tested
On Tue, Nov 02, 2010 at 01:29:14PM +, David L. Mills wrote:
> This doesn't make any sense. Your data show the frequency set to 0.0
> and the a series of clock steps after that. If this is with your
> simulator, try it with the real machine. I have tested with three
> machines herewith and witho
Miroslav,
This doesn't make any sense. Your data show the frequency set to 0.0 and
the a series of clock steps after that. If this is with your simulator,
try it with the real machine. I have tested with three machines herewith
and without kernel and with no such problems.
Dave
Miroslav Lic
On Mon, Nov 01, 2010 at 02:29:58PM +, David L. Mills wrote:
> You have something seriously wrong. The frequency was apparently set
> correctly at -168 PPM, then shortly after that there was a series
> of step corrections about 172 ms in 20 min, which is about 170
> PPM. In other words, the f
Mirslav,
You have something seriously wrong. The frequency was apparently set
correctly at -168 PPM, then shortly after that there was a series of
step corrections about 172 ms in 20 min, which is about 170 PPM. In
other words, the frequcny change did not work. It certainly worke here,
ev
On Wed, Oct 27, 2010 at 11:55:22PM +, David L. Mills wrote:
> See the most recent ntp-dev. It needed some tuning.
Hm, with ntp-dev-4.2.7p74 it still doesn't seem to work as expected.
In the same testing conditions as I used the last time, the frequency
estimate is now 170 ppm off and the clock
Miroslav,
See the most recent ntp-dev. It needed some tuning.
Dave
Miroslav Lichvar wrote:
On Mon, Oct 25, 2010 at 05:31:57PM +, David L. Mills wrote:
For record, a hold timer is started when the first update is
received after startup and ends when the residual offset is less
than 0.5
Miroslav,
I uttered an egregious, terrible lie: the hold interval is not 600 s; it
is 300 s, so the maximum time to converge, given a frequency file within
1 PPM, is five minutes; without a frequency file, within ten minutes to
0.5 ms and 1 PPM. Again, I caution that if for some reason the in
On Mon, Oct 25, 2010 at 05:31:57PM +, David L. Mills wrote:
> For record, a hold timer is started when the first update is
> received after startup and ends when the residual offset is less
> than 0.5 ms or after a timeout of 600 s. During the hold interval
> the PLL loop time constant is set v
Miroslav,
No, it not expected, unless you are referring to broadcast mode when
started with +-100 ms initial offset. That has been corrected as per
your bug report.
For record, a hold timer is started when the first update is received
after startup and ends when the residual offset is less t
On Fri, Oct 22, 2010 at 11:39:47AM +0100, David J Taylor wrote:
> Thanks, Dave. I may be missing something here, but it seems to me
> that 4.2.7p58 still takes a number of hours to reach the accuracy
> limits where thermal effects dominate. It's that which matters to
> me, rather than something i
On 2010-10-22, Richard B. Gilbert wrote:
> On 10/22/2010 6:39 AM, David J Taylor wrote:
>> "Dave Hart" wrote in message
>> news:aanlktik1pda81pqmx2jntgv9ays6h7haht3+zelf+...@mail.gmail.com...
>> []
> The solution is obvious: don't shut down! If you are in a situation
> where only 9-5, M-F operat
"Richard B. Gilbert" wrote in message
news:hvgdny984a8wclzrnz2dnuvz_tcdn...@giganews.com...
[]
AFAIK, *all* versions of NTPD require several hours to reach a stable
state and a close approximation to the correct time. NTPD was designed
for operation 24x365. Every time you shut down you will
On 10/22/2010 6:39 AM, David J Taylor wrote:
"Dave Hart" wrote in message
news:aanlktik1pda81pqmx2jntgv9ays6h7haht3+zelf+...@mail.gmail.com...
[]
No new settings required. You might have a hard time picking out the
difference using 5-minute samples of mrtg and the hardcoded Y axis.
Looking at l
"Dave Hart" wrote in message
news:aanlktik1pda81pqmx2jntgv9ays6h7haht3+zelf+...@mail.gmail.com...
[]
No new settings required. You might have a hard time picking out the
difference using 5-minute samples of mrtg and the hardcoded Y axis.
Looking at loopstats graphs, I would expect you to see l
51 matches
Mail list logo
