[ale] RHEL use AD server for NTP?

Wed Jan 3 15:20:50 EST 2018

Interesting note from Microsoft:

"Prior to Windows Server 2016, the W32Time service was not designed to meet
time-sensitive application needs. However, updates to Windows Server 2016
now allow you to implement a solution for 1ms accuracy in your domain. See
Windows 2016 Accurate Time and Support boundary to configure the Windows
Time service for high-accuracy environments for more information."

Source URL:
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/w
indows-time-service/how-the-windows-time-service-works

P.S. I've used Windows AD servers for years without issue.  Also, Active
Directory (AD) is a little picky with time, so it is critical that the
servers all have almost the exact same time.

/Raj

-----Original Message-----
From: Ale [mailto:ale-bounces at ale.org] On Behalf Of Lightner, Jeffrey via
Ale
Sent: Wednesday, January 3, 2018 1:17 PM
To: DJ-Pfulio <DJPfulio at jdpfu.com>; Atlanta Linux Enthusiasts <ale at ale.org>
Subject: Re: [ale] RHEL use AD server for NTP?

I'd hate to base my opinion of anything computer related on what something
did 20 years ago (the late 90s).   Even 2005 was a full 12 years ago.

I'm not a fan of Windows (and less so of Apple) but I can say we've been
using the Windows DCs as time source for a couple years now and so far I've
not found any issues I could attribute to the time on the DCs.   I
especially have not seen our DCs doing +/- 5 minutes gaps like those you
describe.   Of course I much preferred it when we had our own GPS time
sources but those cost money.

-----Original Message-----
From: Ale [mailto:ale-bounces at ale.org] On Behalf Of DJ-Pfulio via Ale
Sent: Wednesday, January 03, 2018 11:56 AM
To: ale at ale.org
Subject: Re: [ale] RHEL use AD server for NTP?

Windows can't keep time.  They've had this issue since at least 1995.
Around 2005, I spoke with onsite MSFT engineers about this and their stance
was that +/- 5min was close enough. My work-provided machine was running
about 3 min late, thanks to Windows time being off, so I'd join every
meeting/conferent 3 min late.

In the late 1990s, I was fed up with Windows time issues and brought up an
internal Linux NTP server.  Pointed all my systems at it, including Windows.
To get Windows clients to keep time, I had to force the NTP updates to be
every 15 min.  Every hour and Windows would drift 3+ minutes.

BTW, the Linux system used as the time server had Windows on it for a year
before and couldn't keep correct time.  It has been running Linux as a VM
host since then, and keeps sub-sec accuracy all this time.

As for virtual machines and time accuracy, this depends on the hypervisor
used. Some provide NTP extensions to their guest addons which are supposed
to get time from the hostOS HW clock.  IME, this mostly works.  NTP Linux to
Linux between a physical hostOS and all guest VMs on it and other hosts,
don't seem to have the time drift issue. At least not on my 20-30 systems.

I've run vbox, ESXi, KVM and Xen VM hosts. They all behaved about the same,
except vbox.  I treat all my Linux VMs like they are physical machines,
except using virtio drivers for NICs and storage.

The Windows guests still drift a little, even with 15min forced syncs,
virtio drivers and QXL video.  Every few weeks, I discover a Windows guest
is off enough to bother me - manual re-sync fixes it for a few weeks.  I've
tried to automate that, but the net /time stuff doesn't seem to work.

I don't need real-time accuracy, but sub-second accuracy isn't THAT hard
since 1993, really.  There's really no good reason for MSFTs 'tude about
this. Perhaps they've fixed it in the time since I stopped accepting their
patches about 2 yrs ago?

That's what I think I know.  YMMV.

Just for fun, here's the current 'date' for a few Linux systems, most are
VMs, pulled over about 5 seconds:
Wed Jan  3 11:51:12 EST 2018
Wed Jan  3 11:51:14 EST 2018
Wed Jan  3 11:51:14 EST 2018
Wed Jan  3 11:51:14 EST 2018
Wed Jan  3 11:51:15 EST 2018
Wed Jan  3 11:51:15 EST 2018
Wed Jan  3 11:51:16 EST 2018
Wed Jan  3 11:51:16 EST 2018
Wed Jan  3 11:51:17 EST 2018
Wed Jan  3 11:51:17 EST 2018
Wed Jan  3 11:51:17 EST 2018

Close enough.   Checked a Windows VM, it was off about ... 2 sec, which
was pretty great for it.  Forced a sync a few days ago. It was off 3 min
then.

The date run was Ansible at work. ;)  I haven't seen much difference in time
sync between all the Linux systems. The time host is an Ubuntu
14.04 LTS server.

On 01/03/2018 10:49 AM, Jim Kinney via Ale wrote:
> I've had issues with the clock on VMs dragging but never had an issue 
> with a VM as an NTP server. As a server, it checks upstream more often 
> and thus the lag and drift is microscopic.
> 
> On Wed, 2018-01-03 at 10:12 -0500, Leam Hall via Ale wrote:
>> I've heard that RHEL 6 boxes have issues using Winderz AD servers as 
>> a time source. While a VM to VM ntp query is always iffy, is there 
>> anything to the claim? If so, what can be done about it?
>>
_______________________________________________
Ale mailing list
Ale at ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
Ale at ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo