OK,

Let's just say that I have an NTP subnet that is capable of providing clock=
 synchronization=C2=A0at the 10 millisecond level over long distance WANs, =
and at the 1 millisecond level for LANs for Linux clients.

Sooooo, what level of accuracy would the very same NTP subnet be able to pr=
ovide for Windows Clients?

Thanks,
Ed

Ed,

edstuart@gmail.com wrote:
> OK,
> 
> Let's just say that I have an NTP subnet that is capable of providing clock synchronization at the 10 millisecond level over long distance WANs, and at the 1 millisecond level for LANs for Linux clients.
> 
> Sooooo, what level of accuracy would the very same NTP subnet be able to provide for Windows Clients?

I get the same question regularly from our customers and have put some
general information together:
https://www.meinberg.de/download/burnicki/time_synchronization_accuracy_with_ntp.pdf

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On 19/07/2016 11:30, Martin Burnicki wrote:
> Ed,
>
> edstuart@gmail.com wrote:
>> OK,
>>
>> Let's just say that I have an NTP subnet that is capable of providing clock synchronization at the 10 millisecond level over long distance WANs, and at the 1 millisecond level for LANs for Linux clients.
>>
>> Sooooo, what level of accuracy would the very same NTP subnet be able to provide for Windows Clients?
>
> I get the same question regularly from our customers and have put some
> general information together:
> https://www.meinberg.de/download/burnicki/time_synchronization_accuracy_with_ntp.pdf
>
> Martin
>

Nice summary article, for the next version of that article you really
should add:

Windows 8/8.1
Windows 10

Windows (each measured version) using the built in W32Time service with
appropriate (non-default) settings.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Jakob Bohm wrote:
> On 19/07/2016 11:30, Martin Burnicki wrote:
>> Ed,
>>
>> edstuart@gmail.com wrote:
>>> OK,
>>>
>>> Let's just say that I have an NTP subnet that is capable of providing
>>> clock synchronization at the 10 millisecond level over long distance
>>> WANs, and at the 1 millisecond level for LANs for Linux clients.
>>>
>>> Sooooo, what level of accuracy would the very same NTP subnet be able
>>> to provide for Windows Clients?
>>
>> I get the same question regularly from our customers and have put some
>> general information together:
>> https://www.meinberg.de/download/burnicki/time_synchronization_accuracy_with_ntp.pdf
>>
>>
>> Martin
>>
> 
> Nice summary article,

Thanks.

> for the next version of that article you really
> should add:
> 
> Windows 8/8.1
> Windows 10

Agreed.

We at Meinberg are selling NTP and PTP servers, and we often get
questions from customers on the accuracy we can *guarantee* at the
client side. I always tell that you can't guarantee a certain accuracy,
and try to explain why.

So I just recently updated the information in the PDF for a customer,
and I only had the measurements with Windows 7 / XP handy to show how
different parameters and software versions affect the timekeeping under
Windows, and I thought I could share it here.

> Windows (each measured version) using the built in W32Time service with
> appropriate (non-default) settings.

I've played around with w32time quite some time ago, and a colleague
even tried to put a table together which summarizes the peculiarities of
each w32time version. However, he finally gave up because there were too
many variations in the observations.

So I don't think I'll spend much time on w32time. ;-)


Cheers,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On 2016-07-19, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
> Jakob Bohm wrote:
>> Windows (each measured version) using the built in W32Time service with
>> appropriate (non-default) settings.
>
> I've played around with w32time quite some time ago, and a colleague
> even tried to put a table together which summarizes the peculiarities of
> each w32time version. However, he finally gave up because there were too
> many variations in the observations.

Does anyone know in what NTP version are packets from w32time in latest
Windows versions? Is it still NTPv3? The reason I'm asking is detection
of MS-SNTP authentication data. If anyone would be willing to share a
packet dump or tcpdump -v -v output, I'd be grateful.

-- 
Miroslav Lichvar

Miroslav Lichvar wrote:
> On 2016-07-19, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
>> Jakob Bohm wrote:
>>> Windows (each measured version) using the built in W32Time service with
>>> appropriate (non-default) settings.
>>
>> I've played around with w32time quite some time ago, and a colleague
>> even tried to put a table together which summarizes the peculiarities of
>> each w32time version. However, he finally gave up because there were too
>> many variations in the observations.
> 
> Does anyone know in what NTP version are packets from w32time in latest
> Windows versions? Is it still NTPv3? The reason I'm asking is detection
> of MS-SNTP authentication data. If anyone would be willing to share a
> packet dump or tcpdump -v -v output, I'd be grateful.

I've sent a wireshark trace from Windows 10's w32time by email.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On 2016-07-19, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
> Miroslav Lichvar wrote:
>> Does anyone know in what NTP version are packets from w32time in latest
>> Windows versions? Is it still NTPv3? The reason I'm asking is detection
>> of MS-SNTP authentication data. If anyone would be willing to share a
>> packet dump or tcpdump -v -v output, I'd be grateful.
>
> I've sent a wireshark trace from Windows 10's w32time by email.

Thank you, Martin. It seems it uses NTPv3 and the new
ExtendedAuthenticator field (120-byte packets). This is good news as
it nicely avoids ambiguity in parsing of NTPv4 extension fields.

-- 
Miroslav Lichvar