Stephane lasagni wrote:
Hello,
I tried the NTP autokey protocol (TC scheme at first, then with IFF parameters
- Schnorr algorithm since it is the scheme that is the most documented). I
managed to get both schemes to work ok however I have noticed one problem: my
product is a NTP client and
Stephane lasagni wrote:
Hello,
I apologize in advance if my questions further below seem basic to some of you:
I am very new to NTP and Cybersecurity (a whole new world for me!). I am trying
to work out out NTP autokey works when using the “private certificate” scheme,
I thought you might be
antony,
The NTP timescale described on the NTP Era and Era Numbering page at the
NTP Project site reckonds JDN days and fraction since noon on the first
day of year 4613. The correspondence betwen JDN day and civil year prior
to Pope Gregory's bull is in JDN years of 365.25 days , as is the
Julian,
Thanks for the paper reference. Your ideas on feed-forward are similar
to the ideas in Greg Troxel's MIT dissertation. These ideas were
partially implemented in NTPv3 a very long time ago.
There are some minor misinterptretations in the paper. The NTP
discipline loop is not
Folks,
I thought you might get a kick out of this. See
www.eecis.udel.edu/~mills for ISBN number. Translated from the second
edition, published by CRC Press.
Dave
___
questions mailing list
questions@lists.ntp.org
A C,
Before you take a hacksaw to code, you should see the How NTP Works
collection in the online documentation, in particular the clock select
algorithm page. It includes advice on how to avoid falsetickers in
cases like yours, including the use of tinker and/or tos commands. There
should
Juliusz ,
The fuzzballs indeed used a delay metric. They made little nests at the
earth stations in the SATnet program, as well as the routers used in the
early NSFnet. In its original form, the ARPAnet also used a a node state
metric like the fuzzballs, but switched to a link based metric
unruh,
unhurt,
1. You have a broken interpretation on how the NTP discipline algorithm
works. See the online document How NTP Works, and in particular the
discipline and clock state machine pages.
2. Your
Guys,
Joe sent be a receiver and I have finally verified it works sorta. It
took a couple of weeks before it found WWVB, but it did. I connected it
to deacon for test. When it first came up ntpq reported it as working,
but after a couple of minutes the driver aparently went into a loops and
Danny,
We would not be having this discussion if folks read how NTP works in
the online documentation, in particular, the page on the select
algorithm. The number of candidates is not limited to ten. By default,
ten is the high water mark for survivors mobilized as preemptible in
manycast
Danny,
We would not be having this discussion if folks read how NTP works in
the online documentation. The maximum number of selectable candidates is
not limited to ten. Ten is the high water mark for the number of
preemptable candidates mobilized by the manycast and pool modes.
Dave
Danny
Brian,
See the release notes for the latest distribution in the online
documentation.
There has been a bit of facebook engineering in this discussion. For the
real story, see the How NTP Works pages in the latest online documentation.
Dave
Brian Utterback wrote:
On 08/28/11 06:53,
David,
Something like this was done in NTPv3 (xntpd) and it turned out to be a
bad idea. The poll interval is determined by the time constant, which
for PPS and other low-stratum sources is relatively small. If a backup
is switched in at a poll interval much larger than this, it takes awhile
the preempt phase. For configured associations, this
number is irrelevant.
Dave
Steve Kostecke wrote:
On 2011-07-02, David L. Mills mi...@udel.edu wrote:
The combine algorithm operates on the survivors of the cluster
algorithm, as described on the How NTP Works page. The number of
survivors can
Eugen ,
The remote NIST servers do not use the ACTS driver in the distribution.
They use an algorithm called lockclock that functions as a modem device
driver. I assume the unhealthy indication provided in the ACTS timecode
is translated to the NTP LI indicator via the local clock driver, but
Edward,
The loop time constant varies directly with the poll interval. See How
NTP Works in the current documentation. Note that the default value and
range are purposely optimized for public time servers in order to manage
network overhead and are not appropriate for the most accurate LAN
Joe,
The documentation is rather specific. If you generate a new host or sign
key, the certificates are invalid and should be regenerated. Running
ntp-keygen with now arguments generates a new certificate of the same
type and signature as the existing one.
Dave
Joe Smithian wrote:
Hi
stamping.
Dennis Ferguson
On 5 May 2011, at 04:10 , David L. Mills wrote:
Dennis,
Holy timewarp! Are you the same Dennis Ferguson that wrote much of the original
xntpd code three decades ago? If so, your original leapseconds code has changed
considerably, as documented in the white paper
Dennis,
Holy timewarp! Are you the same Dennis Ferguson that wrote much of the
original xntpd code three decades ago? If so, your original leapseconds
code has changed considerably, as documented in the white paper at
www.eecis.udel.edu/~mills/leap.html. It does not speak POSIX, only UTC.
Edward,
I don't know enough about the mechanism Windows uses to adjust the
system clock. If some variant of the Unix adjtime(), the solution may be
straightforward. The phase-lock loop parameters determine the risetime
and overshoot of the discipline loop, in particular the loop gain and
C.,
It doesn't take ten hours; it takes five/ten minutes. See the online
documentation release notes for recent NTP development versions at
www.ntp.org.
Dave
C BlacK wrote:
Why would it take ntpd ten hours to achieve its accuracy? Can this be
explained in laymans terms and
Chris Co.,
The usual problem is overdriving the computer input.. Most IRIG devices
produce a modulated signal in the range 10 V P-P, which is far larger
than the line-in level. You might need an attenuator to produce in the
order of 1 V P-P. As Chris says, the best way is to monitor the line
:
On Tue, Mar 29, 2011 at 12:53 AM, David L. Mills mi...@udel.edu wrote:
I sent you a message requesting to test this before deployment.
I was referring to docs galore as I thrashed about earlier. I don't doubt
each of your changes was an improvement, but each one also made
reference
to April Fool does not help when assessing your credibility.
Dave
Bruce Lilly wrote:
On Mon, 28 Mar 2011 15:01:13 +, David L. Mills wrote:
You may not be aware that all Spectracom devices are supported with one
driver, all TrueTime devices are supported with one driver, all
wrote:
On Tue, Mar 29, 2011 at 12:53 AM, David L. Mills mi...@udel.edu
mailto:mi...@udel.edu wrote:
I sent you a message requesting to test this before deployment.
I was referring to docs galore as I thrashed about earlier. Â I don't
doubt each of your changes was an improvement, but each
Miroslav,
Unfortunately, while things were in flux, snapshots continued to be
produced, which was counterproductive. I have no direct say in that.
The best advice is:
1. Produce a working version of the configuration without Autokey.
2. Roll keys for all group members using ntp-keygen with
Bruce Co.,
You may not be aware that all Spectracom devices are supported with one
driver, all TrueTime devices are supported with one driver, all
telephone modem services are supported with one driver, all Austron
devices are supported with one driver, all Heath devices are supported
with
Dave,
When all else fails, read the documentation. There were good reasons to
change the configuration in minor ways.
1. There was a huge vulnerability if the identity file was specified by
the server, but the correct file was not specified by the client. The
scheme devolved to TC with no
Yassica,
In principle, NTP Autokey can use certificates generated by OpenSSL or
by other certificate authorities (CA); however, there are some very
minor details with these certificates, including the sequence number and
use of the X.500 extension fields. Ideally, the CA would run the Autokey
Bruce,
I take it your driver will replace or modify an existing driver, right?
Adding a new driver to the current population of over 40 drivers is not
a practical course.
Dave
Bruce Lilly wrote:
I'm preparing a POSIX shared memory driver (PSHM) for ntp to address a
few issues that exist
Rick,
All the Spectracom WWVB and GPS receivers use the same serial protocol;
I have had one or more of these things running for almost 30 years. The
Netclock/2 is useless without its ferrite-stick loop antenna, and even
then the rising noise pollution due to the noisy electrical grid and
Jacek,
An index to the cryptic error comment is in ./include/ntp_crypto.h. It
says bad or missing group key. This message is from the client; you
should see the similar message at the server. Check to be sure you are
using the correct client parameters file.
Recent chjanges to the
Terje,
That's why Autokey uses digital signatures and zero-knowledge identity
proofs.
Dave
Terje Mathisen wrote:
David L. Mills wrote:
Miroslav,
Nowhere in the documentation produced by me is the statement that the
minimum number of servers to reliably find the truechimers is four
MIroslav,
The select algorithm was changed in a very minor way to conform
precisely to the formal assassin quoted in my previous message. It
probably has very little practical significance. After all, the old
algorithm has been going strong for nineteen years.
Dave
Miroslav Lichvar wrote:
Terfe,
Read the formal assertion carefully and examine the algorithm on the
Select Algorithm page. The algorithm would return interval C as the
smallest intersection with the largess number of contributors.
Dave
Terje Mathisen wrote:
David L. Mills wrote:
Miroslav,
Nowhere
Miroslav,
According to your diagram, the algorithm would determine the
intersection interval as interval a. The midpoints of all three
intervals would be considered truechimers, since each of the intervals
a, b and c, contain points in the intersection interval.
Dave
Miroslav Lichvar
Miroslav,
Nowhere in the documentation produced by me is the statement that the
minimum number of servers to reliably find the truechimers is four.
There might have been some confusion in the past, in particular with
reference to Lamport's paper, which describes an algorithm much more
David,
As you might see from the online documentation, much of the tutorial
material has been largely rewritten. Awhile back, some kind soul pointed
out a logical discrepancy in the select algorithm. That was repaired,
the code updated and the documentation refreshed. The pages linked from
or worse than with SNTP..
Dave
David Woolley wrote:
David L. Mills wrote:
BlackList,
I say again with considerable emphasis: this is a Microsoft product,
not the NTPv4 distribution that leaves here. What you see is what you
get,
But it is often NTPv4 reference version that is used
with update intervals of a week will be as bad or worse than with SNTP..
Dave
David Woolley wrote:
David L. Mills wrote:
BlackList,
I say again with considerable emphasis: this is a Microsoft
product, not the NTPv4 distribution that leaves here. What you see
is what you get
David,
I'm confused about your explanation, especially the default
configuration. The definitive explanation of synchronization distance,
in particular your reference more precisely to root distance, is on the
page How NTP Works in the online documentation at ntp.org.
Dave
David Woolley
if the
customer is satisfied with the performance. Just don't compare it with
anything in the NTP distribution, documentation or specification.
Dave
E-Mail Sent to this address will be added to the BlackLists wrote:
David L. Mills wrote:
I had no idea somebody would try to configure
horhe,
I can't speak to the versions used by other repackagers, but the current
ntp-dev version interprets a nonzero broadest delay option as defeating
the calibration volley for all broadcast and multicast clients. This is
why it replaced the novolley option of the broadcast client command.
Harry,
As I said, NTP Autokey is designed to operate outside the NAT perimeter.
In principal, although I don't recommend it, it is possible to use
symmetric key cryptography transparently with a NAT box. The policies on
assignment and distribution of keys depend on the agency. NIST has an
to the internal network via a separate interface.
Dave
Harry wrote:
On Nov 10, 2:59 am, David L. Mills mi...@udel.edu wrote:
Harry,
Autokey is not designed to work behind NAT boxes. The Autokey server and
client must have the same (reversed) IP addresses. The intended model is
using two interfaces, one
Harry,
Autokey is not designed to work behind NAT boxes. The Autokey server and
client must have the same (reversed) IP addresses. The intended model is
using two interfaces, one for the Internet side running Autokey, the
other for the inside net on the other side of the NAT box.
Dave
is about 5 PPM low.
Happy hunting,
Dave Hart
On Sun, Nov 7, 2010 at 00:58 UTC, David L. Mills mi...@udel.edu wrote:
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
presented with new ones. For
that reason if no other, the mission to measure the intrinsic clock
offset with large initial offsets is dead in the water.
The source will be modified to entirely avoid all such initial training.
Dave
Dave Hart wrote:
On Mon, Nov 8, 2010 at 05:14 UTC, David L. Mills mi
. The new code is in the backroom, but not yet a snapshot.
Dave
Dave Hart wrote:
On Sat, Nov 6, 2010 at 03:34 UTC, David L. Mills mi...@udel.edu 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
. They don't belong on the same web site. In any case, a
prospective development user must first obtain the distribution, then
read the release notes to see if it would be useful. At least, the
release notes should be on the web site.
Dave
Steve Kostecke wrote:
On 2010-11-05, David L. Mills mi
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
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
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.
[...]
Ok, I think I have found the problem. The adj_systime
: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 ppm is the standard rate
may have a different view, but the NTP implementation conforms to the
traditional Unix semantics.
Dave
Miroslav Lichvar wrote:
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
unruh wrote:
On 2010-11-04, David L. Mills mi...@udel.edu 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
of 128 ms before the step kicks in. And yes, as reported
several times, I have tested it with and without when the step is
exceeded, but not with Linux.
Dave
ms/5 mini. Dave Hart wrote:
On Thu, Nov 4, 2010 at 22:22 UTC, David L. Mills mi...@udel.edu wrote:
Miroslav,
IT IS NOT S BUG
BlackLists,
The calldelay option is not mentioned in the master copy of the
documentation that resides here. Sometimes there can be considerable
delay for it to be published at ntp.org. Sorry about that, but I have no
control over the publishing process. I am told the relevant
documentation
, 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 300 ms (including step correction)
and 100 ms. I
angst with the Linux semantics.
Dave
David Woolley wrote:
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
,
even with the kernel enabled. You should see the frequency change in the
loopstats. If not, try disabling the kernel to see if that is the problem.
Dave,
Miroslav Lichvar wrote:
On Wed, Oct 27, 2010 at 11:55:22PM +, David L. Mills wrote:
See the most recent ntp-dev. It needed some
Mirslav,
There is a very good reason. First, the kernel can an only be switched
between PLL and FLL mode discreetly, while the daemon has a gradual
transition between modes so that the poll interval can vary seamlessly
between 8 s and 36 hr. Second, the kernel PLL is most useful to minimize
Miroslav,
Depends on the synchronization distance. See the online page How NTP Works.
Dave
Miroslav Lichvar wrote:
I've come across an interesting problem and I'm not sure if this is a
bug or feature.
When two peers are configured to use the same server as their source
and the link between
the initial
frequency file is in error something like 500 PPM, there will be a
considerable additional time to converge.
The model for this scheme is not to fix broken frequency files, but to
quickly converge after a laptop has been off for a few hours.
Dave
David L. Mills wrote:
Miroslav
Jerzy ,
See the online documentation at www.ntp.org. The release notes page has
a link to a tutorial on orphan mode. Note the online documentation
applies to the latest development version; the feature may or may not
appear in the release versioin.
Dave
Miernik, Jerzy (Jerzy) wrote:
John,
My experience with SA some years ago was that the timing accuracy was in
the order of LORAN C, that is, about one microsecond. However, the
oscillator in my Austron 2201 GPS receiver was disciplined in frequency
by LORAN C, with result the timing accuracy was in the order of 50 ns. I
. The intent is to avoid non-intersecting correctness
intervals.
Dave
Dave Hart wrote:
On Thu, Sep 16, 2010 at 1:23 AM, David L. Mills mi...@udel.edu wrote:
Miroslav,
The fastest machine I can find on campus has precision -22, or about 230 ns.
Then, I peeked at time.nist.gov, which
:
On Tue, Sep 14, 2010 at 07:17:04PM +, David L. Mills wrote:
Miroslav,
Better recalibrate your slide rule. On a 2.8 GHz dual-core Pentium
running OpenSolaris 10, the measured precision is -21, which works
out to 470 ns.
That probably just means the system on your machine
in the
distribution.
Dave
Miroslav Lichvar wrote:
On Tue, Sep 14, 2010 at 02:45:01AM +, David L. Mills wrote:
Don't get fooled by the MINSTEP. Precision is defined by the time to
read the system clock at the user interface and I have never seen
anything less than 500 ns for that, more typically 1000
the criteria to
judge performance, ntpdt would look 256 times better than advertised. I
am not here judging whether chrony is better than ntpd or not, just that
the performance measurements be comparable and honest.
Dave
unruh wrote:
On 2010-09-14, David L. Mills mi...@udel.edu wrote
the experiment with trace 3 and NTP
operating at a poll interval of 16 s..
Dave
Miroslav Lichvar wrote:
On Fri, Sep 10, 2010 at 10:10:08PM +, David L. Mills wrote:
A previous message implied that, once the Allan characteristic was
determined, it would show chrony to be better than ntpd
.
Dave
Miroslav Lichvar wrote:
On Fri, Sep 10, 2010 at 08:48:58PM +, David L. Mills wrote:
Miroslav,
I've done this many times with several machines in several places
and reported the results in Chapter 12 and 6 in both the first and
second editions of my book, as well as my 1995 paper
, and it servers no useful
purpose. And, by the way, mail sent to your alleged mail address is
returned to sender as undeliverable.
Dave
unruh wrote:
On 2010-09-11, David L. Mills mi...@udel.edu wrote:
David,
With due respect, your comment has nothing to do with the issue. Allan
deviation is between
:
David L. Mills wrote:
Bill,
Running a precision time server on a busy public machine with a
widely varying load is not a good idea and I have no interest in
that. Running
As indicated by the sort of questions the group is getting recently,
it is becoming the norm to run time servers
I am concerned about and they are the ones the Allan
deviation analysis is intended for. If you want to run NTP in a virtual
machines, the performance will depend on many factors, but none of which
have to do with Allan deviation.
Dave
David Woolley wrote:
David L. Mills wrote:
I beg
Miroslav,
I've done this many times with several machines in several places and
reported the results in Chapter 12 and 6 in both the first and second
editions of my book, as well as my 1995 paper in ACM Trans. Networking.
Judah Levine of NIST has done the same thing and reported in IEEE
Bill,
All my measurements were in temperature-controlled environments, such as
a campus lab or home office, and the data were collected over one week.
The temperature varied less than a degree C. However, I have data from
Poul-Henning Kamp for a similar experiment done in summertime Denmark
David,
I beg to differ. All the machines I used are PCs or similar
workstations. They really and truly behave according to an exponential
distribution with a small mean of a few to a few tens of microseconds. I
have done a tedious histogram from which I can pick out the cache
replacement,
, it's from my book. However, there
are examples in the Precision Time Synchronization briefing slides on
the NTP project page at www.eecis.udel.edu/~mills/ntp.html. be advised,
most of those briefings are from the 1990s.
Dave
unruh wrote:
On 2010-09-10, David L. Mills mi...@udel.edu wrote
how to fix this simple bug. Apparently, I never did get
around to documenting the command other than an orphan reference on the
rate management page. That's in process of fix.
Dave
Dave Hart wrote:
On Wed, Sep 1, 2010 at 03:43 UTC, David L. Mills mi...@udel.edu wrote:
Dave,
The code I
is
contrary to the original intent and documentation.
I didn't check to see if the probabilistic choice to preempt old entries
if the list is full remains. My earlier experience is that this is
important for the busiest servers.
Dave
Dave Hart wrote:
On Wed, Sep 1, 2010 at 00:42 UTC, David L
Jaap,
Please see the Event Messages and Status Codes ant the ntpq pages in the
documentation in your release.
Dave
Jaap Winius wrote:
Hi folks,
A few years ago I started graphing my NTP server's performance. The
machine ran Debian lenny with ntp v4.2.4. However, after recently
upgrading
Ulrich,
The state variable was never intended to be externally visible. It has
changed in many ways for many reasons. The variables designed for
external monitoring are explicitly revealed in the documentation, in
particular the ntpq page and the Event Messages and Status Words page.
Guys,
May I suggest you review the definitions of system offset (THETA), root
distance (LAMBDA) and system jitter (PSI) in Section 11.2 of rfc5905.
Dave
David Woolley wrote:
Miroslav Lichvar wrote:
But there will be more clock updates. Noise in frequency may go up,
but the offset will be
Danny,
KoD packets have the leap bits set to 3 (unsynchronized); the stratum is
not signficant. The reference implementation sets the stratum to 16 for
the RATE kiss code. However, packet stratum 16 is mapped to stratum 0 as
visible to the monitoring function. Codes like INIT and STEP are
Ulrich,
From context I suspect Linux has incorporated the PPS kernel discipline
code I wrote in the 1990s. That code has several provisions to groom
noisy PPS signals, including a median filter, popcorn spike suppressor
and range gate. Apparently, the PPS signal in this case is very noisy
Kostas,
Your symmetric peers have the same upstream system peer, so by rule they
are not going to believe each other unless one of them switches to a
different upstream source. Even if they have differerent upstream
sources, one of them will not beleive the other, since that would create
a
David,
The basic definition of SNTP has not changed over the yeas, although
rfc5905 does clarify the intended scope and role of primary servers,
secondary servers and clients. It was the expected, but not required,
model that the Unix adjtime() system call be used if the offset was less
than
engineering practice. This is
the practice in the systems engineering course I taught over several
years. You are invited to obstruct that practice to your own ends, but
not in the public distribution.
Dave
Miroslav Lichvar wrote:
On Wed, Jun 30, 2010 at 10:00:06PM +, David L. Mills wrote
Miroslav,
Exactly as expected. The overshoot exceeds the design limit of 10
percent by as much as 40 percent. That's exactly what the design is
intended to avoid
Dave
Miroslav Lichvar wrote:
On Wed, Jun 30, 2010 at 10:00:06PM +, David L. Mills wrote:
The change in SHIFT_PLL would
judgment.
Dr. Dave
Rob wrote:
Miroslav Lichvar mlich...@redhat.com wrote:
On Wed, Jun 30, 2010 at 10:00:06PM +, David L. Mills wrote:
Is there somebody around here that understands feedback control
theory? You are doing extreme violence to determine a really simple
thing
wrote:
David L. Mills mi...@udel.edu wrote:
Rob,
With due respect, I don't think you know what you are talking about.
Read it again. I don't question your design, I question your claims
that the code implements the design which are upheld even when the
contrary is shown
Miroslav Lichvar wrote:
On Tue, Jun 29, 2010 at 06:31:01PM +, David L. Mills wrote:
From your description your simulator is designed to do something
else, but what else is not clear from your messages. It might help
to describe an experiment using your simulator and show what results
Bill,
The ntpdsim simulator uses the real system clock, which is modeled as
the Allan variance. However, the server clock is modeled as a
random-walk process computed as the integral of a Gaussian process. The
network is modeled as an exponential distribution, although provisions
have been
David L. Mills wrote:
Bill,
The ntpdsim simulator uses the real system clock, which is modeled as
the Allan variance. However, the server clock is modeled as a
random-walk process computed as the integral of a Gaussian process.
The network is modeled as an exponential distribution, although
to describe
an experiment using your simulator and show what results it produces.
Dave
Miroslav Lichvar wrote:
On Mon, Jun 28, 2010 at 05:35:34PM +, David L. Mills wrote:
How is your simulator different than the one included in the NTP
software distribution?
If I read the code
and the Autokey protocol will be unavailable. This
is most important for NASA/JPL users when converting to and from UTC and
TAI and eventually to TDB for deep space missions.
Dave
Miroslav Lichvar wrote:
On Sat, Jun 26, 2010 at 03:07:33PM +, David L. Mills wrote:
Another case in which
.
Dave
unruh wrote:
On 2010-06-23, David L. Mills mi...@udel.edu wrote:
Pavel,
Linux has many, many times broken the NTP model compatible with other
systems such as Solaris and FreeBSD, among others. I have no trouble
with that as long as whatever modifications are required in NTP to make
Kalle,
Calling settimeofday() is completely transparent to the kernel and ntpd
state variables, including the UNSYNC bit; however, the actions in Linux
might violate this design. Setting the RTC is a byproduct of
settimeofday(), but in general setting the time to the current time is a
no-op,
the NTP.
Dave
Krejci, Pavel wrote:
Hello Dave,
From: David L. Mills [mailto:mi...@udel.edu]
Sent: Wednesday, June 23, 2010 4:42 AM
To: Krejci, Pavel
Cc: questions@lists.ntp.org
Subject: Re
1 - 100 of 362 matches
Mail list logo
