What are some options for getting my domain time tighter than w32tm will allow? Trading transaction in some of our apps dont like the loose time we've been seeing. Folks are telling me they need it down to the second. What have you all done out there?
Accurizing Domain Time
- 171 Views
- Last Post 16 December 2015
Before I give you a long answer I have have questions.
Is this more related to the NTP source? When you have a business requirement of 1 second, is that someone’s workstation to an application server? Is that application
server part of your domain?
Is your PDCe syncing from an external Internet source?
What OSs are your DCs, workstations, and application server?
try any product from the list http://www.nist.gov/pml/div688/grp40/softwarelist.cfm
I'm waiting to hear what Jeremy says, but we've implemented a
Spectracom GPS-based net clock, because we're an engineering firm with
tight requirements for the equipment and systems we design, and as a
side benefit it is also used for our IT infrastructure.
Be careful. As with any system that involves a balancing feedback loop like the time services Windows uses within a domain, you can get results very different
than you expect when you try to make changes without taking into account all the components of the system.
So you may actually want to loosen some of the allowed variance in order to achieve quicker synchronicity.
Thinking in Systems is a basic book on systems thinking, and there are a number of graphs in it which show the kinds of unexpected results you can get when you
don’t account for all the components and feedback loops in the entire system.
has some relevant info based on advice from a Microsoft AD RaP.
We have a host system RS6000 that has its own time, so we use that as that as the external time source for AD (PDCe etc).. The reason for that is we have applications that run on Windows servers that perform transactions to that host. Natural domain hierarchy to the downstream 2008R2 or 2012R2 app servers and Win7/8 clients. Naturally our Windows servers have good enough time for AD but the normal drift from w32tm seem to be not quite good enough for our apps.
Thanks for the help
What have you done with w32tm clients, do they keep time tight enough? I assume like we plan to, you have AD sync to that GPS clock, but that still leaves the 'looseness' of your downstream clients on w32time, yes?
Most of our requirement is for applications on Linux servers, because
that's where the logging timestamps are entered - it's a bit less
critical on the Windows workstations.
But, I believe they've worked with the open source time package
NetTime. I don't think it's in wide use, but from what I've seen its
performance has been acceptable.
Ra, I can't find out anything about the clock in the RS6000 so I can't
comment on how accurate it is. My gut feeling is that you'd have a
better experience installing your own time source and having the
RS600, PDCe, and stratum one routers\switches taking their time from
And that’s the problem. W32time was never designed for what you need. It’s irrelevant what the time source is, although important that all time within your
environment is derived from the same source.
High Accuracy W32time Requirements:
Microsecond Resolution Time Services for Windows:
Publishers of Time and Frequency Software:
A couple of years ago I did a lot of research and testing for a mining company that was getting inaccurate data from data mining, collection and merge processes between the trains, trucks, PLCs, etc. I tested many and found that
Meinberg have a freely available pre-compiled Windows binary based on the source from the
NTP project. This seems to be the most flexible and configurable client available. Their NTP-4.2.6p5 "London" release combined with updates from David Taylor at
SatSignal should provide the time accuracy required along with control of clock drift across the Windows servers.
So you only need to roll this out to servers and workstations that require the accuracy needed. No need to roll it out across the whole fleet.
Your source of time is something I would address too, as your RS6000 is not a “reliable” source. You don’t want a time source that
can cause issues like what occurred on 19th November 2012 with the USNO.NAVY.MIL time servers as documented
here. Having said that, ensuring the MaxPosPhaseCorrection and MaxNegPhaseCorrection values are set to 172800 (48 hours) across all servers and workstations will potentially mitigate this. It depends on your size, but I always recommend that if you cannot
get access to Stratum 1 or 2 time sources via the Internet, get some GPS clocks. I’m not a huge fan of the
pool.ntp.org servers for large/enterprise businesses. If you go with GPS clock make sure you get lightning protection, and understand the holdover time requirements and if it will
ever be used for HV (electrical standards require PTP, not NTP). It probably doesn’t for an organisation like yours, but worth understanding. Then you would point your RS6000 to it, your PDCe to it, as well as any clients (Servers and Workstations) running
the Meinberg client.
Lots of info there. Probably too much. I would simply start by testing the Meinberg client with the update from David Taylor from SatSignal, pointing this to your RS6000 and configuring it until you achieve the
accuracy you need. Roll it out to a couple of workstations that run the trading app and see if it helps. The reliable source of time can be a separate project.
The RS runs NTP, so it acts like our time source for AD. However, I was thinking the same as far as a stratum one source. I think though the Windows servers will still be 'loose' since the native w32tm svc is stated in that kb to not be that accurate? I assume we'd have to do something on the server side? 3rd party w32tm replacement?
Excellent info! thanks, I will have to look into that client and a true source. I agree it wouldn't have to be fleet wide as the other members wouldn't need such accuracy and w32tm is fine.
As you know, this is what Microsoft says about the Windows Time Service:
939322 Support boundary to configure the Windows Time service for high-accuracy environments
For accuracy beyond that please consider a third party solution.