[ntp:questions] Windows time question.

Ryan Malayter malayter at gmail.com
Thu Apr 21 13:14:53 UTC 2011


On Thu, Apr 21, 2011 at 3:00 AM, David J Taylor
<david-taylor at blueyonder.co.uk.invalid> wrote:
> I might even take the view that "your illustrious IT droids" aren't doing
> their job properly if they aren't taking an interest in timekeeping to the
> extent of replacing W32Time by NTP in their standard install procedure! <G>
>  Perhaps timestamps of actions aren't critical your organisation.  I hope
> you may be able to convince them in due course.
>
> Having said that, I've not seen W32Time causing a crash, but my first step
> might be to rename the appropriate branches of the registry to try and make
> W32Time recreate them from scratch.

We have hundreds of Windows machines (all at v7 or 2008+ now), and I
have never seen Windows Time Service flake out or cause any trouble
since Windows XP SP1 was released. And even then, it never caused
lockups, just bad timekeeping. It basically just works within its
design space, unobtrusively. The best part about it is that it can
take configuration via Group Policy from Active Directory with a few
mouse clicks. Sure, it doesn't keep great time (16 ms precision), but
when configured properly with multiple sources it is more than
sufficient for most corporate desktop/laptop needs. So all our
workstations use it. Introducing a redundant utility such as ntpd
doesn't make any sense unless it is really needed by a specific use
case.

At my last check a few years ago, ntpd on Windows did not have sane
behavior when network connectivity changed (such as roaming from
Wrired ethernet to 3G modem) or coming in and out of sleep, hibernate,
and low-power modes. I'm not sure if any of that has changed recently,
but ntpd seems to be designed for servers, and that's about it. So we
use it on our Linux and Windows servers only where we have a need for
better than 16ms timekeeping. Note that most logging in OS and
applications does not include microseconds with timestamps, or worse
yet comes from managed-language runtimes such as Java or .NET that
have overheads that make such timestamps suspect. So the whole "need
highly accurate timestamps for security logging purposes" argument
falls flat in most corporate scenarios unless you control the whole
stack.
-- 
RPM



More information about the questions mailing list