Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
>> Bill,
>
>> You are going about this the wrong way. The discipline has its own
>> chapter in my book, but you might not want to go there. An appendix of
>
> I finally did order your book, but it will take a while to get here.
>
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Unruh,
>The NTPv4 spec is an Internet Draft and can be found in the usual way.
>It can also be found on the NTP project page
>www.eecis.udel.edu/~mills/ntp.html. Look for NTPv4 specification project
>documents.
Thanks
Bill
>Dave
>Unruh wrote:
>
Unruh,
The NTPv4 spec is an Internet Draft and can be found in the usual way.
It can also be found on the NTP project page
www.eecis.udel.edu/~mills/ntp.html. Look for NTPv4 specification project
documents.
Dave
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
>
>>Bill,
>
>
>
>I am willing to believe, barring contrary evidence, that your faithfully
>implimented the protocol. (and that the Linux people faithfully implimented
>the protocol in the kernel discipline routines).
Don't be so quick to believe that things work as expected.
I seem to remember a report of some
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Bill,
>You are going about this the wrong way. The discipline has its own
>chapter in my book, but you might not want to go there. An appendix of
I finally did order your book, but it will take a while to get here.
>rfc 1305 discussed it in a pri
Bill,
You are going about this the wrong way. The discipline has its own
chapter in my book, but you might not want to go there. An appendix of
rfc 1305 discussed it in a primitive way. The Clock Discipline
Principles and Precision Time Synchronization briefings on the NTP
project page are old
David,
In the code you cite the interplay between the deamon frequency and
kernel frequency was fragile and hard to follow. It is now more direct
and easy to follow. It's in the ntp-dev branch as part of the general
cleanup.
I put a good deal of effort into the ornamental commentary, but not a
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Unruh,
>The kernel discipline is almost identical to the daemon discipline with
>the exception that the fancy code to combine the PLL and FLL near the
>Allan intercept is absent. Without the PPS signal, the discipline
>behaves as a second-order loo
Unruh wrote:
>
> And then line 595-597
>ntv.modes |= MOD_FREQUENCY;
> ntv.freq = (int32)((clock_frequency +
> drift_comp) * 65536e6);
This is immediately preceded by:
/*
* The frequency is set directly on
David Woolley <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> David Woolley <[EMAIL PROTECTED]> writes:
>>
>>
>>> If you are using the kernel time discipline, which you should be using
>>> for high accuracy, nptd doesn't discipline the clock; it is the kernel
>>> code that does that, based on mea
Unruh wrote:
> David Woolley <[EMAIL PROTECTED]> writes:
>
>
>> If you are using the kernel time discipline, which you should be using
>> for high accuracy, nptd doesn't discipline the clock; it is the kernel
>> code that does that, based on measurements provided by ntpd.
>
> I do not think th
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Unruh,
>The kernel discipline is almost identical to the daemon discipline with
>the exception that the fancy code to combine the PLL and FLL near the
>Allan intercept is absent. Without the PPS signal, the discipline
>behaves as a second-order loo
Unruh,
The kernel discipline is almost identical to the daemon discipline with
the exception that the fancy code to combine the PLL and FLL near the
Allan intercept is absent. Without the PPS signal, the discipline
behaves as a second-order loop; with the PPS it behaves as two separate
first-o
David Woolley <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> How does ntp actually discipline the local clock? I have a gps received
>If you are using the kernel time discipline, which you should be using
>for high accuracy, nptd doesn't discipline the clock; it is the kernel
>code that does that
Unruh wrote:
> How does ntp actually discipline the local clock? I have a gps received
If you are using the kernel time discipline, which you should be using
for high accuracy, nptd doesn't discipline the clock; it is the kernel
code that does that, based on measurements provided by ntpd.
> att
Steve Kostecke <[EMAIL PROTECTED]> writes:
>On 2008-03-23, Unruh <[EMAIL PROTECTED]> wrote:
>> How does ntp actually discipline the local clock?
>ntpd alters (i.e. increases or decreases) the clock frequency to steer
>the system clock toward the best available estimate of the chosen
>time-base.
On 2008-03-23, Unruh <[EMAIL PROTECTED]> wrote:
> How does ntp actually discipline the local clock?
ntpd alters (i.e. increases or decreases) the clock frequency to steer
the system clock toward the best available estimate of the chosen
time-base.
--
Steve Kostecke <[EMAIL PROTECTED]>
NTP Publi
How does ntp actually discipline the local clock? I have a gps received
attached to a computer which is disciplined by a remote clock over an ADSL
line. (Ie, the gps does not act as a refclock -- it is purely to measure
the actual offset of the system. It is only the remote server that actaully
act
18 matches
Mail list logo
