As I said, Windows is huge and evolving, and Sever is different from
regular Windows versions; be careful when mixing and matching versions.
Some of these technotes are pretty recent, like 2014 or 2015. See -
How to configure an authoritative time server in Windows Server
https://support.microsoft.com/en-us/kb/816042
How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx
Support boundary to configure the Windows Time service for high-accuracy
environments
https://support.microsoft.com/en-us/kb/939322
Domain Controller Roles
https://technet.microsoft.com/en-us/library/cc786438(v=ws.10).aspx
Windows Time Service Technical Reference
https://technet.microsoft.com/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-time-service
Kerberos (protocol)
https://en.wikipedia.org/wiki/Kerberos_(protocol)
"Kerberos has strict time requirements, which means the clocks of the
involved hosts must be synchronized within configured limits. The
tickets have a time availability period and if the host clock is not
synchronized with the Kerberos server clock, the authentication will fail."
-Brooks
On 2017-01-08 12:59 PM, Brooks Harris wrote:
On 2017-01-08 10:15 AM, Martin Burnicki wrote:
Brooks Harris wrote:
On 2017-01-06 11:52 AM, Martin Burnicki wrote:
- OS kernels with different features (Windows doesn't even know leap
seconds, AFAIK)
It is often repeated on LEAPSECS that "Windows doesn't even know leap
seconds". That's just not true. It knows very well about Leap
Seconds in
the same way other systems do but it (typical desktop versions) is lazy
about when it updates - it doesn't attempt to update for Leap Seconds
until the particular system gets round to syncing to some NTP server
(defaulting to time.windows.com, but works perfectly well if set to
time.nist.gov, for example).
Many years ago I wrote a DOS TSR which could read the time from Meinberg
PCI cards (and ISA cards at that time), and adjusted the DOS time if
there was a significant difference.
So of course the DOS time was also adjusted after the plug-in card had
stepped its time due to a leap second.
So according to your argumentation even plain old DOS was aware of leap
seconds, wasn't it?
Yeah, I think so.
Really, none of DOS, Windows, or (pure) POSIX systems "know" about
Leap Seconds except in so far as the reference counter (Windows
FILETIME or POSIX time_t, (I can't remember what counter DOS relied
on)) has been adjusted by the system in response to NTP queries. That
adjustment gets reflected to YMDhms representation through calls to
win::GetSystemTime() or POSIX::gmtime(). (Again, long time since I
played with DOS, not sure the analogous calls)
By the way, DOS was essentially a real-time OS; you could hammer the
interrupts however you liked. You don't want to do that in a
multitasking event driven OS.
In Windows, FILETIME (an unsigned 64-bit value) is directly
analogous to
POSIX time_t except it has a 1601-01-01 00:00:00 epoch. struct
SYSTEMTIME is analogous to POSIX struct tm ("broken down time" or
"YMDhms" representation). FileTimeToSystemTime() is analogous to POSIX
gmtime();
Like time_t, FILETIME is "bumped" when the system syncs to a NTP
server.
Yes because the time adjustment software slews or steps the time.
Which Windows API call can be used to notify Windows that a leap second
is pending, so the Windows system time can account for it at the
right time?
I am unaware of any part of Windows that is "aware" of Leap Seconds.
There's no register somewhere that holds current TAI-UTC, announce, or
history, I'm pretty sure, not at user-level access to the OS system
calls, anyway.
(I'm hesitant to state this with great authority because Windows as a
whole is just huge, and there are APIs on APIs developed and exposed
over the years. I keep discovering yet another API that may expose
deeper and deeper access to stuff. There might be something buried
somewhere that can do this somehow. And Windows is always evolving, so
something new might exist. Windows Server is something of a different
animal than regular Windows PC versions, certainly with respect to its
file system support, so there might be something different there
regarding timekeeping, I don't know. I've never seen documentation of
any such thing, though.)
Combinations of SetSystemTime() and SetSystemTimeAdjustment() can
adjust the system clock. I've never tried to use them to tightly
adjust system time. It would probably not be an easy project because
monitoring accurate cause and effect would be tricky. I've played with
SetSystemTimeAdjustment(), and it definitely changes things a bit, but
never explored it carefully. But SetSystemTime() certainly works in
the context of setting values obtained from NTP.
These functions adjust the "System timer" which is responsible for
user-level FILETIME values and such. This is not the the primary CPU
clock, of course, which you'd dearly love to frequency lock to an
outside time source, but I know of no OS level call to do that. Of
course you could build a driver in ring-zero to give it a go, which
would be fun, but not a weekend project. :-) (Recommendation: do not
try anything with interrupts unless you are fond of blue-screens.)
I have never discovered any references to or documentation of exactly
how Windows synchronizes with NTP. Its a black box. (Any tips on this
appreciated). But from everything I've been able to observe and
experiment with it behaves the same as running an NTP client
application and using SetSystemTime() from the NTP results. That works
fine, but I've never tried to critically evaluate just how tightly
this can be done.
As you probably know, some aspects of the clock and timer behavior
depend on the CPU model, BIOS, associated chip sets, and the Windows
power-management scheme in use by a given installation, of which there
are many from different Windows versions to support available hardware
technology on a given system. For example, the minimum (average) sleep
time available from ::Sleep() can vary from, like from 10 to 14
Milliseconds and higher on different systems. I've tested and verified
that. (Recommendation: never use ::Sleep() for anything; you've gotta
do it the hard way with thread synchronization mechanisms).
Most of my experience regarding tight timekeeping in Windows revolves
around obtaining media (video and audio) and device control (things
like VTR (video tape recorder) control) from external sources,
displaying those locally or over networks, or emitting media and
control to external devices. None of this is easy. Windows is not a
real-time OS; you have to repeat that mantra. Everything needs to be
buffered. Windows provides many OS systems calls, low-level
interfaces, and APIs for dealing with threading, media, and serial
communications. There are several "multi-media" clocks and APIs to
chose from, including high level APIs like DirectShow. Then there are
all the third-party media systems like Quicktime and Ffmpeg and a
bunch of others. Then too there is the whole other world of .NET.
Generally speaking these sorts of applications don't require
high-precision accurate date-and-time. But the new SMPTE focus on a
*fixed* date-time epoch (1588/PTP) timing scheme is what came to drive
my interest in this broader discussion.
-Brooks
Martin
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
