[LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Mon Jan 9 20:32:43 EST 2017

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 at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>