Windows built-in SNTP/NTP clients - NTP

This is a discussion on Windows built-in SNTP/NTP clients - NTP ; Can someone post a list or point me to one, that shows which versions of MS-Windows have decent NTP clients? I know that NT/2K/XP does not but what about W2k3, '2k8, etc? -- Peter Laws / N5UWY National Weather Center ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Windows built-in SNTP/NTP clients

  1. Windows built-in SNTP/NTP clients

    Can someone post a list or point me to one, that shows which versions of
    MS-Windows have decent NTP clients? I know that NT/2K/XP does not but what
    about W2k3, '2k8, etc?

    --
    Peter Laws / N5UWY
    National Weather Center / Network Operations Center
    University of Oklahoma Information Technology
    plaws@ou.edu
    -----------------------------------------------------------------------
    Feedback? Contact my director, Craig Cochell, craigc@ou.edu. Thank you!

  2. Re: Windows built-in SNTP/NTP clients

    On Mon, Aug 11, 2008 at 10:15 AM, Peter Laws wrote:
    > Can someone post a list or point me to one, that shows which versions of
    > MS-Windows have decent NTP clients? I know that NT/2K/XP does not but what
    > about W2k3, '2k8, etc?


    http://support.ntp.org/bin/view/Supp...owsTimeService

    and these from my blog:

    http://blog.malayter.com/2006/05/win...p-service.html
    http://blog.malayter.com/2008/03/con...e-service.html
    --
    RPM

  3. Re: Windows built-in SNTP/NTP clients

    Peter Laws wrote:
    > Can someone post a list or point me to one, that shows which versions
    > of MS-Windows have decent NTP clients? I know that NT/2K/XP does not
    > but what about W2k3, '2k8, etc?


    Peter,

    In addition to Ryan's information, you can run the "official" NTP on
    Windows NT, 2000, XP and Vista, although it is not the "built-in" NTP:

    http://www.meinberg.de/english/sw/ntp.htm

    This will allow Windows to act as both server and client. I have been
    using that version on Windows Vista, but not with completely satisfactory
    results, showing high short-term jitter:

    http://www.satsignal.eu/mrtg/gemini_ntp.html

    Has anyone done tests on the native Vista NTP implementation? WHat is the
    performance like? Does it respond to NTPQ commands?

    Thanks,
    David



  4. Re: Windows built-in SNTP/NTP clients

    Ryan Malayter wrote:
    > On Mon, Aug 11, 2008 at 10:15 AM, Peter Laws wrote:
    >> Can someone post a list or point me to one, that shows which
    >> versions of MS-Windows have decent NTP clients? I know that
    >> NT/2K/XP does not but what about W2k3, '2k8, etc?

    >
    > http://support.ntp.org/bin/view/Supp...owsTimeService
    >
    > and these from my blog:
    >
    > http://blog.malayter.com/2006/05/win...p-service.html
    > http://blog.malayter.com/2008/03/con...e-service.html


    I just checked Vista (Home Premium) and the built-in NTP does not respond
    to NTPQ requests. Does the one in Windows 2003 or 2008? Can any
    implementation which fails to respond to NTPQ commands be called "decent"?

    Thanks,
    David



  5. Re: Windows built-in SNTP/NTP clients

    Peter Laws wrote:
    > Can someone post a list or point me to one, that shows which versions of
    > MS-Windows have decent NTP clients? I know that NT/2K/XP does not but what
    > about W2k3, '2k8, etc?


    None have decent ones. W2k3 SP2 has a fair one, and some people say
    this extends back to the unservice-packed version. Presumably later
    versions have, at least, the same software.

    I'm not aware of any built-in versions interpolating clock ticks and I'm
    not aware of any of them supporting any of the management interfaces,
    but I've not had sufficient hands on access to say these with absolute
    certainty.

    I believe that all of them require explicit configuration before they
    will make proper client requests.
    >


  6. Re: Windows built-in SNTP/NTP clients

    On Tue, Aug 12, 2008 at 2:21 AM, David J Taylor
    wrote:

    > I just checked Vista (Home Premium) and the built-in NTP does not respond
    > to NTPQ requests. Does the one in Windows 2003 or 2008? Can any
    > implementation which fails to respond to NTPQ commands be called "decent"?
    >


    NTP mode 6 packets are an OPTIONAL part of the NTP specification in
    RFC-1305, and RFC-1305 even goes so far as to suggest that mode 6
    packets be used only when other management and monitoring tools are
    unavailable. Microsoft provides other management tools (w32tm, group
    policy, event viewer, etc.), although they are barely sufficient.

    As far as I know, the reference implementation and its derivatives are
    the *only* implementations supported by ntpq. Some of its functions
    are even version-specific and not mentioned in any RFC, right?

    So asking you question the other way is just as valid: "Can any
    implementation which fails to respond to "w32tm" commands be called
    "decent"? Sounds silly.

    --
    RPM

  7. Re: Windows built-in SNTP/NTP clients

    Ryan Malayter wrote:
    > On Tue, Aug 12, 2008 at 2:21 AM, David J Taylor
    > wrote:
    >
    >> I just checked Vista (Home Premium) and the built-in NTP does not
    >> respond to NTPQ requests. Does the one in Windows 2003 or 2008?
    >> Can any implementation which fails to respond to NTPQ commands be
    >> called "decent"?
    >>

    >
    > NTP mode 6 packets are an OPTIONAL part of the NTP specification in
    > RFC-1305, and RFC-1305 even goes so far as to suggest that mode 6
    > packets be used only when other management and monitoring tools are
    > unavailable. Microsoft provides other management tools (w32tm, group
    > policy, event viewer, etc.), although they are barely sufficient.
    >
    > As far as I know, the reference implementation and its derivatives are
    > the *only* implementations supported by ntpq. Some of its functions
    > are even version-specific and not mentioned in any RFC, right?
    >
    > So asking you question the other way is just as valid: "Can any
    > implementation which fails to respond to "w32tm" commands be called
    > "decent"? Sounds silly.


    Thanks for your input, Ryan. I'm really thinking of the management
    environment, where you have a single monitor system checking on a host of
    different clients. I guess the "correct" approach there would be if all
    the clients responded to SNMP requests, rather than using a proprietary
    protocol. For the moment, though, I would want an NTP client which could
    be monitored by NTPQ (although only the offset is of routine interest to
    me).

    Cheers,
    David



  8. Re: Windows built-in SNTP/NTP clients

    "David J Taylor"
    wrote in
    message news:Nbvok.41764$E41.4596@text.news.virginmedia.co m...

    > [...] I guess the "correct" approach there would be if all the
    > clients responded to SNMP requests, rather than using a proprietary
    > protocol. ...


    It's stuck in my head that NTP has Assigned Numbers (MIBs? I'm
    not up to speed on SNMP) already, and SNMP capability could be
    added without too much trouble.

    I'm tying to see the catch - would this be for monitoring purposes
    only? There are many people who want to reconfigure on the fly; on
    the other hand there are probably even more people who only want
    to watch. And it might make sense for some high-end appliance
    manufacturer to develop, even.

    Groetjes,
    Maarten Wiltink



  9. Re: Windows built-in SNTP/NTP clients

    David,

    Neither does Windows implement the mode-6 protocol nor does it conform
    to the basic protocol. See the reference implementation documentation
    about Windows issues. Also see the alternative workaround in ntp_proto.c.

    As the author of rfc1305 I say you misquote me. The mode-6 control and
    monitoring protocol is an integral component of the specification; the
    mode-7 protocol is intended as propietary. In any case the mode-6
    protocol was defined and implmented well before SNMP.

    An NTP MIB has been implemented by some manufacturers and another
    proposed by the NTP working group, but neither is supported by the
    reference implementation. Either MIB might be appropriate for management
    purposes, but for complete monitoring and performance evalutation the
    limitations of current SNMP clients make the mode-6 protocol necessary.

    Dave

    David J Taylor wrote:
    > Ryan Malayter wrote:
    >
    >>On Tue, Aug 12, 2008 at 2:21 AM, David J Taylor
    >> wrote:
    >>
    >>
    >>>I just checked Vista (Home Premium) and the built-in NTP does not
    >>>respond to NTPQ requests. Does the one in Windows 2003 or 2008?
    >>>Can any implementation which fails to respond to NTPQ commands be
    >>>called "decent"?
    >>>

    >>
    >>NTP mode 6 packets are an OPTIONAL part of the NTP specification in
    >>RFC-1305, and RFC-1305 even goes so far as to suggest that mode 6
    >>packets be used only when other management and monitoring tools are
    >>unavailable. Microsoft provides other management tools (w32tm, group
    >>policy, event viewer, etc.), although they are barely sufficient.
    >>
    >>As far as I know, the reference implementation and its derivatives are
    >>the *only* implementations supported by ntpq. Some of its functions
    >>are even version-specific and not mentioned in any RFC, right?
    >>
    >>So asking you question the other way is just as valid: "Can any
    >>implementation which fails to respond to "w32tm" commands be called
    >>"decent"? Sounds silly.

    >
    >
    > Thanks for your input, Ryan. I'm really thinking of the management
    > environment, where you have a single monitor system checking on a host of
    > different clients. I guess the "correct" approach there would be if all
    > the clients responded to SNMP requests, rather than using a proprietary
    > protocol. For the moment, though, I would want an NTP client which could
    > be monitored by NTPQ (although only the offset is of routine interest to
    > me).
    >
    > Cheers,
    > David
    >
    >


  10. Re: Windows built-in SNTP/NTP clients

    David L. Mills wrote:
    > David,
    >
    > Neither does Windows implement the mode-6 protocol nor does it conform
    > to the basic protocol. See the reference implementation documentation
    > about Windows issues. Also see the alternative workaround in
    > ntp_proto.c.
    > As the author of rfc1305 I say you misquote me. The mode-6 control and
    > monitoring protocol is an integral component of the specification; the
    > mode-7 protocol is intended as propietary. In any case the mode-6
    > protocol was defined and implmented well before SNMP.
    >
    > An NTP MIB has been implemented by some manufacturers and another
    > proposed by the NTP working group, but neither is supported by the
    > reference implementation. Either MIB might be appropriate for
    > management purposes, but for complete monitoring and performance
    > evalutation the limitations of current SNMP clients make the mode-6
    > protocol necessary.
    > Dave


    Dave,

    It was Ryan and not I who wrote about mode-6 - I protest my innocence!

    I continue to recommend the reference implementation for Windows use, and
    I am grateful to those who continue to make a compiled version available.

    It would be good to see even a limited SNMP capability included in NTP -
    for monitoring only, not for control. Offset alone would be enough for
    me, although the ability to reproduce the ntpq -p display would be great.

    Cheers,
    David



  11. Re: Windows built-in SNTP/NTP clients

    On Wed, Aug 13, 2008 at 11:56 AM, David L. Mills wrote:
    > Neither does Windows implement the mode-6 protocol nor does it conform
    > to the basic protocol.


    Microsoft claims otherwise:
    "The Windows Time service integrates NTP version 3 with algorithmic
    enhancements from NTP version 4"
    from http://technet.microsoft.com/en-us/l.../cc773013.aspx
    There are plenty of references to RFC 1305 on those pages.

    The only strange behavior I've observed from Windows Time Service
    >2003 is the use of symmetric-active associations as a default.

    However, that is not a non-compliance problem, as client-mode
    associations are easily configured explicitly. It is just a stupid
    default.

    Now the lack of support for broadcast and multicast modes may be
    grounds for calling the implementation, but the RFC is a bit unclear
    as to whether all modes are required. The use of the standard RFC 221

    > As the author of rfc1305 I say you misquote me. The mode-6 control and
    > monitoring protocol is an integral component of the specification; the
    > mode-7 protocol is intended as propietary. In any case the mode-6
    > protocol was defined and implmented well before SNMP.


    >From RFC 1305 Appendix B, paragraph 1:

    "These messages are intended for use only in
    systems where no other management facilities are available or
    appropriate, such as in dedicated-function bus peripherals. Support for
    these messages is not required in order to conform to this
    specification."

    Now David, you may have *meant* something else, but what you wrote
    into RFC 1305 seems pretty clear. The first sentence quoted above
    clearly indicates that mode 6 packets are *not* the preffered method
    for management and monitoring of NTP systems. Any NTP implementer -
    even Microsoft - cannot be taken to task accountable for following the
    recommendations of RFC 1305!

    --
    RPM

  12. Re: Windows built-in SNTP/NTP clients

    Sorry, I accidentally hit send too soon during the middle of an edit.
    Damn you Gmail, and your odd keyboard shortcuts! My second paragraph
    should have read:

    "Now the lack of support for broadcast and multicast modes may be
    grounds for calling the implementation non-compliant, but the RFC is a
    bit unclear as to whether all modes of operation are required. The use
    of the standard RFC 2119 language (MUST, SHOULD, MAY, MUST NOT, etc.)
    was obviously not possible as RFC 1305 pre-dates that RFC by many
    years. Does the NTPv4 draft remedy this and use RFC 2119-style
    language?"

    Regards,

    --
    RPM

  13. Re: Windows built-in SNTP/NTP clients

    David J Taylor wrote:

    >
    > In addition to Ryan's information, you can run the "official" NTP on
    > Windows NT, 2000, XP and Vista, although it is not the "built-in" NTP:
    >
    > http://www.meinberg.de/english/sw/ntp.htm



    I'm a big proponent of that package and have it on everything I maintain
    (which is few, thankfully!) ... but this is a W2k3 server maintained by
    another group (a MS-centric group) and I'd rather educate them gently
    instead of just saying "here's a nickel kid, go buy yourself a *real* time
    server" ... Even if I think that's the best course of action!:-)



    --
    Peter Laws / N5UWY
    National Weather Center / Network Operations Center
    University of Oklahoma Information Technology
    plaws@ou.edu
    -----------------------------------------------------------------------
    Feedback? Contact my director, Craig Cochell, craigc@ou.edu. Thank you!

  14. Re: Windows built-in SNTP/NTP clients

    Davod.

    Mea culpa; I didn't mean to blame you. If all you want is to watch
    antother NTP server or client, just spark up a configuration and set the
    noselect bit. The problem with SNMP clients is that they fail to deal
    with the complete set of data types, specifically floating double.

    We did a project sevral years ago by implementing an SNMP agent
    integrated with a NTP mode-6 agent that worked very well. But, I was not
    in a position to maintain it and there were no other volunteers. Harlan
    has a project doing that now; he is invited to report progress.

    Dave

    David J Taylor wrote:

    > David L. Mills wrote:
    >
    >>David,
    >>
    >>Neither does Windows implement the mode-6 protocol nor does it conform
    >>to the basic protocol. See the reference implementation documentation
    >>about Windows issues. Also see the alternative workaround in
    >>ntp_proto.c.
    >>As the author of rfc1305 I say you misquote me. The mode-6 control and
    >>monitoring protocol is an integral component of the specification; the
    >>mode-7 protocol is intended as propietary. In any case the mode-6
    >>protocol was defined and implmented well before SNMP.
    >>
    >>An NTP MIB has been implemented by some manufacturers and another
    >>proposed by the NTP working group, but neither is supported by the
    >>reference implementation. Either MIB might be appropriate for
    >>management purposes, but for complete monitoring and performance
    >>evalutation the limitations of current SNMP clients make the mode-6
    >>protocol necessary.
    >>Dave

    >
    >
    > Dave,
    >
    > It was Ryan and not I who wrote about mode-6 - I protest my innocence!
    >
    > I continue to recommend the reference implementation for Windows use, and
    > I am grateful to those who continue to make a compiled version available.
    >
    > It would be good to see even a limited SNMP capability included in NTP -
    > for monitoring only, not for control. Offset alone would be enough for
    > me, although the ability to reproduce the ntpq -p display would be great.
    >
    > Cheers,
    > David
    >
    >


  15. Re: Windows built-in SNTP/NTP clients

    Ryan,

    That was 16 years ago and you know exactly what I meant. If you are
    going to implement a mode-6 control and monitoring protocol, then you
    must conform to the specification. Period. Any other interpretation is
    stupid.

    Dave

    Ryan Malayter wrote:

    > On Wed, Aug 13, 2008 at 11:56 AM, David L. Mills wrote:
    >
    >>Neither does Windows implement the mode-6 protocol nor does it conform
    >>to the basic protocol.

    >
    >
    > Microsoft claims otherwise:
    > "The Windows Time service integrates NTP version 3 with algorithmic
    > enhancements from NTP version 4"
    > from http://technet.microsoft.com/en-us/l.../cc773013.aspx
    > There are plenty of references to RFC 1305 on those pages.
    >
    > The only strange behavior I've observed from Windows Time Service
    >
    >>2003 is the use of symmetric-active associations as a default.

    >
    > However, that is not a non-compliance problem, as client-mode
    > associations are easily configured explicitly. It is just a stupid
    > default.
    >
    > Now the lack of support for broadcast and multicast modes may be
    > grounds for calling the implementation, but the RFC is a bit unclear
    > as to whether all modes are required. The use of the standard RFC 221
    >
    >
    >>As the author of rfc1305 I say you misquote me. The mode-6 control and
    >>monitoring protocol is an integral component of the specification; the
    >>mode-7 protocol is intended as propietary. In any case the mode-6
    >>protocol was defined and implmented well before SNMP.

    >
    >
    >>From RFC 1305 Appendix B, paragraph 1:

    > "These messages are intended for use only in
    > systems where no other management facilities are available or
    > appropriate, such as in dedicated-function bus peripherals. Support for
    > these messages is not required in order to conform to this
    > specification."
    >
    > Now David, you may have *meant* something else, but what you wrote
    > into RFC 1305 seems pretty clear. The first sentence quoted above
    > clearly indicates that mode 6 packets are *not* the preffered method
    > for management and monitoring of NTP systems. Any NTP implementer -
    > even Microsoft - cannot be taken to task accountable for following the
    > recommendations of RFC 1305!
    >


  16. Re: Windows built-in SNTP/NTP clients

    On Thu, Aug 14, 2008 at 12:17 PM, David L. Mills wrote:
    > Ryan,
    >
    > That was 16 years ago


    It is still the only published standard for implementers to use.

    > and you know exactly what I meant. If you are
    > going to implement a mode-6 control and monitoring protocol, then you
    > must conform to the specification. Period. Any other interpretation is
    > stupid.


    It seems that any definition of the content of mode 6 packets has been
    removed from draft-ietf-ntp-ntpv4-proto-10. I don't know what to make
    of that, and I'm sure other implementers would be confused about it as
    well.

    --
    RPM

  17. Re: Windows built-in SNTP/NTP clients

    Folks,

    I hope to have something to say about the new SNTP code within the next few
    weeks' time.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  18. Re: Windows built-in SNTP/NTP clients

    Ryan,

    So far as I am concerned, the mode-6 C&M protocol remains as in rfc1305,
    althougth not in the current NTPv4 draft. The WG intent is to publish
    that in a separate draft.

    There was never any intent to detail the various billboards and eye
    candy in the specification, only the status words and read/write
    commands. These depend on the particular implementation; in the
    reference implementation these details are in the ntpq and decode
    documentation pages. They are by design not in the specification, as
    they change in minor ways as the algorithms evolve and new features are
    added.

    Dave

    Ryan Malayter wrote:
    > On Thu, Aug 14, 2008 at 12:17 PM, David L. Mills wrote:
    >
    >>Ryan,
    >>
    >>That was 16 years ago

    >
    >
    > It is still the only published standard for implementers to use.
    >
    >
    >>and you know exactly what I meant. If you are
    >>going to implement a mode-6 control and monitoring protocol, then you
    >>must conform to the specification. Period. Any other interpretation is
    >>stupid.

    >
    >
    > It seems that any definition of the content of mode 6 packets has been
    > removed from draft-ietf-ntp-ntpv4-proto-10. I don't know what to make
    > of that, and I'm sure other implementers would be confused about it as
    > well.
    >


+ Reply to Thread