pc wrote:
At risk of stirring up a hornets' nest:
The RFC unequivocally states that "A primary server is
synchronized to a reference clock directly traceable to
UTC."
IMO, that is not a necessary condition. If I have a
hierarchy of NTP servers and clients with no external
connection to the Inte
On 2010-06-24, pc wrote:
> Many users of this list have a requirement to synchronize a number of
> machines within some user-defined limit, but they don't care if they
> are all offset from UTC by a few minutes.
The problem is that most time island operators appear to make the
unstated assumptio
David,
"...pretending to be a mathematical treatise..." Let's take a closer
look at that judgment. The RFC is based on a document I wrote five years
ago. That document was carefully typeset with equations, figures and
tables for precise engineering description. The IETF required a
text-only docum
Wolfgang,
I used this program extensively some years ago, but not with the new
syntax. I am told it enables many new features, but I have not verified
that. You might be able to drop back to the old syntax The old syntax
allowed only a single server and client, but the new syntax should
support m
Hi--
On Jun 24, 2010, at 6:45 AM, pc wrote:
> The RFC unequivocally states that "A primary server is synchronized to a
> reference clock directly traceable to UTC."
>
> IMO, that is not a necessary condition. If I have a hierarchy of NTP servers
> and clients with no external connection to the
pc,
You completely miss the point. By definition a primary server is
synchronized to UTC via an external source such as a GPS receiver. By
definition, it operates at stratum 1. It is indeed possible to operate a
server with some other reference source, even itself (orphan mode or
local clock
[ escape4glob $patt1 ]David L. Mills wrote:
Pavel,
Linux has many,
do we actually know anything about per platform usage ?
My guess is that Linux boxes these days comprise the majority of ntpd users.
uwe
___
questions mailing list
question
At risk of stirring up a hornets' nest:
The RFC unequivocally states that "A primary server is
synchronized to a reference clock directly traceable to
UTC."
IMO, that is not a necessary condition. If I have a
hierarchy of NTP servers and clients with no external
connection to the Internet and I f
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: [ntp:questions] Reference clock driver for /dev/rtc
Pavel,
It's not as simple as that. Normally, ntpd uses s
Pavel,
It's not as simple as that. Normally, ntpd uses settimeofday() once per
hour to set the system clock, which has the side effect of setting the
RTC. Obviously, you don't want that. If the RTC refclock is enabled,
that has to be disabled, so some kind of interlock must be devised. This
c
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
the RTC driver work remain proprietary to Linux and never leak to other
sys
On 2010-06-24, geep wrote:
> I can see an error message relating to your 2 DNS servers:
>
> no answer from ns2.ntp.org (149.20.54.239)
> no answer from ns1.ntp.org (149.20.54.238)
We do not have name servers at those addresses.
> via: http://www.robtex.com/dns/ntp.org.html#analysis
Thank-yo
geep wrote:
On Wed, 23 Jun 2010 20:14:40 +, Steve Kostecke wrote:
All of our systems are up. We are currently experiencing some DNS
"issues" and are attempting to resolve them.
We apologize for any inconvenience this may be causing.
Steve - thanks for the info.
I can see an error message
On Wed, 23 Jun 2010 20:14:40 +, Steve Kostecke wrote:
>
> All of our systems are up. We are currently experiencing some DNS
> "issues" and are attempting to resolve them.
>
> We apologize for any inconvenience this may be causing.
Steve - thanks for the info.
I can see an error message relat
14 matches
Mail list logo
