Danny Mayer wrote:
No, ntpd deliberately limits frequency changes to 500 PPM. That's hard
coded. You need to avoid using anything greater than that as Dave has
explained. That would be the reason why it taks ntpd longer to bring the
clock back to the right time.
Assuming that the static
David Woolley [EMAIL PROTECTED] wrote:
Petri Kaukasoina wrote:
Basically, it stepped time with ntpdate, slept 100 seconds and stepped time
again with ntpdate. From the time adjustment, the script calculated the
drift value and put that to the drift file. Again, the time offset always
stays
Petri Kaukasoina wrote:
David Woolley [EMAIL PROTECTED] wrote:
That has quite a lot of similarity with what ntpd itself does if it is
cold started with iburst. The only big difference is that it uses 900,
Hmm, I can't see that. I put in only one good time source with iburst,
deleted
David,
David Woolley wrote:
ISTR that time stamps on financial transactions are required to be
within two seconds of the correct time. With NTP that standard is not
too difficult to meet.
In 2006, it turns out that it was 3 seconds
http://tf.nist.gov/general/pdf/2125.pdf,
NIST is a US
Jan Ceuleers wrote:
NIST is a US government institution; might there perhaps be different
laws or regulations elsewhere in the world? Does anyone among the
readership here know?
I used the US case as that is the one that has come up on the newsgroup,
but I assume there are similar rules
Richard B. Gilbert wrote:
Computer Network Time Synchronization: The Network Time Protocol by
David L. Mills (Hardcover - Mar 24, 2006)
Available from Amazon.com. You may be able to find a copy at a
University Book store. Be prepared for Sticker Shock. It ain't
cheap! Publishing in
Jason Rabel wrote:
Richard B. Gilbert wrote:
Computer Network Time Synchronization: The Network Time Protocol by
David L. Mills (Hardcover - Mar 24, 2006)
Available from Amazon.com. You may be able to find a copy at a
University Book store. Be prepared for Sticker Shock. It ain't
cheap!
Hello,
i would like to ask you for help or ideas with one ntp related task.
I need to setup one ntp server to serve its sntp clients
with time, which is specific amount of time (several seconds) in
advance against correct real time taken from another ntp server in
network. I did some search in
[EMAIL PROTECTED] wrote:
Hello,
i would like to ask you for help or ideas with one ntp related task.
I need to setup one ntp server to serve its sntp clients
with time, which is specific amount of time (several seconds) in
advance against correct real time taken from another ntp server in
Richard,
There were several different architecture computers considered in the
1995 and 1998 studies, incluing SPARC, Alpha, Intel and several lab
instruments. All oscillators conformed to a simple model: white phase
noise (slope -1) below the intercept, random-walk frequency noise (slope
On 26 Led, 19:03, Dennis Hilberg, Jr.
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Hello,
i would like to ask you for help or ideas with one ntp related task.
I need to setup one ntp server to serve its sntp clients
with time, which is specific amount of time (several seconds) in
David L. Mills wrote:
Richard,
There were several different architecture computers considered in the
1995 and 1998 studies, incluing SPARC, Alpha, Intel and several lab
instruments. All oscillators conformed to a simple model: white phase
noise (slope -1) below the intercept, random-walk
Danny,
Unless the computer clock intrinsic frequency error is huge, the only
time the 500-PPM kicks in is with a 100-ms step transient and poll
interval 16 s. The loop still works if it hits the stops; it just can't
drive the offset to zero.
Dave
Danny Mayer wrote:
Unruh wrote:
David L.
Petru,
The default 900-s stepout interval was originally determined by the time
an old Spectracom WWVB receiver took to regain synchronization after a
leapsecond and should probably be reduced. It can of course be tinkere.
During the initial training period the time is not disciplined other
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
Reading your claims literally, chrony would have to slew the clock
considerably greater than the 500 PPM provided by the standard Unix
adjtime() system call. Please explain how it does that.
David J Taylor [EMAIL PROTECTED] writes:
Richard B. Gilbert wrote:
[]
Computer Network Time Synchronization: The Network Time Protocol by
David L. Mills (Hardcover - Mar 24, 2006)
Available from Amazon.com. You may be able to find a copy at a
University Book store. Be prepared for Sticker
David,
I don't know your version, but the TSET state was removed some time ago
and your comments are different from the current source. It's really
hard to test the discipline under all conceivable conditions. Now and
then somebody cooks up a case considered very unlikely, like Solaris
David Woolley [EMAIL PROTECTED] writes:
What I was expecting was for it to unconditionally do both frequency and
phase calibration, in the absence of the drift file. I presume that
chrony does a correction on the first couple of samples and then refines it.
Yes. Actually it does a
Richard B. Gilbert [EMAIL PROTECTED] writes:
David,
Why are you telling me this? My contribution to this thread consisted
of the above exposition of the publication data and availability of Das
Buch.
He is not good at following attributions in threads. He addressed it to you
because he read
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
Brian Utterback [EMAIL PROTECTED] writes:
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
You might not have noticed a couple of crucial issues in the clock
filter code.
I did notice them all. Thus my caveate. However throwing
20 matches
Mail list logo
