Windows - Seven Days Later
Jerry Baker
remaining stable. I now have a little more than a weeks worth of data
graphed with MRTG available. Perhaps I am expecting too much from NTP,
but it looks to me like there is something critically wrong with NTP's
operation on the Windows platform (SNTP clients with no stepping keep
better time).
Take a look at http://jerbaker.dhs.org/ntp/
W. D.
Hey Jerry,
I am willing to take your word that you are having problems.
I just got a box working running NTP. It is keeping time
extremely accurately. I am running FreeBSD on an older
computer. It's possible to get microsecond accuracy on an
old 486, if you have a GPS antenna. The operating
system is important. I recommend FreeBSD.
I am putting together a How To to install NTP on FreeBSD.
It will be ready in a day or so. Let me know if you are
interested.
So, I recommend you grab an old 486, load it with FreeBSD
(http://www.US-Webmasters.com/FreeBSD/Install/) and install
NTP.
Start Here to Find It Fast!™ -> http://www.US-Webmasters.com/best-start-page/
$8.77 Domain Names -> http://domains.us-webmasters.com/
Jerry Baker
> At 15:30 10/7/2004, Jerry Baker, wrote:
>>I have made several postings about how NTP is having a real problem
>>remaining stable. I now have a little more than a weeks worth of data
>>graphed with MRTG available. Perhaps I am expecting too much from NTP,
>>but it looks to me like there is something critically wrong with NTP's
>>operation on the Windows platform (SNTP clients with no stepping keep
>>better time).
>>
>>Take a look at http://jerbaker.dhs.org/ntp/
>
> Hey Jerry,
>
> I am willing to take your word that you are having problems.
>
> I just got a box working running NTP. It is keeping time
> extremely accurately. I am running FreeBSD on an older
> computer. It's possible to get microsecond accuracy on an
> old 486, if you have a GPS antenna. The operating
> system is important. I recommend FreeBSD.
>
> I am putting together a How To to install NTP on FreeBSD.
> It will be ready in a day or so. Let me know if you are
> interested.
>
> So, I recommend you grab an old 486, load it with FreeBSD
> (http://www.US-Webmasters.com/FreeBSD/Install/) and install
> NTP.
I would really prefer to just fix whatever it is that is broken in NTP.
I am more interested in tracking down this issue than I am in the
accuracy of the time itself. There is obviously something haywire with
NTP on Windows, and I would like to get to the bottom of it. I do not
have the expertise on my own though, which is why I am posting here. My
suspicion now is that there is something about thread scheduling on
Windows that does not work quite the way someone expected when they
ported the code. NTP appears to be *extremely* sensitive to CPU usage
(even just editing and saving text files).
Jerry Baker
> I would really prefer to just fix whatever it is that is broken in NTP.
> I am more interested in tracking down this issue than I am in the
> accuracy of the time itself. There is obviously something haywire with
> NTP on Windows, and I would like to get to the bottom of it. I do not
> have the expertise on my own though, which is why I am posting here. My
> suspicion now is that there is something about thread scheduling on
> Windows that does not work quite the way someone expected when they
> ported the code. NTP appears to be *extremely* sensitive to CPU usage
> (even just editing and saving text files).
Another suspicion I have is that NTP is sensitive to network I/O on
Windows. There are some large fluctuations with NTP that coincide with
nothing other than network activity - and nothing more than 5% or so of
capacity.
I will be away from home starting this evening until Monday. There
should be no network activity other than that initiated by someone
accessing my Web server, or NTP itself. It should be interesting to see
what NTP does on a machine that is not being used at all.
Harlan Stenn
your OS and there is nothing ntpd can do about that.
H
Brad Knowles
> I am putting together a How To to install NTP on FreeBSD.
> It will be ready in a day or so. Let me know if you are
> interested.
Note that FreeBSD ships natively with ntpd (and has for years),
and the upcoming 5-STABLE tree has already incorporated ntpd-4.2.0.
So, there's not really anything to install, unless you need to use
the very latest version from ports, which basically amounts to "make
install" and you're done.
Now, the configuring part, that can take a bit more work, but
there's not really anything specific to FreeBSD for that.
> So, I recommend you grab an old 486, load it with FreeBSD
> (http://www.US-Webmasters.com/FreeBSD/Install/) and install
> NTP.
If you want to make the most out of old Intel hardware, I think
FreeBSD is an excellent place to start.
--
Brad Knowles, <br...@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
David J Taylor
My own measurements:
http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html
suggest that providing no heavy interactive use is made of the machine,
NTP works fine - e.g. PCs Bacchus and Hermes. PC Odin (used for progrm
development) seems OK as well, but PC Stamsund which is used for making
photo panoramas and general Web browsing also seems to be subject to the
sorts of problems you are seeing. There is no logging in an out on any of
the PCs.
PC Bacchus is the only machine to rely purely on the Internet, and it is
pointed at seven Internet servers plus the router on the local cable modem
headend. It /does/ get affected if I am making either a full bandwidth
FTP download lasting more than about 1024 seconds (the poll time that all
of the servers are currently at), or if I am making a full bandwidth
upload like a very large e-mail.
PC Odin is used internally as a Web server, and is running very large
programs processing GB of data per day. It is transferring an average of
120kBytes/s from PC Hermes (from a 2Mb/s satellite link) so it is doing a
heck of a lot of network I/O.
Lost interrupts can be a problem. I have seen things like video players,
flash animations etc. cause this, and Sun's Java VM is broken which can
also cause this problem (you can run Sun's JVM with a startup parameter to
fix the problem).
You comment that even saving text files causes a problem - can I suggest
you check that your disks are running DMA and not polled I/O? Perhaps the
same with your network cards?
Cheers,
David
David J Taylor
In view of the reports of this problem on many OSes, isn't there something
which could be done to detect such missing interrupts?
Cheers,
David
David Woolley
Jerry Baker <je...@novalid.invalid> wrote:
> I have made several postings about how NTP is having a real problem
> remaining stable. I now have a little more than a weeks worth of data
I strongly suspect your problem is the same as the problem mentioned
in this article:
http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0410&L=ntbugtraq&F=P
&S=&P=3654
Note that this has no mention of any time synchronization software,
although it does have both Windows NT family and SETI@Home in common
with you. I doubt that S@H is relevant except as an almost entirely
CPU bound, low priority, process. That leaves Windows!
I am pretty sure (but haven't investigated in detail, and no longer am
allowed to install software on the NT family machines that I can use)
that Windows delays a lot of rescheduling until the next clock tick.
If either the ethernet device driver or ntpd suffers from this effect,
the time stamps on the receipt, and/or transmissions of the packets will
be out by up to one clock tick, and round trips will be liable to
jump backwards and forwards a tick.
> graphed with MRTG available. Perhaps I am expecting too much from NTP,
You're expecting too much from Windows.
> but it looks to me like there is something critically wrong with NTP's
You seem to be have been taking a very hostile attitude to ntpd all along,
but you have been continually changing the goalposts and dribbling in
critical pieces of information. What, for example, happened to your
original 2.6s step problem?
Looking at your MRTG graphs, you are not getting uni-directional clock
steps, but rather paired forward and backward steps, which are slightly
confused because the clock never appears stable enough for ntpd to
establish a large poll interval and long time constant, so ntpd has
partially corrected the step in one direction, before the counter step
(note, as I pointed out before, the phase errors are the cause of the
frequency changes, not the other way round). ntpd is doing its best
with low quality time data that keeps stepping backwards and forwards
by what looks like a clock tick.
> operation on the Windows platform (SNTP clients with no stepping keep
> better time).
How are you instrumenting the SNTP client? In any case, most SNTP clients
use relatively long poll intervals, which will tend to low pass filter
out the forwards and backwards steps in the time measurment. You may be
able to make ntpd filter them out by using a longer minpoll, but I can't
guarantee that that won't result in instability or a failure of the loop
to initally capture.
Of course, if you really think that ntpd is broken on NT, the source is
published and you can debug it yourself. The NT specific code ought to
be fairly easy to find.
> Take a look at http://jerbaker.dhs.org/ntp/
As I said, it looks as though there is an uncertainty of about one clock
tick in the basic measurements and ntpd is interpreting this as a very
unstable clock and trying to be responsive in tracking the time. A
scheduling problem is completely consistent with runs in one state,
followed by short runs in another state.
Note that, what you are graphing is the difference between the local
clock and the measurement of the time from the upstream server. The
local clock itself is moving much more smoothly, for any application
that interpolates between clock ticks; normal applications, will, as
always, see time with a resolution of one clock tick, so will have
something like a 20ms(?) sawtooth imposed on the accurate clock, but
that's purely down to Windows.
james edwards
>
> You're expecting too much from Windows.
>
> > but it looks to me like there is something critically wrong with NTP's
I thought it was common knowledge that any MS drops interrupts more than
other OS'es. The logical extension from this well know fact is that it is
not
going to keep time with the kind of accuracy a *nix host can achieve.
--
James H. Edwards
Routing and Security Administrator
At the Santa Fe Office: Internet at Cyber Mesa
jam...@cybermesa.com n...@cybermesa.com
http://www.cybermesa.com/ContactCM
(505) 795-7101
Danny Mayer
> In article <5Ih9d.8501$Sl2.3253@trnddc09>,
> Jerry Baker <je...@novalid.invalid> wrote:
>
> > I have made several postings about how NTP is having a real problem
> > remaining stable. I now have a little more than a weeks worth of data
>
> I strongly suspect your problem is the same as the problem mentioned
> in this article:
>
> http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0410&L=ntbugtraq&F=P
> &S=&P=3654
>
> Note that this has no mention of any time synchronization software,
> although it does have both Windows NT family and SETI@Home in common
> with you. I doubt that S@H is relevant except as an almost entirely
> CPU bound, low priority, process. That leaves Windows!
>
Actually no. I have documented proof that two unrelated pieces of software,
in my case BIND 9.2.2 and Windows Media Player, interact with
each other in unexpected ways. So don't dismiss S@H so easily though
it's not the only thing that can cause problems. For example netsvs
network services grabs upwards of 1200 handles when it's started on
Windows XP. W2K is much more moderate.
Danny
Danny Mayer
Not through ntp. This is a Windows internal problem. You'd need to
know the Windows internals throw in some hooking functions to see
what's being called, etc. It would not be easy to figure out and
even then there is almost certainly nothing that ntp could do.
Danny
> Cheers,
> David
Jerry Baker
> You seem to be have been taking a very hostile attitude to ntpd all along,
> but you have been continually changing the goalposts and dribbling in
> critical pieces of information. What, for example, happened to your
> original 2.6s step problem?
The problem was that killing NTP seems to leave the clock running with
whatever correction was being applied at the time it was stopped. Not
knowing how to return the clock to its "normal" tick interval, I just
reboot whenever I stop NTP and I don't have the problem any more.
David J Taylor
[]
> Not through ntp. This is a Windows internal problem. You'd need to
> know the Windows internals throw in some hooking functions to see
> what's being called, etc. It would not be easy to figure out and
> even then there is almost certainly nothing that ntp could do.
>
> Danny
Thanks, Danny.
As I said, it's not /just/ Windows that does this, though.
Cheers,
David
Jerry Baker
> You seem to be have been taking a very hostile attitude to ntpd all along,
> but you have been continually changing the goalposts and dribbling in
> critical pieces of information. What, for example, happened to your
> original 2.6s step problem?
I don't think it's hostile. NTP, after all, is a software package and I
don't think software can experience "hostility." The reason I suspect
NTP is because most of the people involved with NTP seem to be pretty
hostile towards Windows in general, and completely unwilling to even
entertain the notion of exploring possible work-arounds for this issue.
Most responses are something like, "uh, well, I don't have Windows but I
think it works like this."
> Looking at your MRTG graphs, you are not getting uni-directional clock
> steps, but rather paired forward and backward steps, which are slightly
> confused because the clock never appears stable enough for ntpd to
> establish a large poll interval and long time constant, so ntpd has
> partially corrected the step in one direction, before the counter step
> (note, as I pointed out before, the phase errors are the cause of the
> frequency changes, not the other way round). ntpd is doing its best
> with low quality time data that keeps stepping backwards and forwards
> by what looks like a clock tick.
The poll interval has remained 1024s for two weeks.
> How are you instrumenting the SNTP client? In any case, most SNTP clients
> use relatively long poll intervals, which will tend to low pass filter
> out the forwards and backwards steps in the time measurment. You may be
> able to make ntpd filter them out by using a longer minpoll, but I can't
> guarantee that that won't result in instability or a failure of the loop
> to initally capture.
I set up an SNTP client (D4) to poll every 15 minutes. When I do that it
shows a regular correction of about 5ms.
> Of course, if you really think that ntpd is broken on NT, the source is
> published and you can debug it yourself. The NT specific code ought to
> be fairly easy to find.
I hope your mechanic never says, "well, I'm not going to fix your car,
but if you think something is wrong there's all the parts."
David L. Mills
Sure, any machine with any SNTP client I have found can make a few tens
of milliseconds, as long as the computer clock oscillator is within 100
PPM or so and the network is well behaved and the NTPv4 extensions are
not required. I certainly would not want a SNTP client like your to
become a server and export 50-ms offsets to a population of dependent
clients. If OpenNTP is well written, documented and tested, I would very
much like to replace the current SNTP client presently in the NTPv4
distribution with it. Maybe the ISC guys can make that happen.
Dave
Peter Hessler wrote:
> On Thu, 14 Oct 2004 21:55:47 +0100
> da...@djwhome.demon.co.uk (David Woolley) wrote:
>
> :The non-legal, non-security, argument that they use is that most people
> :don't need better than about half a second accuracy (even if the starter
> :of this thread is complaining about 10ms errors). If you add on the
> :demands for sub-second initial time setting, step free response to major
> :input steps, and cooperating isolated islands (which account for most
> :of the current FAQs), the official ntpd is at risk of losing out to
> :poorer substitutes.
>
> I use OpenNTPD on my time server, and I am off by 0.027525 seconds at this
> time. Except for the initial sync, I am never off by more than 0.05
> seconds.
>
>
Jerry Baker
> It is perfectly understandable that most NTP hackers would much prefer
> to not have to spend time on such workarounds, but as I stated, some do,
> and we're currently seeing NTP times on Win* that's an order of
> magnitude better than what the OS is intrinsically capable of, which is
> quite an achievement IMHO.
>
> Terje
>
It is not my intent to discount the work of others. I was merely
pointing out that some people rely on others with more expertise to do
things. Learning the intracacies of NTP's various Windows hacks and
everything else is a tremendous waste of resources when there are
already people out there that know it. If they aren't interested in
fixing it, fine. That doesn't mean I shouldn't ask, nor does it make it
unreasonable to think that someone would want to investigate a problem
with their own creation. I sincerely apologize for assuming that someone
familiar with NTP's Windows code would be interested in tracking down a
blatant issue on the platform, especially with someone willing to do
almost all of the footwork. I would have much rathered to track it down
to Windows losing interrupts during log in events rather than just
assume that the cause is brokenness of Windows. To immediately say the
cause of this specific issue is Windows assumes that it has already been
investigated and resolved, and from what I see here that is not the case.
Wolfgang S. Rupprecht
Peter Hessler <phes...@theapt.org> writes:
> I use OpenNTPD on my time server, and I am off by 0.027525 seconds at this
> time. Except for the initial sync, I am never off by more than 0.05
> seconds.
I wonder if they fixed something in a the last few weeks. One of my
net neighbors runs a -current open-nntpd and he is usually 200ms off
of real time. All this on an enhanced DSL line.
His server also claims to be stratum-2 whether it is synchronized to
some high-numbered stratum or not. Darn annoying.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
Richard B. Gilbert
The difference is that your mechanic will hand you a big bill for fixing
whatever is wrong! I believe that ntp is a volunteer effort on the part
of all concerned. I think most of the developers use some version of
Unix and don't use Windows unless forced to by the requirements of
their regular jobs.
David L. Mills
Thanks for the careful analysis and reply. I copied the statement almost
verbatim from the MIT copyright statement for Kerberos. As I said, my
main goal is to preserve the connection with UDel as well as incorporate
the copyright statemenst of other authors you find in various files. As
for "losing to openntp," that doesn't bother me a bit. I do, however,
strongly object to calling it that; it is in brutal fact opensntp. I
would assume the OpenBSD folks to claim conformance to one specification
or another, for otherwise it surely is not maintainable.
Dave
David Woolley wrote:
> In article <ckkk9f$phc$1...@dewey.udel.edu>, David L. Mills <mi...@udel.edu> wrote:
>
>
>>The most important issue is that the University of Delaware remains the
>>copyright holder of this work
>
>
> That is not the issue that they are raising.
>
>
>> with individual authors acknowledged as
>>listed.
>
>
> Whilst I'm not a lawyer, to me the licence doesn't require other authors
> to surrender copyright. There is no requirement for contributors to
> assign copyright to the University of Delaware. Unless you have had
> contributors of non-trivial changes execute an assignment document
> (the Free Software Foundation actually requires a nominal payment, to
> form a valid contract, when doing this), I would say contributors own
> the copyrights in their non-trivial contributions.
>
> Requiring copyright assignment before inclusion in the official version
> would probably be a good idea, as it makes licence changes and licence
> enforcement easier. (Making it a requirement on all versions would
> definitely take the software out of the definition of "open source".)
>
>
>>listed. If somebody wants to rip it off in other products or sell it on
>>a CD,
>
>
> Open BSD's lawyer's argument is that the current licence does not permit
> this because the phrase "without fee" can be seen as qualifying "and
> distribute". CD's are typically distributed for a fee. They continue
> to distribute the Delaware version from their web site, because no fee
> is charged, but exclude it from their CDs, for which a charge is made.
> (A number of "freeware" licences explicitly ban supply on paid for CDs,
> so it is not unreasonable for their lawyer to assume that this is what
> you meant.)
>
>
>>Just be sure the UDel copyright notice is posted somewhere under the hood.
>
>
> They wouldn't have a problem with this; it's basically what they
> require of code for which they do own the copyright. In Europe, you
> would have a moral right to have such a notice, and even in the USA it
> is an open question as to whether it is possible to abandon copyright.
> Generally in the sort of open source circles in which BSD operate, not
> having a copyright notice would be a problem, as it makes auditting the
> copyright licensing difficult.
>
> The consequence of this dispute about the meaning of "without fee" is
> that a significant segment of the open source community is ganging up
> against ntpd in favour of a poor alternative, which is really SNTP, not
> NTP. This is being fueled by a certain feeling of righteousness, about
> being truly open source, but also about Open BSD as well. Open BSD users
> see it as being a very secure system, and are putting that attribute onto
> openntp (partly because it is small, because it isn't a full NTP
> implementation).
David L. Mills
As I said, I would absolutely adore a SNTP version that is well written,
strictly conformant to the SNTP spec and open source. The SNTP client
version now included with the NTPv4 is not such a program, but I have
been bushwhacked about putting it in the distribution anyway. There
should be independent versions of NTPv4 and SNTPv4 open source
distributions available via archives, preferable at ISC.
However, it is absolutely necessary to conform in every way to the
published specifications and conditions of use. After the Netgear
incident the folks at U Wisconsin, Netgear and I rewrote rfc2030 with
strict rules of engagement. It was our hope this would hit the streets
ASAP and we could send the Protocol Police after any freeboaters. The
RFC was dropped on the RFC Editor's desk over twelve months ago, but has
not yet survived the standards process.
As for the repo churn, your comments are deserved for the beta and
snapshot versions, but the release version has just had its first birthday.
Dave
Harlan Stenn
There are no bug reports against the sntp code in the distribution.
If there are problems with it I need to be told about it (bugzilla.ntp.org,
but I make an exception for you, Dave).
H
David J Taylor
[]
>> As I said, it's not /just/ Windows that does this, though.
>
For example, I have seen reports in this group of Linux with non-DMA disks
and too high a clock interrupt frequency.
> If it is common, it may be a hardware related issue.
> Have you checked the clock to see what its accuracy is without any
> time syncing?
> Have you checked your hardware config to see if say, the network card
> IRQ is being shared with other cards, and could have an impact on
> interrupts?
> Have you shut off all other network services to see if one of them
> could be having an impact on NTP?
> A Windows hardware group may offer better advice on these issues.
I'm not having this problem but that looks like a useful checklist for the
OP.
David
james edwards
> cause of this specific issue is Windows assumes that it has already been
> investigated and resolved, and from what I see here that is not the case.
Point out to me ***any*** stratum 1 or 2 server that is windows. I am
talking about
servers who are primary time sources for syncing others, not some funky box
on DSL.
Harlan Stenn
Peter Hessler <phes...@theapt.org> wrote:
>On Thu, 14 Oct 2004 21:55:47 +0100
>da...@djwhome.demon.co.uk (David Woolley) wrote:
>
>:don't need better than about half a second accuracy (even if the starter
>:of this thread is complaining about 10ms errors). If you add on the
>:demands for sub-second initial time setting, step free response to major
>:input steps, and cooperating isolated islands (which account for most
>:of the current FAQs), the official ntpd is at risk of losing out to
>:poorer substitutes.
>
>time. Except for the initial sync, I am never off by more than 0.05
>seconds.
Exactly what does "off by 0..2.. seconds" mean?
I suspect in your case it means "to the only server I am believing".
H
Danny Mayer
>
> The difference is that your mechanic will hand you a big bill for fixing
> whatever is wrong! I believe that ntp is a volunteer effort on the part
> of all concerned. I think most of the developers use some version of
> Unix and don't use Windows unless forced to by the requirements of
> their regular jobs.
In this case, oddly enough, this happens to be untrue. I do almost all
of the network programming work for NTP these days and my main
platform IS Windows. Most of the work right now is on Unix, but I do
make sure things keep working on Windows. This is not, of course, the
normal situation with open-source Internet software.
Right now I've been working on extracting the NT Service code
from ntpd.c and putting it into it's own file. The code is pretty
tangled there and it's hard to tell what it's doing. I also put together
a new installer to replace the instsrv stuff. This one makes Windows
NTPD services much more secure. It's not ready yet, though Terje has
seen it. I'm also making code changes to allow builds using VS.NET.
Danny
John DeDourek
I was one of the people having trouble with a Red Had Linux box. To
try to state the problem precisely (most of you know this already):
Most PC operating systems keep time by using an interrupt service
routine to increment the OS time variable. If you miss an interrupt,
the system time falls behind by one "clock tick" (OS dependent,
typical value 10ms). ntp will then speed up the clock for a while
until it catches up then slows it down to normal speed again.
Other things use interrupts and their associated service routines,
e.g to do network I/O, disk I/O, etc. The associated service
routines are in the driver for those devices. For technical
reasons beyond what I want to include here, the driver
must lock out all interrupts occassionally for "short" periods.
When the clock interrupt occurs while interrupts are locked out,
the clock interrupt routine can't run and update the clock. The
interrupt is stored in a one bit counter and the service runs
once when interrupts are enabled. IF TWO INTERRUPTS OCCUR
WHILE INTERRUPTS ARE LOCKED OUT, the counter stays at one
(cause the hardware designers don't put more than one bit in
those things). Thus the interrupt service routine only increments
the time by one tick, but the clock "ticked twice" and you
are behind one tick. Not a lot of hope for fixing that
without hardware redesign with more bits in the couter.
(I lie a little here; search
for rumblings about consulting the CPU cycle counter.)
Back to the OS. The problem is drivers, e.g. the network
driver. If it locks interrupts out "too long" you lose.
Driver has a certain number of instructions; it will take
longer to run those on a slow machine.
Also, for a while Red Hat in its "wisdom" ratcheted the
tick time down from 10 ms to around 2.5 ms if I recall.
Short tick, slow machine, I lost big time. Rebuilt
kernel and put tick back to 10 ms and things were better.
Got a faster machine and the other drivers ran quicker
(while the interrupts were locked out) and things ran
better. Still occasional glitches. What I need to
do is find a student who wants to instrument Linux to
find the bad drivers and suggest patches to fix
the problem. It is
possible witn Linux because we can fiddle with the
code.
This is where Windows loses. All you can
do is tell Microsoft, or the people supplying the
various binary driver disks that someone is locking
interrupts out for more than a tick and hope they have
incentive to fix it. Can't hope to fix that here.
ntp does its best when other things in the OS (drivers)
cause lost clock interrupts, but the time does wobble
as the OS problem pulls the time back and ntp pushes it
forward.
Harlan Stenn
You just did a much better job of saying what I tried to communicate!
Thanks!
H
Richard B. Gilbert
>On Thu, 14 Oct 2004 21:55:47 +0100
>da...@djwhome.demon.co.uk (David Woolley) wrote:
>
>:The non-legal, non-security, argument that they use is that most people
>:don't need better than about half a second accuracy (even if the starter
>:of this thread is complaining about 10ms errors). If you add on the
>:demands for sub-second initial time setting, step free response to major
>:input steps, and cooperating isolated islands (which account for most
>:of the current FAQs), the official ntpd is at risk of losing out to
>:poorer substitutes.
>
>I use OpenNTPD on my time server, and I am off by 0.027525 seconds at this
>time. Except for the initial sync, I am never off by more than 0.05
>seconds.
>
>
>
I'd say that's an order of magnitude poorer than the performance of
"official ntpd". Since it's "free", why not use the best?
Garrett Wollman
David Woolley <da...@djwhome.demon.co.uk> wrote:
>Open BSD's lawyer's argument is that the current licence does not permit
>this because the phrase "without fee" can be seen as qualifying "and
>distribute".
I've had to deal with this bogus argument for some time with respect
to the MIT license (which is also the X11 license, on which I believe
the UDel license is based). It has always been understood that the
"without fee" modifies "is hereby granted". Of course, a contract
lawyer's job is to point out potential ambiguities in the terms of an
agreement that might be interpreted to his client's detriment. (The
Open Group, when they took over the X Consortium, modified the license
slightly to eliminate this perceived ambiguity by moving the words
"without fee" after "granted".)
>The consequence of this dispute about the meaning of "without fee" is
>that a significant segment of the open source community is ganging up
>against ntpd in favour of a poor alternative, which is really SNTP, not
>NTP.
Actually, this issue has not come up (at least in relation to ntpd) in
FreeBSD at all. The major reasons FreeBSD has been contemplating
moving UDel ntpd out of base in favor of openntpd are:
1) SNTP is sufficient for most end systems' requirements.
2) The security posture of UDel's code base makes many people
uncomfortable.
2a) UDel's code base is very large and results in great deal of repo
churn every time a new version is imported.
3) Deprecation of ntpdate has angered many users.
4) Difficulty of keeping manual pages up-to-date with changes in UDel
documentation.
That said, there seems to be a consensus that openntpd is
insufficiently mature to take over at this time. You are invited to
look at the FreeBSD mailing-list archives for a more detailed
discussion.
-GAWollman
--
Garrett A. Wollman | As the Constitution endures, persons in every
wol...@lcs.mit.edu | generation can invoke its principles in their own
Opinions not those of| search for greater freedom.
MIT, LCS, CRS, or NSA| - A. Kennedy, Lawrence v. Texas, 539 U.S. ___ (2003)
Harlan Stenn
> I thought my position was well known.
If it's not in bugzilla it quickly falls off my radar.
> The SNTP client now in the distribution is poorly written,
While I'd format the block comments and the function prologues differently,
the code seems pretty clean to me. It also builds everywhere I have tried.
> likely to be misused (server)
This can be fixed pretty easily.
> and just not up to par with the ntpd code and maintenance mission.
We clearly disagree on the former point (there are hunks of code in ntpd
that nobody wants to touch because they are just arcane), and I don't
know what you mean by the "maintenance mission".
> A good, compliant SNTP client is not hard to write at all, but discipline
> is necessary to avoid feature bloat.
Nothing else has shown up.
> The feature most likely to be prized would be a MIB and SNMP client.
Nothing useful has shown up here, either.
And nobody has offered to either do the work or provide money to pay for
any development.
H
David J Taylor
[]
> I use OpenNTPD on my time server, and I am off by 0.027525 seconds at
> this time. Except for the initial sync, I am never off by more than
> 0.05 seconds.
.. which is least five times worse than using NTP, and would be
unacceptable for my own logging needs.
David
Terje Mathisen
> There aren't any because NTP does not operate properly on Windows.
> Whether this is a situation that is caused by Microsoft or NTP is
> irrelevant - it still doesn't work right. I want to figure out if there
> is any way to make NTP work better on Windows without just dismissing it
> altogether.
As several people have told you, there isn't any such way.
This is because the only way to fix the Windows system clock is to start
by fixing the HAL (Hardware Abstraction Layer) which is underneath the
actual Windows OS code, and then replace the 'GetSystemTimeAsFileTime()'
os call with one that will do proper interpolation between each timer tick.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Danny Mayer
Jerry, tracking down something like this is more work than I think you
realise and since it's not NTP that's causing the problem it doesn't get
a lot of my attention right now. If you are willing to do the legwork I'd
be happy to take the feedback and work it into the NTP Windows-specific
code which I am familiar with.
Danny
David J Taylor
[]
John,
Thanks for your concise explanation - I am familar with drivers and
interrupts so I can see both the need for interrupt prevention and the
problem with two lost interrupts. It's been a long time since I looked,
but as I recall the CMOS clock doesn't have milliseconds - what a pity!
> This is where Windows loses. All you can
> do is tell Microsoft, or the people supplying the
> various binary driver disks that someone is locking
> interrupts out for more than a tick and hope they have
> incentive to fix it. Can't hope to fix that here.
Well, while we may not be able to control how well drivers are written,
perhaps we could document drivers and software known to cause problems?
I'll start the list:
- Sun's Java Virtual Machine
Needs to be started with the "-XX:+ForceTimeHighResolution" parameter to
avoid loosing interrupts.
See:
http://www.macromedia.com/support/coldfusion/ts/documents/createuuid_clock_speed.htm
Perhaps this could be added to the documentation?
Cheers,
David
David J Taylor
[]
> Right now I've been working on extracting the NT Service code
> from ntpd.c and putting it into it's own file. The code is pretty
> tangled there and it's hard to tell what it's doing. I also put
> together
> a new installer to replace the instsrv stuff. This one makes Windows
> NTPD services much more secure. It's not ready yet, though Terje has
> seen it. I'm also making code changes to allow builds using VS.NET.
>
> Danny
Danny,
Your VS .NET builds would be welcome. I would have contributed in the
past (keeping the CMOS clock in sync across restarts), but getting 5 pages
of error messages when trying to build working code was not encouraging!
I hope the security won't be "over the top", as I've seen many problems
when things are made /too/ secure.
Many thanks for your continued efforts.
Cheers,
David
David L. Mills
What might have bitten you about documentation inconsistency might be
the fact that the documentation on the web at www.ntp.org is for the
latest features in the current tarball snapshot. This might not match
older documentation included in the distribution you might happen to
use. So, use the documentation that came with your particular
distribution. If for some reason you do not have access to the
documentation for your version, it should be available from the ISC
archives via www.ntp.org.
Dave
Brad Knowles wrote:
> At 9:55 PM +0000 2004-10-14, Garrett Wollman wrote:
>
>> 1) SNTP is sufficient for most end systems' requirements.
>
>
> Properly implemented, that might be true. IMO, OpenNTPd is not a
> proper implementation of SNTP. If you want that, consider msntp instead.
>
>> 2) The security posture of UDel's code base makes many people
>> uncomfortable.
>
>
> In what way? The fact that we actually support authentication?
>
>> 2a) UDel's code base is very large and results in great deal of
>> repo churn every time a new version is imported.
>
>
> We're trying to incorporate improvements from a wide variety of
> sources to a wide variety of places in the codebase, and to do so as
> quickly as we reasonably can in a volunteer project. If you would
> prefer that we do less, we can fire most of the volunteers and make sure
> that there are relatively few code changes that get made.
>
>> 3) Deprecation of ntpdate has angered many users.
>
>
> This is little more than an education problem. We never should have
> allowed ntpdate to be modified in all the multitudinous ways it was, and
> we should have incorporated the necessary features into ntpd instead.
> Almost all the features required are now incorporated into ntpd, and if
> people continue to gripe you could set up a hard link for the program
> name "ntpdate".
>
>> 4) Difficulty of keeping manual pages up-to-date with changes in UDel
>> documentation.
>
>
> We're working on that. Now that the public support services have
> been moved to ISC, that may be easier to keep in sync.
>
>> That said, there seems to be a consensus that openntpd is
>> insufficiently mature to take over at this time. You are invited to
>> look at the FreeBSD mailing-list archives for a more detailed
>> discussion.
>
>
> I've been on the FreeBSD mailing lists for several years. I have
> yet to see a single extensive discussion of NTP or ntpd on those lists.
> If I've missed some extensive discussion of NTP or ntpd, please let me
> know which lists those have been on.
>
> If you want to seriously consider OpenNTPd, then I would encourage
> you to look at
> <http://bradknowles.typepad.com/considered_harmful/2004/09/openntpd.html>
> and make sure that you have answered in your own mind how you're going
> to deal with all these problems.
>
james edwards
"Jerry Baker" <je...@novalid.invalid> wrote in message
> There aren't any because NTP does not operate properly on Windows.
> Whether this is a situation that is caused by Microsoft or NTP is
> irrelevant - it still doesn't work right. I want to figure out if there
> is any way to make NTP work better on Windows without just dismissing it
> altogether.
Then, as others have said, one would need access to the windows source to
investigate
what is happening here.
--
James H. Edwards
Routing and Security Administrator
At the Santa Fe Office: Internet at Cyber Mesa
jam...@cybermesa.com n...@cybermesa.com
http://www.cybermesa.com/ContactCM
(505) 795-7101
David J Taylor
> You can easily add this information under:
>
> http://ntp.isc.org/Support/KnownOsIssues
>
> H
Easily?
What do you do?
Where's the Help button?
I tried pressing Edit (I was expecting somthing like an Add or a New
button) and it starts asking for some sort of registration code.
I gave up at that point.
David
Harlan Stenn
David J Taylor <david-...@blueyonder.co.not-this-bit.nor-this-part.uk> wrote:
>Harlan Stenn wrote:
>> You can easily add this information under:
>>
>> http://ntp.isc.org/Support/KnownOsIssues
>
Most folks think so.
>What do you do?
Here's the easy version:
- Visit that link
- Click on the Edit button
- if you haven't registered, do so. You can use a fake name if you like,
and a disposable email address if you like (I use spamgourmet.com)
- Log in
- type away.
- click "Preview"
- Want to do more?
- YES - click "back", you are ate "type away"
- NO - click "save, you are done
>Where's the Help button?
There is a "TWiki System" link on the LH toolbar. It will take you to lots
of documentation.
At the bottom of each edit window there is a TextFormattingRules link that
has most all of the help I ever need. It may be worth reading the GoodStyle
link every once in a while.
There is one at the bottom of the text edit page. I think it is called
>I tried pressing Edit (I was expecting somthing like an Add or a New
>button) and it starts asking for some sort of registration code.
Yes, we ask for registration as a low-barrier way to ID who did what.
>I gave up at that point.
You we so very close...
H
David L. Mills
Massive disagreement. The code is rotten. My point stands, especially
with respect to protocol conformance and feature bloat. My comments have
nothing whatsoever to do with bugzilla. They have to do with style and
robustness of coding. If your radar requires bugzilla, I submit you need
new klystrons.
Dave
David J Taylor
[]
> Here's the easy version:
> H
OK, I tried adding that information, but I had to change to topic from
"Windows XP and PPS" to "Windows and Sun's JVM". I hope I didn't wipe out
any other info in the process.....
Cheers,
David
Harlan Stenn
more editing.
I expect it will be refined a bit more as time passes.
H
David J Taylor
Thanks for that, Harlan. As far as I can see, the two topics:
- Windows XP and PPS
- Windows and Sun's Java Virtual Machine
should be at the same "level", but as you know, I am new to the system.
Thanks for your help.
Cheers,
David
Harlan Stenn
There are several ways to do that, and I suspect either Steve or I will
make that happpen soon.
H
Goran Larsson
Brad Knowles <br...@stop.mail-abuse.org> wrote:
> If you want to seriously consider OpenNTPd, then I would
> encourage you to look at
> <http://bradknowles.typepad.com/considered_harmful/2004/09/openntpd.html>
> and make sure that you have answered in your own mind how you're
> going to deal with all these problems.
What happens if one of those broken OpenNTPd servers manages to be
listed in e.g. pool.ntp.org? Will it be filtered out as a false ticker
or will it be able to give me false time? How can I make sure my NTP
daemon never attempts to use an OpenNTPd "NTP server"?
--
Göran Larsson http://www.mitt-eget.com/
Steve Kostecke
https://ntp.isc.org/Support/WindowsXPAndPPS appears to be a request for
help, not a report of KnownOsIssues, and should probably be moved
elsewhere.
--
Steve Kostecke <kost...@ntp.isc.org>
David L. Mills
This is what Autokey is for. You need to boogie only with
Autokey-configured sites. Our primary server pogo has been running this
for several months in trial. I expect soon the ISC folks will start
handing out identity keys using an automated script. You would log in
via the web, provide your key-encrypting key and get back the identity
key. There are directions elsewhere, probably on the twichy, that tell
you how to configure the client, or see the authentication options page
in the current documentation.
The rfc2030 rules say a host can be a SNTP server only if directly
connected to an external source, such as a GPS radio or NIST modem. To
do that it would have to comply with the NTP protocol as a server, which
means it would have to implement the full suite of server functions as
described in rfc2030. A SNTP client obtaining time from another server
cannot be a server for other clients. To do that, it would have to
comply with the rfc1305 rules and include the NTP algorithms.
Dave
Dave
Richard B. Gilbert
> Goran,
>
>
>
> The rfc2030 rules say a host can be a SNTP server only if directly
> connected to an external source, such as a GPS radio or NIST modem. To
> do that it would have to comply with the NTP protocol as a server,
> which means it would have to implement the full suite of server
> functions as described in rfc2030. A SNTP client obtaining time from
> another server cannot be a server for other clients. To do that, it
> would have to comply with the rfc1305 rules and include the NTP
> algorithms.
>
> Dave
>
Does anyone enforce these "rules"?
Danny Mayer
As a practical matter, no. You either comply with the rfc or you don't.
If you do NOT comply, then you may have interoperability problems with
those servers and clients that do comply. The goal of all IETF RFC's
is to ensure and encourage interoperability. People won't buy or use
products that don't interoperate as they obtain products from many
different vendors. A vendor that doesn't interoperate with products
from other vendors isn't likely to stay in business very long as clients
won't buy products that don't work with other products that they
already have.
Danny
Brad Knowles
> What happens if one of those broken OpenNTPd servers manages to be
> listed in e.g. pool.ntp.org? Will it be filtered out as a false ticker
> or will it be able to give me false time? How can I make sure my NTP
> daemon never attempts to use an OpenNTPd "NTP server"?
I don't think there is really anything you can do to protect
yourself against them.
So far as I know, the only thing you can do is rely on Adrian to
do his job and try to ensure that none of the servers proposed for
pool.ntp.org will be running OpenNTPd.
--
Brad Knowles, <br...@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
David L. Mills
Well, if you consider the Netgear incident, yes. The sales department
tells the engineering department to comply with the rules, because to do
otherwise gets lots of folks really angry and they go public and that
hurts sales.
Dave
David Woolley
ma...@gis.net (Danny Mayer) wrote:
> As a practical matter, no. You either comply with the rfc or you don't.
> If you do NOT comply, then you may have interoperability problems with
> those servers and clients that do comply.
Unless, that is, you are the dominant market supplier and are trying to
encourage lock in to your product range, in which case W32 Time,
which is another broken implementation of SNTP, incidentally sharing
the bug of always reporting stratum 2 (so maybe the specification
is not adequately proof about people wanting implement but not
understand), is a good example of a non-compliant system that will not
be forced compliant by market forces.
The other way that you can get away with non-compliance is if you are
addressing a technically naive market, and some interoperability remains;
openntpd may be in that position, W32time certainly is. I think GUI email
programs are also good examples, e.g. it is quite common to have people
write 100s of characters on one line because their email program writer
didn't read the specification properly and thought it would be cool to
word wrap[1], without using the MIME media type that actually allows that,
not to mention that almost every HTML email is syntactically invalid
and often grossly violates the semantics.
Also, in the specific case of SNTP implementations violating the
pure server or pure client rule, both the server and client interfaces
could be compliant and therefore interoperate, but it is the system that
violates the RFC. Again, naive users will not appreciate the reasons
for the constraint, as their time keeping requirements may be quite lax
and and using a combined client/server SNTP, like W32time or openntpd
may seem a nice, low effort, solution, to them.
> The goal of all IETF RFC's
> is to ensure and encourage interoperability. People won't buy or use
> products that don't interoperate as they obtain products from many
> different vendors. A vendor that doesn't interoperate with products
Most businesses these days only buy desk top and server level machine
operating systems from Microsoft.
> from other vendors isn't likely to stay in business very long as clients
> won't buy products that don't work with other products that they
> already have.
Only if they are a minority supplier. A majority or monopoly supplier
generally wants a very basic level of interoperability, to allow migration
to their products, but incompatibility at higher levels of functionality,
so that the customer is locked in. "Lock in" is a factor that will normally
be discussed when a marketing department is planning a product or service,
although, in a lot of standards violation cases, it is more likely to be
the result of using developers good at achieving timescales, cost, and
sales time features but with no understanding of the application.
Standards have always been the realm of the small suppliers and the
big consumers. Even consuming organisations that, in theory, have rules
to require standards compliance, generally have mechanisms that can be
used to get dispensations when the alternative might be a politically
unacceptable (typically meaning non-Windows) solution.
[1] Recent versions of Mozilla can be configured to behave correctly, but
that battle is largely lost.
Goran Larsson
Brad Knowles <br...@stop.mail-abuse.org> wrote:
> I don't think there is really anything you can do to protect
> yourself against them.
Wouldn't using seven upstream servers do it, unless several of
them are openntp servers?
Brad Knowles
>> I don't think there is really anything you can do to protect
>> yourself against them.
>
> Wouldn't using seven upstream servers do it, unless several of
> them are openntp servers?
You would have no practical way to determine which of your
upstreams is running OpenNTPd, and seven upstreams would only protect
you against three falsetickers. Depending on how common this program
becomes, it could be practically impossible to protect yourself
against it.
Harlan Stenn
stratum 15 unless it is being "driven" by an attached refclock, and I
gather it does not presently support refclocks.
H
David Woolley
st...@maccarony.ntp.org (Harlan Stenn) wrote:
The important word here is "should". That permits operation without
a local reference clock, but discourages it. If the intention had beed
to forbid it, the word would have had to be "must".
Also, on a quick look, I think I understand why both Microsoft and OpenBSD's
implementations use 2 as their stratum, regardless of the upstream
stratum. Microsoft only use this if they have every been synchronised,
I'm not sure about openntpd. The following wording suffers from the very
common software documentation problem that it specifies one interface without
specifying how it relates to other interfaces:
2-15 secondary reference (via NTP or SNTP)
This doesn't say that the number must be greater than the input stratum,
so the typical implementor, who knows how to code, but nothing about the
application, will think that they can use any value in the range.
This also permits acting as both client and server.
Harlan Stenn
And I've seen SMTP implementations that were written by folks who had
never used email before. They made some interesting assumptions too.
The current behavior of openntp is wrong and should be fixed.
It should also clearly identify itself as an implementation of SNTP.
H