Windows 2000 build-in NTP client
Gilles Vollant
Windows 2000 contain a build-in NTP client.
First, you need select a NTP server, using the command line :
net time /setsntp:ntp-server
by example:
net time /setsntp:tock.usno.navy.mil
if you use the tock.usno.navy.mil ntp server.
After, you need start the W32time service. You can use the command line:
net start W32Time
But the better way is probably set the start option of the Windows Time
Synchronization service (W32Time) to Automatic, so the service will start
when Windows start.
These page gives more information about NTP in Windows 2000
http://support.microsoft.com/support/kb/articles/q224/7/99.asp
http://support.microsoft.com/support/kb/articles/q216/7/34.asp
http://support.microsoft.com/support/kb/articles/q223/1/84.asp
Pe...@_nospam_mosier.com
will probably get this message:
Could not locate a time-server.
More help is available by typing NET HELPMSG 3912.
The problem is that if you are not authoritative in your domain (for
example, a standalone home machine running W2K professional) then you won't
be able to use a time server outside your network. W32Time is set up so
that only one machine is allowed to get the time from an external (i.e.
internet NTP) source.
So if you are a home user like me, this doesn't seem to work.
This is confirmed in Q243574:
http://support.microsoft.com/support/kb/articles/Q243/5/74.ASP
Which says:
"Windows 2000 servers that are not domain controllers and Windows 2000
Professional-based computers attempt to locate a domain controller to
synchronize the network time. Domain controllers attempt to contact the
domain controller that holds the primary domain controller (PDC) Flexible
Single Master Operation (FSMO) role. Only the domain controller that holds
the PDC FSMO role can query an external time source to set the time."
Too bad they don't seem to mention an alternative method. I will personally
try TimeServ (from the NT res kit) which can be found at:
ftp://ftp.microsoft.com/reskit/y2kfix/x86/timeserv/timeserv.htm
"Gilles Vollant" <in...@winimage.com> wrote in message
news:8tgkmf$84t$1...@wanadoo.fr...
David Woolley
from aste-genev-bois-101-1-176.abo.wanadoo.fr,
Gilles Vollant <in...@winimage.com> wrote:
> net time /setsntp:tock.usno.navy.mil
> if you use the tock.usno.navy.mil ntp server.
That's not a good example. I find it difficult to think of any good
reason, other than system diagnostics, to use this server with SNTP,
especially from France (I get zero good returns with ntpdate -d from
London).
I would say that SNTP users within a company site should be using the
company NTP server and people directly connected to ISPs should be using
the ISP's server (or the ISP's ISP's server, etc., until you find a
competent ISP in the chain).
Andrej Borsenkow
>
It is not NTP it is SNTP.
-andrej
Gilles Vollant
"David Woolley" <da...@djwhome.demon.co.uk> a écrit dans le message news:
T9728...@djwhome.demon.co.uk...
> In article <8tgkmf$84t$1...@wanadoo.fr>,
> from aste-genev-bois-101-1-176.abo.wanadoo.fr,
> Gilles Vollant <in...@winimage.com> wrote:
>
> > net time /setsntp:tock.usno.navy.mil
> > if you use the tock.usno.navy.mil ntp server.
>
> That's not a good example.
This is an example, I used the Microsoft example
From France, I use ntp.internet-fr.net
Gilles Vollant
"Andrej Borsenkow" <Andrej.B...@mow.siemens.ru> a écrit dans le message
news: 8tlq0c$64p$1...@news.mch.sbs.de...
Andrej Borsenkow
phase and frequency) with the best precision possible. This incliudes
estimates of roundtrip time between client and server to get offset between
two colcks. This explains why NTP packet carries four timestamps (two
transmits and two recieves).
The purpose of SNTP is to simply ask server about its current time. Quoting
RFC1769:
In both unicast and broadcast modes, the unicast server reply or
broadcast message includes all the fields described above; however,
in SNTP only the Transmit Timestamp has explicit meaning and then
only if nonzero. The integer part of this field contains the server
time of day in the same format as the UDP/TIME Protocol [POS83].
While the fraction part of this field will usually be valid, the
accuracy achieved with SNTP may justify its use only to a significant
fraction of a second. If the Transmit Timestamp field is 0, the
message should be disregarded.
The main advantage of NTP daemon is, that after it has computed local error,
it can maintain correct time with good precision even if no external source
is available. But to compute this error it needs all data from NTP packet
and this is not available in SNTP.
-andrej
"Gilles Vollant" <in...@winimage.com> wrote in message
news:8togf3$eh9$1...@wanadoo.fr...
Doug Hogarth
believe that MS Win2K uses the various timestamps so that it can attempt to
adjust for half-roundtrip delay and any delay at the server. But I'd still
call it Simple because of issues like using only one server, etc.
"Andrej Borsenkow" <Andrej.B...@mow.siemens.ru> wrote in message
news:8tok8o$c7i$1...@news.mch.sbs.de...
Nick Maclaren
In article <8tok8o$c7i$1...@news.mch.sbs.de>,
"Andrej Borsenkow" <Andrej.B...@mow.siemens.ru> writes:
|> The purpose of NTP is to get reliable estimate of local clock error (both
|> phase and frequency) with the best precision possible. This incliudes
|> estimates of roundtrip time between client and server to get offset between
|> two colcks. This explains why NTP packet carries four timestamps (two
|> transmits and two recieves).
In almost all cases, three would be enough, but that is by the way.
Specifying four does little harm, and may be useful in some cases.
|> The purpose of SNTP is to simply ask server about its current time. Quoting
|> RFC1769:
|>
|> In both unicast and broadcast modes, the unicast server reply or
|> broadcast message includes all the fields described above; however,
|> in SNTP only the Transmit Timestamp has explicit meaning and then
|> only if nonzero. The integer part of this field contains the server
|> time of day in the same format as the UDP/TIME Protocol [POS83].
|> While the fraction part of this field will usually be valid, the
|> accuracy achieved with SNTP may justify its use only to a significant
|> fraction of a second. If the Transmit Timestamp field is 0, the
|> message should be disregarded.
This is misleading, because it applies when you have a SNTP server;
a SNTP client can do a LOT better. The NTP and SNTP data protocols
are identical, and almost all SNTP clients are used with NTP servers.
In fact, an SNTP server can do better, but the conditions under which
it can do so are more complex. An SNTP client can ALWAYS do better!
|> The main advantage of NTP daemon is, that after it has computed local error,
|> it can maintain correct time with good precision even if no external source
|> is available. But to compute this error it needs all data from NTP packet
|> and this is not available in SNTP.
Actually, it is. My SNTP client uses it and achieves the same effect.
In my view, the mistake in RFC 2030 was in specifying a server mode
with an unreasonably downgraded interface. I should have preferred
RFC 2030 to specify merely an SNTP client interface and say that it
is expected to receive packets from either an NTP server or a
direct time server that behaves like a stratum 1 NTP server.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Terje Mathisen
>
> In article <8tok8o$c7i$1...@news.mch.sbs.de>,
> "Andrej Borsenkow" <Andrej.B...@mow.siemens.ru> writes:
> |> The purpose of NTP is to get reliable estimate of local clock error (both
> |> phase and frequency) with the best precision possible. This incliudes
> |> estimates of roundtrip time between client and server to get offset between
> |> two colcks. This explains why NTP packet carries four timestamps (two
> |> transmits and two recieves).
>
> In almost all cases, three would be enough, but that is by the way.
> Specifying four does little harm, and may be useful in some cases.
Three would be exactly equivalent to the current situation, if the
server makes sure to split the processing time in two, and then enter
the same time for both it's timestamps.
The current setup is nicer though, with better symmetry, and it makes it
_slightly_ easier since there's never any need for the server to read
time stamps back from the packet (or to save them locally).
Terje
--
- <Terje.M...@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
Nick Maclaren
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>Nick Maclaren wrote:
>>
>> In article <8tok8o$c7i$1...@news.mch.sbs.de>,
>> "Andrej Borsenkow" <Andrej.B...@mow.siemens.ru> writes:
>> |> The purpose of NTP is to get reliable estimate of local clock error (both
>> |> phase and frequency) with the best precision possible. This incliudes
>> |> estimates of roundtrip time between client and server to get offset between
>> |> two colcks. This explains why NTP packet carries four timestamps (two
>> |> transmits and two recieves).
>>
>> In almost all cases, three would be enough, but that is by the way.
>> Specifying four does little harm, and may be useful in some cases.
>
>Three would be exactly equivalent to the current situation, if the
>server makes sure to split the processing time in two, and then enter
>the same time for both it's timestamps.
>
>The current setup is nicer though, with better symmetry, and it makes it
>_slightly_ easier since there's never any need for the server to read
>time stamps back from the packet (or to save them locally).
Yes, quite. For the few uses of NTP that operate at that level,
it helps a little; and the others don't care.
However, when talking about SNTP, all the server has to do is
to store a few fields and its timestamp or timestamps; there is
no processing of consequence, so the error introduced by storing
only one would be negligible. When my program is operating in
server mode, it stores the same value twice, as is appropriate
for an SNTP server; this saves one system call ....
It is a trivial matter, but of such things are Usenet threads
made :-)
Ned Robie
I require clock synchronization accuracy on Win2k and WinNT of less than 10ms.
It's documented that SNTP is not designed to provide this, so I need to run
NTP.
I installed NTP (version 4.0.99k) on two WinNT 4.0 hosts in a client/server
config.
The server's reference clock is its local clock.
The client synched up in 2 to 3 minutes with .00095-.00096 dispersion, then lost
synch after about 30 minutes (reach went to 0 for perhaps one polling
interval), then resynched within 2 to 3 minutes.
This occurred repeatedly. Any ideas on what might be causing this?
There are no other apps using port 123 on either machine.
Also, I'm not sure what I need to do on Win2k to (temporarily) disable
W32Time so it doesn't step on NTP's toes. I was hoping W32Time is
really full-fledged NTP and that I might be able to use it as an NTP server,
but that doesn't appear to be the case since I can't get an NTP client to reach
it.
I found http://support.microsoft.com/support/kb/articles/Q223/1/84.ASP,
but can't find any detailed information about what these vars really do.
Any help/comments/advice would be appreciated.
-- Ned R.
Gilles Vollant wrote:
> Can you explain difference ?
>
> "Andrej Borsenkow" <Andrej.B...@mow.siemens.ru> a ecrit dans le message
Andrej Borsenkow
"Ned Robie" <n...@ganymede.com> wrote in message
news:3A08807B...@ganymede.com...
> Well, while we're on the subject...
>
> I require clock synchronization accuracy on Win2k and WinNT of less than
10ms.
> It's documented that SNTP is not designed to provide this, so I need to
run
> NTP.
>
> I installed NTP (version 4.0.99k) on two WinNT 4.0 hosts in a
client/server
> config.
> The server's reference clock is its local clock.
>
> The client synched up in 2 to 3 minutes with .00095-.00096 dispersion,
then lost
> synch after about 30 minutes (reach went to 0 for perhaps one polling
> interval), then resynched within 2 to 3 minutes.
>
> This occurred repeatedly. Any ideas on what might be causing this?
> There are no other apps using port 123 on either machine.
>
Yes. The problem is that your server is using local clock as reference
clock. I had exactly the same problem trying to sync several systems without
external "true" time source.
I never investigated it really deep (when I started to understand better how
ntpd works, I already had access to reference clocks). Unless your server
has *very* stable clock (that I do not believe - mine does not), ntpd on
client is forced to think, it is *its* time that goes wrong and tries to
correct it.
Find true time source. In my experience, ntpd is pretty useless without it.
-andrej
Rob MacGregor
> Well, while we're on the subject...
>
> I require clock synchronization accuracy on Win2k and WinNT of less than 10ms.
> It's documented that SNTP is not designed to provide this, so I need to run
> NTP.
>
> I installed NTP (version 4.0.99k) on two WinNT 4.0 hosts in a client/server
> config.
> The server's reference clock is its local clock.
>
> The client synched up in 2 to 3 minutes with .00095-.00096 dispersion, then lost
> synch after about 30 minutes (reach went to 0 for perhaps one polling
> interval), then resynched within 2 to 3 minutes.
>
> This occurred repeatedly. Any ideas on what might be causing this?
> There are no other apps using port 123 on either machine.
I'm currently running 4.0.99f on W2K to a pair of boxes (Linux and BSD) running
4.0.99j. I haven't seen the problem you describe, but then my servers have a real
time source. Have you checked NTP on your server - maybe it's the one causing the
problem?
> Also, I'm not sure what I need to do on Win2k to (temporarily) disable
> W32Time so it doesn't step on NTP's toes. I was hoping W32Time is
> really full-fledged NTP and that I might be able to use it as an NTP server,
> but that doesn't appear to be the case since I can't get an NTP client to reach
> it.
Have you tried simply disabling the service? That should do it (currently I'm
running NTP on my W2K desktop with the "Windows Time" service at Manual startup).
--
Rob MacGregor (MCSE) [PGP key ID 0x1F5239DD]
The light at the end of the tunnel is an oncoming dragon.
Real email address (just add @ . ): rob_macgregor hotmail com