Jan,
A timer interrupt is required each second to update the clock frequency
no matter what. In addition, a sweep is made through the associations to
see if a poll is pending. It would be in principle posssible to
implement a system of queues to avopid sweeping the associations each
second,
think the transceiver clocks and onboard rover clocks are
anywhere near that caliber.
Dave
Evandro Menezes wrote:
On May 4, 2:37 pm, David L. Mills [EMAIL PROTECTED] wrote:
On symmetry, etc. There are both gravitational and velocity corrections
relative to both Earth and solar system barycentric
Bill,
You seem to have a tack up your tail about the clock filter algorithm.
First, you didn't respond to my message about sampling at twice the
Nyquist rate, even if a burst of seven samples is lost.
Second, look at the clock filter algorithm code and comments. Samples
older than the Allan
.
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
Gene,
I've seen and reviewed the paper; however, reviews are private to the
Their paper is public. It is posted on the web.
authors. Someone else should take a close look at what they are actually
measuring and assess
Uwe,
A Costas receiver does what I think the 5120 does. You can buy one,
called a software defined rario, for less than $1000. It consists of two
double-balanced mixers converting to baseband. The I and Q signals are
sent to a 24-bit sound card and ordinary PC. The rest is done by a DSP
David and others,
The adaptive poll algorithm evolved over many years and many variations.
A summary follows.
1. The poll will not be less than the maximum of the peer poll and
minpoll. The maximum poll will not be greater than maxpoll. This is to
protect the network.
2. The time constant
David,
There is need to dispell urban legends here. First, the only reference
clock driver that uses anything other than minpoll is the ACTS driver.
All others do not increase the poll interval under any circumstances.
Second, there is no failover at all. The design is that more than one
Woolley wrote:
David L. Mills wrote:
There is need to dispell urban legends here. First, the only reference
clock driver that uses anything other than minpoll is the ACTS driver.
You introduced the possibility that there were exceptions, yourself,
earlier in the thread; I was just
Jason,
Of the timecode formats specified in the 9037 support document, only the
Spectracom format is available in products currently manufactured. See
http://www.eecis.udel.edu/~mills/database/brief/bof/ibm.pdf. One of my
consulting clients is searching for a way to synchronize a 9037 to an
Serge,
Wow, I hadn't foreseen manycast orphans. The problem is that manycast
servers are carefully taught not to respond if the stratum of the client
is the same or lower than the server. The cohort option allows
manycasting between servers of the same stratum. For instance,
tos orphan 5
Richard,
It's a little more complicated than that. If the server is unreachable
when a poll is scheduled, a single poll is sent. If no reply is heard,
the cleint tries again in 64 s and repeats for a total of three times
and returns to the original poll interval. If not heard after that, it
the temperature ranges
from 0 to 50 below C and when things get shut down in a duststorm.
Dave
Danny Mayer wrote:
Unruh wrote:
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
Brian,
The longest delay NTP response was from the Moon, as simulated at JPL
Hal,
You should see the current web documentation on rate control and the KoD
packet. Rate control is on a per-client baiss, so if 10,000 clients all
light up at the same time, each will be treated individually. KoD
packets are themselves rate controlled, so the effect might be to drop
Ryan,
The iburst option is by serious intent not the default becaase serveral
thousand ibursters ganging up on one or another NIST and/or USNO public
servers would not be considered polite.
Dave
Ryan Malayter wrote:
On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke [EMAIL PROTECTED] wrote:
Ulrich,
The current (development) code has a new statistics file, called
protostats, that records significant events, like system peer changes,
mobilization/demobilization and error events. Among the events is a
spike detected event, which indicates that an offset arrived greater
than the
let you know.
Dave
Brian Utterback wrote:
David L. Mills wrote:
Suspecting such could be the case between NTP servers and clients, I
designed an experiment to detect such things and found small but
significant LRD effects with lags up to TWO WEEKS! At short lags up to
several network
: Friday, May 02, 2008 7:38 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] frequency adjusting only
David L. Mills wrote:
Suspecting such could be the case between NTP servers and
clients, I
designed an experiment to detect such things and found small but
significant LRD effects
a particular feature, it is not available
in that version.
Dave
David Woolley wrote:
David Woolley wrote:
David L. Mills wrote:
See the documention on the true option of the server command. Compare
with the prefer and noselect options.
Where is it documented in 4.2.4p4
Hal,
telnet ntp.alaska.edu daytime. Other busy NIST servers don't do
TCP/TIME anymore, but others might.
Dave
DaveHal Murray wrote:
I would like to connect to any server to receive a string where it is
written the istant time (possibly hh.mm.ss.xxx ). I found several sites
where I may read
Bill,
As a physicist you know about the sampling theorem and Nyquist rate. The
feedbacl loop bandwith and poll interval have been carefully chosen so
that, even using only one of eight samples, the net sampling rate is
twice the Nyquist rate. Oversampling doesn't improve the timekeeping
Greg,
Let me correct a couple of minor misconceptions. The clock filter, which
I call a minimum filter, selects from the last eight samples the one
with minimum delay. Since the reference clock delay is always zero, the
algorithm selects the most recent sample and the filter is effectively
Bill,
Hey, somebody mentioned LRD (long-range dependency aka heavy-tail),
which is the tendency for infrequenct events to take unexpectedly long
times. I first noticed this in the ARPAnet, which showed occasional
delays up to thirty seconds. I could not account for where in the
network a
David,
See the documention on the true option of the server command. Compare
with the prefer and noselect options.
Dave
David Woolley wrote:
Danny Mayer wrote:
It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2
As far as I can see, the intersection algorithm
David,
The original model implemented in the Alpha kernel does not step the
clock backward unless the step is greater than two seconds. Rather, it
stops the clock and advances one microsecond at each read. This applies
whether NTP slews or steps. Various ports of that code have broken this
Guys,
I was afraid this might happen. There is no such port check in the
development branch, so somebody broke my rules not to change ntp_proto.c
withhout my permission. The result not only breaks the specification, it
disables symmetric active/active modes. Any check like this has to be
mode
not in spec, and that port check has been illegal since 1992.
The current NTPv4 ntent is that source port 123 is required only for
symmetric modes. Previously it was required for all modes.
Dave
Ronan Flood wrote:
David L. Mills [EMAIL PROTECTED] wrote:
I was afraid this might happen
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,
You
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
computes that
function. I claim it does and confirm by empirical verification of the
impulse response as reported previously, both for the kernel and for the
daemon. For the same time constant they both have the same response.
Dave
Bill Unruh wrote:
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 loop; with the PPS it behaves as two separate
,
On Monday, February 11, 2008 at 19:03:36 +, David L. Mills wrote:
While not admitted in public, the latest snapshot can set the poll
interval to 3 (8 s), so the risetime is 250 s. This works just fine on
a LAN, but I would never do this on an outside circuit.
Setting ntp-dev 4.2.5p113
Evandro,
Remember, enable/disable auth has nothing to do with authentication
itself, just whether new associations can be mobilized if no
authentication is used. In your case a symmetric passive association was
apparently mobilized and began sending mode-2 packets just as if a
legitimate peer
Martin,
Maybe so, but when I tried both XP and Vista before the change I
mentioned, both timed out and did not work.
Dave
Martin Burnicki wrote:
Ryan,
Ryan Malayter wrote:
Okay, I just did some packet captures. It appears that Vista, when
configured *only* with a time server host name or
Maartin and others,
The intended model for monitoring and control is clearly articulated in
the control and monitoring protocol defined in rfc 1305. This model
provides status words and event codes explicitly designed for remote
access and as a demarcation between the idiosyncratic inner
Harlan,
What you see from me is what you get. How you incorporate it in whatever
archive you maintain is at your convenience.
Dave
Harlan Stenn wrote:
In article [EMAIL PROTECTED], David L. Mills [EMAIL PROTECTED] writes:
David While I don't maintain the changelog, it would seem a simple
.
You may notice in the fog of war that Autokey names potentially can
replace the IP addresses. Need to work on that...
Dave
Danny Mayer wrote:
David L. Mills wrote:
Danny,
The specific accusation directed to me personally was about the notrust
bit, which change I described in my previous
Folks,
I just poked around and discovered something interesting that affects
Windows clients, both XP and Vista.
Microsoft has broken the NTP specification in that the client sends a
request in symmetric active mode instead of client mode. According to
the NTP spec, both ancient and modern,
David,
I would be happy to make the documentation harder to find. I don't
maintain the home page, but wordsmithing about four words would remove
any ambiguity and clearly state that the documentation for each version
is contained in that version. In any case, what documentation that comes
Ryan,
If you are using the NTP web documentation, you should read the home
page where it states the relationship between the web documentation and
the development branch on one hand and previous versions on the other.
As always, please use the documentation that comes with your particular
Martin,
1. The pool command has been present for, in the scheme of things, for
some time, certainly before the latest release in September, 2007. If
so, why are we having this discussion?
2. To what are you referring to about inverted restrict bits? I've heard
this urban legend before from
Brian,
How true. But, are you ready for this? The minimum average headway
constraint, introduced to protect very busy servers, must be at least 16
s by default, but allow for a temporaty 8-packet burst. So, if somebody
configures a symmetric active association with iburst and autokey and
Ryan,
NOt so much jealously guarded, but of necessity. My eyesight has
seriously degraded and I need special editors and tools. I have serious
difficulty dealing with the eye-unfriendly Bugzilla contraption and even
our own University pages. The NTP web guys have done a wonderful job
of
it
as a vanilla configuration file command. This of course requires
authentication as in ntpdc.
As I said, the implementation is incomplete and very likely additional
commands will be useful in future. Your comments are invited.
Dave
Dennis Hilberg, Jr. wrote:
David L. Mills wrote:
Dennis
Dennis,
The ntpdc program has not been actively maintained for some time. The
principal problem is that the ntpdc remote configuration commands are
incompatible with the pool and manycast schemes.
The ntpq program can now generate configuration file commands, but the
command set is
] wrote:
On Feb 22, 12:26 pm, David L. Mills [EMAIL PROTECTED] wrote:
My reference for leap second introduction was CCIR Recommendation 517,
which permits leaps only June/December.
For reference, that is now known as ITU-R RA.517, available for
purchase at
http://www.itu.int/rec/R-REC-RA
with battery case. I have its logbook.
Dave
[EMAIL PROTECTED] wrote:
On Feb 22, 10:51 am, David L. Mills [EMAIL PROTECTED] wrote:
Before 1972 there were no leap secconds; however there were periodic
introductions of tiny rate adjustments relative to Ephemeris Time (ET)
that drove everybody nuts
Bill,
Before 1972 there were no leap secconds; however there were periodic
introductions of tiny rate adjustments relative to Ephemeris Time (ET)
that drove everybody nuts. There never has been and most likely never
will be leap deletions. In any case the timecode generators at WWVB and
WWV
Danny,
A little history here. A few years ago industry lobbyists persuaded the
State Depatment to propose abolishing leap seconds to the ITU-T (nee
CCITT) without a public discussion first. The astronomers and
timekeepers around the world are still seething about what they perceive
as
Danny,
That snapshot is older than I thought. That particular botch of code
along with other botches was vulnerable to whimsical errors, like server
leap bits popping up and down or leapsecond file update. The current
code here can leap at the end of any month, which seems to be the
Maarten Wiltink wrote:
David L. Mills [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
No, there is no random delay at startup. Each association starts one
second after the previous one. The random backoff occurs only after
a step.
Is there also a random backoff after an increase
Maarten,
No. However, there is a small dither of a few percent at all poll
intervals to resist self-synchronization.
Dave
Maarten Wiltink wrote:
David L. Mills [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
No, there is no random delay at startup. Each association starts one
be more worried about a broacast server coming up with 2000 corporate
broadcast clients, but in that case the initial client response is
randomized over the poll interval.
Dave
Unruh wrote:
Martin Burnicki [EMAIL PROTECTED] writes:
Dave,
David L. Mills wrote:
Serge,
The behavior after
that, but folks have their biases.
Dave
Serge Bets wrote:
Hello David,
On Tuesday, February 12, 2008 at 2:43:06 +, David L. Mills wrote:
Just for clarity, neither the daemon nor kernel frequency is adjusted
in any way with ntpd -q.
ntpd -q can make use of the driftfile to set
the
reference implementation, as the rate violation will result in a dropped
packet and, if configured, a KoD.
Dave
Martin Burnicki wrote:
Dave,
David L. Mills wrote:
Serge,
The behavior after a step is deliberate. The iburst volley after a step
is delayed a random fraction of the poll
Serge,
I didn't believe what you said until I checked the code and it does
increase the correction by 50%, but limits the overshoot to 50 ms. Why
in the would it overshoot at all?
Dave
Serge Bets wrote:
Hello David,
On Monday, February 11, 2008 at 19:03:36 +, David L. Mills wrote
Dag-Erling,
Correct. That was the plan for my latest Intel motherboard. Problem is,
Intel wired the motherboard header backwards. My SIIG serial port card
comes up COM5, COM6,..., but my favorite old program requires COM1 or COM2.
Dave
Dag-Erling Smørgrav wrote:
[EMAIL PROTECTED] (Chris
Guys,
Just for clarity, neither the daemon nor kernel frequency is adjusted in
any way with ntpd -q.
Serge Bets wrote:
On Monday, February 11, 2008 at 7:38:53 +, David Woolley wrote:
Serge Bets wrote:
the kind of slew (singleshot) initiated by ntpd -q comes *above* the
usual
under discussion.
The one that's used nearly universally in boot sequences.
-Tom
David L. Mills wrote:
Guys,
There seems to some misinformation here.
Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
After that, stock Unix adjtime() slews the clock at rate 500 PPM
Guys,
There seems to some misinformation here.
Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
After that, stock Unix adjtime() slews the clock at rate 500 PPM, which
indeed could take 256 s for an initial offset of 128 ms. A prudent
response would be to measure the
page to external sites and in addition internal links to the NTP
and SNTP distributions along with a statement that both are strictly
specification conformant. That might inspire other wannabees to make and
enforce similar claims.
Dave
Harlan Stenn wrote:
In article [EMAIL PROTECTED], David L
[EMAIL PROTECTED],
I have no plans to provide UML, but would welcome a volunteer to do
that. You are invited to view the internet draft NTPv4 protocol
specification now at the IETF and on the NTP project page linked from
www.ntp.org. If you want to make a political statement about UML or OSI,
Harlan,
Historically, rfc 1305 is/was an Internet Draft Standard. It was never
advanced to Internet Standard because it is in PostScript, like the
previous version, and I refused to rewrite it in Postel ASCII. Thanks to
the hard working guys in the NTP Working Group, the NTPv4 spec is in XML
Unruh,
My message to David probably is most relevant.
Dave
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
Unrug,
You are not accurately describing the ntpd clock filter. An accurate
desciption would surely help the point you are making.
You are undoubtedly correct. I
David,
The rub is when a new sample comes along when an older sample with lower
delay is in the filter. This can and often does persist until the
minimum sample is ejected from the filter by a newer sample and the
minimum sample is redetermined. So, the minimum sample, and thus the
maximum
Bill,
Not quite. There must always be a selection in every run of eight
samples, so there can be no more than seven unselected samples in a row.
To gain more insight, run ntpd with -d to produce a trace. Note in the
clock_filter trace the age value, which is the interval from the last
Unrug,
You are not accurately describing the ntpd clock filter. An accurate
desciption would surely help the point you are making.
Davde
Unruh wrote:
Grian Utterback [EMAIL PROTECTED] writes:
David J Taylor wrote:
Brian Utterback wrote:
[]
Which is why NTP prefers the source with the
David,
We are talking right past each other and are not having a productive
discussion. Tge best choice for me is just to shut up.
Dave
David Woolley wrote:
David L. Mills wrote:
Guys,
This is really silly. The Unruh agenda is clear. Should you choose to
I think you replied
specification.
Dave
David Woolley wrote:
David L. Mills wrote:
The result of the sort is usually the first entry on the list, but even
I thought this only gave the figure head peer, but that the actual clock
disciplining used a weighted average of some number of candidates aa well
Dag-Erling,
The monitor and rate semantics are further elaborated in the recent
documentation posted to the web page.
Dave
Dag-Erling Smørgrav wrote:
David L. Mills [EMAIL PROTECTED] writes:
The rate violation is caught in the MRU list, which can be retrieved
using ntpdc and the monlist
a
total ove about 1000 packets per hour dropped due rate exceeded of about
3 received packets per hour.
If you set up a test locally, include the
restrict default limited kod
line in the configuration file.
Dave
Dag-Erling Smørgrav wrote:
David L. Mills [EMAIL PROTECTED] writes:
Yes
2, a KoD is sent; otherwise, the packet is dropped
without further action. There probably should be some triage, but not
without additional complexity.
Dave
Dag-Erling Smørgrav wrote:
David L. Mills [EMAIL PROTECTED] writes:
These configurable features are in the current snapshot, so
David,
Cite: Judah Levine of NIST, personal communication. A few little
mistakes on my part proved him right.
Dave
[EMAIL PROTECTED] wrote:
In comp.protocols.time.ntp you write:
Hi Dave,
We can argue about the Hurst parameter, which can't be truly random-walk
as I have assumed, but the
David,
We can argue about the Hurst parameter, which can't be truly random-walk
as I have assumed, but the approximation is valid up to lag times of at
least a week. However, as I have been cautioned, these plots are really
sensitive to spectral lines due to nonuniform sampling. I was very
.
This has nothing to do with the initial offset as you suggest.
Dave
Maarten Wiltink wrote:
Unruh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
David L. Mills wrote:
Unless the computer clock intrinsic frequency error is huge, the
only time the 500-PPM kicks in is with a 100-ms
that.
Dave
Eric wrote:
On Mon, 28 Jan 2008 19:19:12 +, David L. Mills [EMAIL PROTECTED] wrote
for the entire planet to see:
Eric,
Many years ago the Proteon routers dropped the first packet after the
cache timed out; that was a disaster. That case and the ones you
describe are exactly what
Unruh,
It would seem self evident from the equations that minimizing the delay
variance truly does minimize the offset variance. Further evidence of
that is in the raw versus filtered offset graphs in the architecture
briefings. If nothing else, the filter reduces the variance by some 10
dB.
benefit.
ICMP pings will not work to our campus machines from outside. ICMP
request messages are dropped by the ingress router.
Dave
Steve Kostecke wrote:
On 2008-01-28, David L. Mills [EMAIL PROTECTED] wrote:
Eric wrote:
[---=| TOFU protection by t-prot: 72 lines snipped
, David L. Mills [EMAIL PROTECTED] wrote
for the entire planet to see:
snip
However, you give me an idea. Why not shut down the burst when the clock
filter delivers the first sample? Gotta think about that.
Dave
Hi Dave -
I'm pleased to know I've provoked some new thoughts. If I
Steve,
The best place to check the data is in the ntp_util.c file,
record_sys_stats() routine. I recently added another stat, but you might
not be using the most recent version.
The time since startup is in hours. The packets received are the total
number of packets received. The server
Hal,
Not any more. Current NTPv4 sends the burst at 2-s intervals, mainly to
coordinate with Autokey opportunities and reduce the total number of
packets.
Dave
Hal Murray wrote:
I'll probably quite easily display my profound NTP ignorance here :)
But if there is assymetric delay stemming
will also recognize the need for
zeal in avoiding undersampling, which is why the poll-adjust algorithm
is so squirrely.
Dave
Danny Mayer wrote:
Unruh wrote:
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
Brian Utterback [EMAIL PROTECTED] writes:
Unruh wrote:
David L. Mills [EMAIL
('Allan Deviation (PPM)');
print -dtiff allan
Dave
Richard B. Gilbert wrote:
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
David,
1. I have explained in very gory detail in many places how the time
constant is chosen for the best accuracy using typical computer
oscillators
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
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
Root,
Right; 5 microseconds per timer interrupt at 100 Hz is 0.5 ms/s. That
was the original Unix kernel value.
Dave
root wrote:
David L. Mills [EMAIL PROTECTED] writes:
snip
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org
Root,
You could have saved a lot of time sweating the code if you looked at
the briefings. See especially the before and after time series and note
the 10 dB improvement in S/N.
You might not have noticed a couple of crucial issues in the clock
filter code.
1. The basic principle is to
ms which I interpret as 100 milliseconds. Even 25
year old fuzzballs could to much better than that on the congested
ARPAnet. Did you mean 100 microseconds?
Dave
David Woolley wrote:
David L. Mills wrote:
5. This flap about the speed of convergence has become silly. Most of
us are less
Brian,
The 500 PPM limit in the reference implementation was originally set to
match the adjtime() slew of that value, but so many kernels have been
hacked adjtime that this might not even be appropriate now. The bottom
line is that an update given to adjtime() should be completed before the
for LANs and WANs. You are invited to justify a
different time constant, but it has to work an a bumpy road to Malaysia.
Further discussion on this issue is neither interesting nor helpful and,
frankly, boring.
Dave
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
Maarten,
I turn
Danny,
Your comment on another thread about weather modelling stirred my pot. I
gave a long thought about modelling when designing the synthetic sources
for the ntpd simulator. With the Allan characteristic in mind the
synthetic sources use exponentially distributed phase noise plus
Guys,
Sure, I'm stubborn as a bull. The laws of physics make me so.
I am dismissing any comparisons between ntpd and crony or any other
vehicle unless the comparison includes substantially all the scenarios
that ntpd is designed to work with. The protocol is specifically
designed to work over
Guys,
Reprinted without permission from the draft spec:
14. Simple Network Time Protocol (SNTP)
Primary servers and clients complying with a subset of NTP, called
the Simple Network Time Protocol (SNTPv4) [2], do not need to
implement the mitigation algorithms described in Section
that it might take 3000 s to amortize the initial
offset from the TOC chip at power-up. This is no different than if some
server torqued your clock by that amount.
Dave
Maarten Wiltink wrote:
Unruh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
David L. Mills [EMAIL PROTECTED] writes
Unruh,
It may help to review the material on Allan deviation and noise
modelling in the briefings on the NTP project page. If you are down in
the low microsecond range with poll intervals much over 64 s, expect to
see a frequency sway due to small temperature variations less than one
degree
Guys,
I haven't read every word on this thread, but all I can contribute is
that nothing reported here is anything like my experience here. Our
servers pogo.udel.edu and rackety.udel.edu are synchronized via GPS and
PPS. I invite the skeptics to peek at them from time to time. I describe
Unruh,
Please read the specification. The offset statistic is the
maximum-likelihood estimate of the remote clock offset relative to the
local clock and the sign really does matter. The best way to describe
this and keep the sign straight is to assume the signed offset is the
quantity in
Unruh,
The basic clock discipline feedback loop has been unchanged since 1992,
although minor changes have been made to improve behavior in very long
poll intervals. The only radical change has been using a preliminary
15-minute initial frequency computation when no frequency file is
Unruh,
As you can see from the Allan deviation plots in the briefings on the
NTP project page, it does no good whatsoever to average over ten hours;
the observations are completely uncorrelated over that lag. The Allan
intercept, or best averaging time, is more like twenty minutes to two
Petri,
I knew Linux was broken, but what you report suggests it is broken
beyond my wildest imagination. First, I do know Linux supports the
precision time kernel, as it has the ntp_adjtime() system call, even if
it is buried in a wrapper. If so, and assuming that syscall is
implemented
201 - 300 of 362 matches
Mail list logo
