Windows Subsystem for Linux for testing Windows 10 PTP Client
Published Apr 03 2019 06:00 AM 50K Views
Microsoft

Hi Folks,

 

Program Manager Dan Cuomo here to chat about setting up one of the most important new features outlined in #10 on our Top 10 Networking features in Windows Server 2019, Precision Time Protocol (PTP).

 

As a quick refresher, you can visualize the benefit of PTP (IEEE 1588v2) by thinking back to the last thunderstorm you experienced.  The further away you are from the lightning, the larger the audible delay in the thunder (you don’t see AND hear at the same time unless you’re very close to the lightning).  This is not just the difference in speed of sound vs the speed of light, but the delay introduced by the environment such as nearby cars and buses, buildings, and many others.PTPthunderstorm.png

 

In timing, latency (delay) is a killer – If you’re in the financial services, video broadcasting, gaming, or numerous other industries you’re painfully aware of this.  As timing is distributed in the network, the accuracy and certainty of that measurement degrades like the sound of the lightning as you move further from the source.

 

PTP is a new (to Windows) time synchronization protocol that helps to remove the noise and asymmetry in the network that reduces the accuracy of a traditional time synchronization protocol. 

PTPSwitch.png

 

One of the challenges customers have is setting up and testing the Windows Client as it requires a time server that can speak PTP; you cannot use an NTP server to speak to a PTP client.  So, in this blog, we’ll show you how to easily setup and test PTP with a linux grandmaster – All on a single physical machine!

 

Disclaimer: These instructions are point-in-time; at the time of writing (3/27/19), these instructions work however future changes to the various components included here might affect your success in the future.

 

Video

Let me first prove this works then you can use the instructions below to try it out yourself!

Instructions

These instructions reference three different locations where you will need to perform an action.

 

Windows 10 Client: This is a Windows 10 version 1809 or later physical host system.  This is the only physical system needed for this exercise.

 

Windows Server 2019 VM: This is a virtual machine installed on the Windows 10 Client and will be the PTPv2 (IEEE 1588v2) subordinate.  In this example we use a Windows Server 2019 system as the PTP subordinate, however a Windows 10 system can also work.  Creating this virtual machine is outside of the scope of these instructions.

 

Ubuntu on WSL: This is a Windows Store app that runs the Windows Subsystem for Linux on the Windows 10 Client and will operate as the PTP Grandmaster.

 

On the Windows 10 Client navigate to our GitHub Repo - In this example we will use the unicast configuration file in this repo.

 

Click on the unicast configuration for PTPd (last one in the list shown below)Annotation 2019-03-31 154900.jpg

 

 

Next, click Raw and copy the contents into notepad and save the file in your preferred location with a .conf extension. In this example, we’ve saved the file to c:\temp\PTPd\PTPdUnicast.conf.  You will later access this file directly, from within the /mnt folder on the Ubuntu on WSL instance.14.jpg

 

Important Note: Please make sure that the file has a blank line at the end of the file

 

Open Hyper-V Manager on your Windows 10 Client and attach the VM to a virtual switch. In this example, we use the default switch however any virtual switch can be used so long as it is not a private virtual switch.4.png

 

In Hyper-V Manager, select the virtual machine and note the assigned IP Address. If you’re not using the default virtual switch, you may need to assign one.5.png

 

Open the Windows Store on the Windows 10 Client and search for Linux or Ubuntu and install the Windows Subsystem for Linux application6.png

 

Once installed, select start and launch Ubuntu7.png

 

Ubuntu on WSL

 

First launch will take a few minutes; please be patient.8.png

 

Enter a username, then a password9.png

 

Run sudo apt-get update.  This updates the packages that are on the system and will require internet access.10.png

 

Run sudo apt-get install ptpd.  This installs the PTP package that will operate as the PTP grandmaster11.png

 

Run ls /mnt. WSL mounts the local file system inside the Ubuntu instance.  c indicates the drive letter that is shared between this WSL Linux system and your Windows 10 client.12.png

 

Next, run ls /mnt/c/temp/PTPd13.png

 

Run ifconfig

ifconfig.png

 

Identify the interface on the same subnet as your Windows Server 2019 VMinterface.png

 

Windows 10 Client

Modify the line ptpengine:interface = eth0 to use the interface identified in the last stepa.png

 

Next modify the ptpengine:unicast_destinations value with the IP address of the Windows Server 2019 VMb.png

 

Ubuntu on WSL

Run sudo ptpd -c /mnt/c/temp/PTPd/PTPdUnicast.conf to start the PTPd grandmaster.c.png

 

Next, run ps -aux | grep ptpd to identify the PID of the PTPd.  If you want to restart PTPd, you use this PID to kill the process.

 

Windows Server 2019 VM

Modify the registry to Configure PTP. This step also disables the VMIC and NTP Client in order to guarantee we’re getting time using the correct provider.

 

This is the IP from Ubuntu on WSL (eth2 in the example above)

Root Key

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient

Type

Name

Value

REG_SZ

PtpMasters

172.17.75.17

REG_DWORD

Enabled

1

REG_DWORD

InputProvider

1

REG_SZ

DllName

"c:\windows\system32\ptpprov.dll"

REG_DWORD

DelayPollInterval

0x3e80

REG_DWORD

AnnounceInterval

0x0fa0

REG_DWORD

EnableMulticastRx

0

Root Key

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

REG_DWORD

Enabled

0

Root Key

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider

REG_DWORD

Enabled

0

 

Next, restart the Windows Time Service and open the PTP ports in the Windows Firewall using an elevated PowerShell prompt.

New-NetFirewallRule -DisplayName 'PTP-319' -Name 'PTP-319' -LocalPort 319 -Direction Inbound -Action Allow -Protocol UDP

 

New-NetFirewallRule -DisplayName 'PTP-320' -Name 'PTP-320' -LocalPort 320 -Direction Inbound -Action Allow -Protocol UDP

Install and Launch Wireshark.  Start a capture and filter using the following filter: udp.port in {319 320}d.png

 

You should see Announce, Sync, and Delay_Req, Delay_Resp messages.e.png

 

Note: Be patient :smiling_face_with_smiling_eyes: You should see Announce and Sync messages immediately however you may need to wait a few minutes to see the Delay_Req and Delay_Resp.  While you’re waiting, you can go on to the next step.

 

Open the Event Viewer > Applications and Services > Microsoft > Windows > Time-Service-PTP-Provider > PTP-Operational.  First verify you see event 512 which will occur once announce messages are received.

f.png

 

Next verify that you receive event 513 which indicates that you have successfully selected the PTP Master as the source of time.g.png

 

 

That’s it!  Now that you’re system has chosen the PTP master, you’re synchronizing time.  You can further verify this by running w32tm /query /status /verbose to verify that the last synchronization was successful.

h.png

 

If you’re trying to test out PTP, you can get your feet wet using the Windows Subsystem for Linux which is a nifty little tool that enables Linux to run natively on Windows.  Obviously this approach will not yield high accuracy however if you’re looking to easily demonstrate the functionality, this might be the easiest approach for you!

 

Thanks for reading,

Dan Cuomo

27 Comments
Copper Contributor

Whats?Whats?


@Dan Cuomo wrote:

Hi Folks,

 

Program Manager Dan Cuomo here to chat about setting up one of the most important new features outlined in #10 on our Top 10 Networking features in Windows Server 2019, Precision Time Protocol (PTP).

 

As a quick refresher, you can visualize the benefit of PTP (IEEE 1588v2) by thinking back to the last thunderstorm you experienced.  The further away you are from the lightning, the larger the audible delay in the thunder (you don’t see AND hear at the same time unless you’re very close to the lightning).  This is not just the difference in speed of sound vs the speed of light, but the delay introduced by the environment such as nearby cars and buses, buildings, and many others.PTPthunderstorm.png

 

In timing, latency (delay) is a killer – If you’re in the financial services, video broadcasting, gaming, or numerous other industries you’re painfully aware of this.  As timing is distributed in the network, the accuracy and certainty of that measurement degrades like the sound of the lightning as you move further from the source.

 

PTP is a new (to Windows) time synchronization protocol that helps to remove the noise and asymmetry in the network that reduces the accuracy of a traditional time synchronization protocol. 

PTPSwitch.png

 

One of the challenges customers have is setting up and testing the Windows Client as it requires a time server that can speak PTP; you cannot use an NTP server to speak to a PTP client.  So, in this blog, we’ll show you how to easily setup and test PTP with a linux grandmaster – All on a single physical machine!

 

Disclaimer: These instructions are point-in-time; at the time of writing (3/27/19), these instructions work however future changes to the various components included here might affect your success in the future.

 

Video

Let me first prove this works then you can use the instructions below to try it out yourself!

Instructions

These instructions reference three different locations where you will need to perform an action.

 

Windows 10 Client: This is a Windows 10 version 1809 or later physical host system.  This is the only physical system needed for this exercise.

 

Windows Server 2019 VM: This is a virtual machine installed on the Windows 10 Client and will be the PTPv2 (IEEE 1588v2) slave.  In this example we use a Windows Server 2019 system as the PTP slave, however a Windows 10 system can also work.  Creating this virtual machine is outside of the scope of these instructions.

 

Ubuntu on WSL: This is a Windows Store app that runs the Windows Subsystem for Linux on the Windows 10 Client and will operate as the PTP Grandmaster.

 

On the Windows 10 Client navigate to our GitHub Repo - In this example we will use the unicast configuration file in this repo.

 

Click on the unicast configuration for PTPd (last one in the list shown below)Annotation 2019-03-31 154900.jpg

 

 

Next, click Raw and copy the contents into notepad and save the file in your preferred location with a .conf extension. In this example, we’ve saved the file to c:\temp\PTPd\PTPdUnicast.conf.  You will later access this file directly, from within the /mnt folder on the Ubuntu on WSL instance.14.jpg

 

Important Note: Please make sure that the file has a blank line at the end of the file

 

Open Hyper-V Manager on your Windows 10 Client and attach the VM to a virtual switch. In this example, we use the default switch however any virtual switch can be used so long as it is not a private virtual switch.4.png

 

In Hyper-V Manager, select the virtual machine and note the assigned IP Address. If you’re not using the default virtual switch, you may need to assign one.5.png

 

Open the Windows Store on the Windows 10 Client and search for Linux or Ubuntu and install the Windows Subsystem for Linux application6.png

 

Once installed, select start and launch Ubuntu7.png

 

Ubuntu on WSL

 

First launch will take a few minutes; please be patient.8.png

 

Enter a username, then a password9.png

 

Run sudo apt-get update.  This updates the packages that are on the system and will require internet access.10.png

 

Run sudo apt-get install ptpd.  This installs the PTP package that will operate as the PTP grandmaster11.png

 

Run ls /mnt. WSL mounts the local file system inside the Ubuntu instance.  c indicates the drive letter that is shared between this WSL Linux system and your Windows 10 client.12.png

 

Next, run ls /mnt/c/temp/PTPd13.png

 

Run ifconfig

ifconfig.png

 

Identify the interface on the same subnet as your Windows Server 2019 VMinterface.png

 

Windows 10 Client

Modify the line ptpengine:interface = eth0 to use the interface identified in the last stepa.png

 

Next modify the ptpengine:unicast_destinations value with the IP address of the Windows Server 2019 VMb.png

 

Ubuntu on WSL

Run sudo ptpd -c /mnt/c/temp/PTPd/PTPdUnicast.conf to start the PTPd grandmaster.c.png

 

Next, run ps -aux | grep ptpd to identify the PID of the PTPd.  If you want to restart PTPd, you use this PID to kill the process.

 

Windows Server 2019 VM

Modify the registry to Configure PTP. This step also disables the VMIC and NTP Client in order to guarantee we’re getting time using the correct provider.

 

This is the IP from Ubuntu on WSL (eth2 in the example above)

Root Key

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient

Type

Name

Value

REG_SZ

PtpMasters

172.17.75.17

REG_DWORD

Enabled

1

REG_DWORD

InputProvider

1

REG_SZ

DllName

"c:\windows\system32\ptpprov.dll"

REG_DWORD

DelayPollInterval

0x3e80

REG_DWORD

AnnounceInterval

0x0fa0

REG_DWORD

EnableMulticastRx

0

Root Key

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

REG_DWORD

Enabled

0

Root Key

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider

REG_DWORD

Enabled

0

 

Next, restart the Windows Time Service and open the PTP ports in the Windows Firewall using an elevated PowerShell prompt.

New-NetFirewallRule -DisplayName 'PTP-319' -Name 'PTP-319' -LocalPort 319 -Direction Inbound -Action Allow -Protocol UDP

 

New-NetFirewallRule -DisplayName 'PTP-320' -Name 'PTP-320' -LocalPort 320 -Direction Inbound -Action Allow -Protocol UDP

Install and Launch Wireshark.  Start a capture and filter using the following filter: udp.port in {319 320}d.png

 

You should see Announce, Sync, and Delay_Req, Delay_Resp messages.e.png

 

Note: Be patient :smiling_face_with_smiling_eyes: You should see Announce and Sync messages immediately however you may need to wait a few minutes to see the Delay_Req and Delay_Resp.  While you’re waiting, you can go on to the next step.

 

Open the Event Viewer > Applications and Services > Microsoft > Windows > Time-Service-PTP-Provider > PTP-Operational.  First verify you see event 512 which will occur once announce messages are received.

f.png

 

Next verify that you receive event 513 which indicates that you have successfully selected the PTP Master as the source of time.g.png

 

 

That’s it!  Now that you’re system has chosen the PTP master, you’re synchronizing time.  You can further verify this by running w32tm /query /status /verbose to verify that the last synchronization was successful.

h.png

 

If you’re trying to test out PTP, you can get your feet wet using the Windows Subsystem for Linux which is a nifty little tool that enables Linux to run natively on Windows.  Obviously this approach will not yield high accuracy however if you’re looking to easily demonstrate the functionality, this might be the easiest approach for you!

 

Thanks for reading,

Dan Cuomo


 

Copper Contributor
Copper Contributor

Hi Dan,

Any chance the ptp domain number becomes configurable within ptpclient?

Thanks,

GP

Microsoft

Hi @pguzli  - We're certainly open to feedback on this, however we don't have immediate plans to modify this.  Could you explain the scenarios you're targeting that requires this?

Copper Contributor

Hi Dan, thank you for your reply. We have been using multiple (actually only two 0,1) ptp domains for timesync on our Linux servers and legacy NTP on Windows servers. It would be nice to be able to use ptp only by accepting domain number 1 multicast messages on Win servers which are in that designated network segment 

Thank you, Peter

Microsoft

@pguzli  - Understood.  So the intent is simply for separation between Windows and Linux servers (or did I misunderstand why you're doing this)?

Copper Contributor

HI Dan, Separation is based on network segments (which reflect geographical location). PTPmasters are each others backups which is why the 2 ptp domains are necessary. Peter

Copper Contributor

Hi Dan. you wrote "Windows 10 system can also work", how can I do this without Windows Server 2019?

Microsoft

Hi @VasiliiNuzhnov - Thanks for reading.  You would perform the same steps on a Windows 10 system as on the 2019 VM.  There's no functional difference between the PTP provider on Client or Server SKUs.  Are you running into an issue in your attempt?

Copper Contributor

Yes @Dan Cuomo , on my Win10(1809) I can't see PtpClient in the registry (only VMIC and NTP).

Microsoft

True for Server as well AFAIK.  You need to create the registry keys.

Copper Contributor

ups

Microsoft

Hi @VasiliiNuzhnov - One more recommendation, please make sure that you're using at least Windows 10 version 1809.  This feature came to Windows 10 in tandem with Windows Server 2019.

Copper Contributor

Hi Dan,I wanna to use PTP client on multicast mode. How do I set window10 registry key? I found there is a key named "EnableMulticastRx" , so I guess ptpClient should support multicast;

Microsoft

Hi @13066012760 - That's correct. Just update the EnableMulticastRx key to 1 and restart the time service.

 

Thanks for reading!

Copper Contributor

Hi Dan. I updata the EnableMulticastRx Key to 1 and restart the time service. When I modify PTPConfig ptpengine:clock_class = 13, win10 PTPClient will not send Delay_Req msg . When I set ptpengine:clock_class below 13, Win10 PTPClient sent Delay_Req msg again. Dose Win10PTPClient will not synic time with clock_class upper than 13?

Another question: I find only I set PTPMaster Mode hybrid or unicast, my win10 PTPClient will work. Dose win10 PTPClient not support PTP Multicast mode ?

When I set PTPMasterMode at multicast, in Wireshark , I only find Announce\Sync\Follow_up\Delay_Req,but no Delay_Resp msg.  I guess win10 set Delay_Req type is unicast ,So PTPMaster will reject to responds. But hybrid mode will accept Delay_Req is unicast ,so it work.

Copper Contributor

Hi @Dan Cuomo, I'm having issues getting this to work. I'm running current ptpd in Docker for Windows (Linux container) on one machine in my local network using the example unicast configuration from Github. My other machine is running Windows 10 Version 1903 with W32Time and is receiving announce messages from the master but rejecting them. The only events I get from PTP-Operational are event 515 stating current configuration. Here is the log output from the slave (w32tm.log_ptpprov):

153049 19:25:48.9301320s - ReadConfig: 'PtpMasters'=192.168.1.7 
153049 19:25:48.9301642s - ReadPtpParametersFromRegistry, ret= 0x00000000
153049 19:25:48.9301867s - InitializeEvents, ret= 0x00000000
153049 19:25:48.9302098s - pwszMastersList:192.168.1.7
delayPollIntervalMsec:16000
announceIntervalMsec:4000announceReceiptTimeoutMsec:12000
bSlaveModeOnly:1bUseTimestamps:0
bAllowAnyMaster:0
bMulticastRxEnabled:0
bUseE2ECorrection:1
153049 19:25:48.9374670s - Iftmstmps disabled
153049 19:25:48.9375564s - Iftmstmps disabled
153049 19:25:48.9376105s - PtpProvider: Created 2 sockets (0 listen-only): [::]:319<0x0>, 0.0.0.0:319<0x0>
153049 19:25:48.9376556s - Iftmstmps disabled
153049 19:25:48.9377178s - Iftmstmps disabled
153049 19:25:48.9377808s - PtpProvider: Created 2 sockets (0 listen-only): [::]:320<0x0>, 0.0.0.0:320<0x0>
153049 19:25:48.9379104s - StartListeningThread completed for event port socket(s)
153049 19:25:48.9379420s - StartListeningThread completed for general port socket(s)
153049 19:25:48.9379628s - IntializePtp, ret= 0x00000000
153049 19:25:48.9379749s - RegisterListenerForSamples(), ret= 0x00000000
153049 19:25:48.9400301s - ListeningThread: StopEvent
153049 19:25:48.9401498s - TeardownPtp(), ret= 0x00000000
153049 19:25:48.9402130s - UnregisterWaitEx ret:0x00000000
153049 19:25:48.9496313s - ReadConfig: 'PtpMasters'=192.168.1.7 
153049 19:25:48.9496669s - ReadPtpParametersFromRegistry, ret= 0x00000000
153049 19:25:48.9496929s - InitializeEvents, ret= 0x00000000
153049 19:25:48.9497063s - pwszMastersList:192.168.1.7
delayPollIntervalMsec:16000
announceIntervalMsec:4000announceReceiptTimeoutMsec:12000
bSlaveModeOnly:1bUseTimestamps:0
bAllowAnyMaster:0
bMulticastRxEnabled:0
bUseE2ECorrection:1
153049 19:25:48.9532085s - Iftmstmps disabled
153049 19:25:48.9532933s - Iftmstmps disabled
153049 19:25:48.9533482s - PtpProvider: Created 2 sockets (0 listen-only): [::]:319<0x0>, 0.0.0.0:319<0x0>
153049 19:25:48.9534009s - Iftmstmps disabled
153049 19:25:48.9534632s - Iftmstmps disabled
153049 19:25:48.9535262s - PtpProvider: Created 2 sockets (0 listen-only): [::]:320<0x0>, 0.0.0.0:320<0x0>
153049 19:25:48.9536653s - StartListeningThread completed for event port socket(s)
153049 19:25:48.9536833s - StartListeningThread completed for general port socket(s)
153049 19:25:48.9536973s - IntializePtp, ret= 0x00000000
153049 19:25:48.9537095s - RegisterListenerForSamples(), ret= 0x00000000
153049 19:25:51.6425689s - ListeningThread -- DataAvailEvent set for socket 1 type 1 (0.0.0.0:320)
153049 19:25:51.6426038s - ListeningThread -- Recvd 64 bytes.
153049 19:25:51.6426133s - ListeningThread -- Received Message From 192.168.1.7:51084 <- 192.168.1.8:320
153049 19:25:51.6426280s - Received general packet of length:64
153049 19:25:51.6426437s - Rx Announce packet ServerTxtimestamp:116444735630000000 ClockId:0x20011FEFFAC4202 PortNum:0x100 SequenceId:297
153049 19:25:51.6426608s - Rejecting peer that is not in the allowed master list. peerIP:192.168.1.7:51084
153049 19:25:51.6430753s - ListeningThread -- DataAvailEvent set for socket 1 type 0 (0.0.0.0:319)
153049 19:25:51.6431165s - ListeningThread -- Recvd 44 bytes.
153049 19:25:51.6431261s - ListeningThread -- Received Message From 192.168.1.7:51085 <- 192.168.1.8:319
153049 19:25:51.6431413s - Received Event Packet of length:44
153049 19:25:51.6432251s - ListeningThread -- DataAvailEvent set for socket 1 type 1 (0.0.0.0:320)
153049 19:25:51.6432506s - ListeningThread -- Recvd 44 bytes.
153049 19:25:51.6432600s - ListeningThread -- Received Message From 192.168.1.7:51084 <- 192.168.1.8:320
153049 19:25:51.6432744s - Received general packet of length:44
153049 19:25:53.2971402s - No clocks qualified as a master clock. MasterCount:0
153049 19:25:55.6425659s - ListeningThread -- DataAvailEvent set for socket 1 type 1 (0.0.0.0:320)
153049 19:25:55.6426120s - ListeningThread -- Recvd 64 bytes.
153049 19:25:55.6426221s - ListeningThread -- Received Message From 192.168.1.7:51084 <- 192.168.1.8:320
153049 19:25:55.6426366s - Received general packet of length:64
153049 19:25:55.6426467s - Rx Announce packet ServerTxtimestamp:116444735630000000 ClockId:0x20011FEFFAC4202 PortNum:0x100 SequenceId:298
153049 19:25:55.6426709s - Rejecting peer that is not in the allowed master list. peerIP:192.168.1.7:51084

One of my concerns is that extra characters often show up in the PtpMasters list fetched from the registry, as shown below. Do you know why this might happen?

153049 19:22:00.4726602s - ReadConfig: 'PtpMasters'=192.168.1.7 
153049 19:22:00.4726925s - ReadPtpParametersFromRegistry, ret= 0x00000000
153049 19:22:00.4727152s - InitializeEvents, ret= 0x00000000
153049 19:22:00.4727380s - pwszMastersList:192.168.1.7
delayPollIntervalMsec:16000
announceIntervalMsec:4000announceReceiptTimeoutMsec:12000
bSlaveModeOnly:1bUseTimestamps:0
bAllowAnyMaster:0
bMulticastRxEnabled:0
bUseE2ECorrection:1
153049 19:22:00.4790711s - Iftmstmps disabled
153049 19:22:00.4791615s - Iftmstmps disabled
153049 19:22:00.4792192s - PtpProvider: Created 2 sockets (0 listen-only): [::]:319<0x0>, 0.0.0.0:319<0x0>
153049 19:22:00.4792648s - Iftmstmps disabled
153049 19:22:00.4793354s - Iftmstmps disabled
153049 19:22:00.4793991s - PtpProvider: Created 2 sockets (0 listen-only): [::]:320<0x0>, 0.0.0.0:320<0x0>
153049 19:22:00.4795526s - StartListeningThread completed for event port socket(s)
153049 19:22:00.4795713s - StartListeningThread completed for general port socket(s)
153049 19:22:00.4795920s - IntializePtp, ret= 0x00000000
153049 19:22:00.4796041s - RegisterListenerForSamples(), ret= 0x00000000
153049 19:22:00.4815898s - ListeningThread: StopEvent
153049 19:22:00.4817522s - TeardownPtp(), ret= 0x00000000
153049 19:22:00.4817943s - UnregisterWaitEx ret:0x00000000
153049 19:22:00.4933334s - ReadConfig: 'PtpMasters'=192.168.1.7 
153049 19:22:00.4933675s - ReadPtpParametersFromRegistry, ret= 0x00000000
153049 19:22:00.4933920s - InitializeEvents, ret= 0x00000000
153049 19:22:00.4934051s - pwszMastersList:192.168.1.7耀
delayPollIntervalMsec:16000
announceIntervalMsec:4000announceReceiptTimeoutMsec:12000
bSlaveModeOnly:1bUseTimestamps:0
bAllowAnyMaster:0
bMulticastRxEnabled:0
bUseE2ECorrection:1
153049 19:22:00.4971654s - Iftmstmps disabled
153049 19:22:00.4972536s - Iftmstmps disabled
153049 19:22:00.4973084s - PtpProvider: Created 2 sockets (0 listen-only): [::]:319<0x0>, 0.0.0.0:319<0x0>
153049 19:22:00.4973527s - Iftmstmps disabled
153049 19:22:00.4974137s - Iftmstmps disabled
153049 19:22:00.4974787s - PtpProvider: Created 2 sockets (0 listen-only): [::]:320<0x0>, 0.0.0.0:320<0x0>
153049 19:22:00.4976451s - StartListeningThread completed for event port socket(s)
153049 19:22:00.4976948s - StartListeningThread completed for general port socket(s)
153049 19:22:00.6391038s - Failed to resolve server: 192.168.1.7耀. Error:0x80072AF9

I'm also wondering how I might set bAllowAnyMaster to true as that should avoid the issue.

 

Also, is there a built-in way to measure the precision of the synchronization once it completes?

 

Here is my w32tm configuration to verify:

C:\WINDOWS\system32>w32tm /query /configuration
[Configuration]
EventLogFlags: 2 (Local)
AnnounceFlags: 10 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 10 (Local)
MaxPollInterval: 15 (Local)
MaxNegPhaseCorrection: 54000 (Local)
MaxPosPhaseCorrection: 54000 (Local)
MaxAllowedPhaseOffset: 1 (Local)
FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 1 (Local)
UpdateInterval: 360000 (Local)
FileLogName: C:\void\logs\w32tm.log (Local)
FileLogEntries: 0-300 (Local)
FileLogSize: 1000000 (Local)
[TimeProviders]
PtpClient (Local)
DllName: c:\windows\system32\ptpprov.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
NtpClient (Local)
DllName: C:\WINDOWS\SYSTEM32\w32time.DLL (Local)
Enabled: 0 (Local)
InputProvider: 1 (Local)
NtpServer (Local)
DllName: C:\WINDOWS\SYSTEM32\w32time.DLL (Local)
Enabled: 0 (Local)
InputProvider: 0 (Local)
VMICTimeProvider (Local)
DllName: C:\WINDOWS\System32\vmictimeprovider.dll (Local)
Enabled: 0 (Local)
InputProvider: 1 (Local)
Copper Contributor

I'm fairly sure the problem was due to the source port on the messages from the server not being 319/320 but instead randomly assigned ports. I tested ptpd on a Linux VM which didn't have this issue and was able to get it working. With the limited networking options for Linux containers in Docker for Windows, I haven't been able to get that setup working. I'd still really like to know if there's a way to set bAllowAnyMaster to true.

Copper Contributor

Hello,

thank you very much for your detailed manual, I also implemented a ptpd2 (2.3.2) daemon in a VM (Grandmaster) and 2 slaves  in WIN10 PC's. It works well on one PC. I got all results you have described, in the Event Viewer as well as in the powershell typing w32tm /query /status /verbose. Both are fresh WIN10 system with WIN10 1909. The second PC with WIN10 I have configured exactly the same, but I have no input in the event viewer an w32tm /query /status /verbose give back that no time data are available.

The firewall is configured. In wireshark the sync message and the announce message is received.

The only difference to your manual: I need to use the ptpd2 (2.3.2) daemon in the VM and i have configured as multicast in the VM daemon (Grandmaster) as well as in the slaves

Where could the time data been blocked? What possibilities do I have for troubleshooting?

 

Copper Contributor

Hi Dan.  In this article, I noticed the feature request for adding ptp domain number to the ptp client configuration.  I was just wondering if the ptp domain configuration had been added since then.  Thanks.

Copper Contributor

Hello @Dan Cuomo  , 

 

I was implementing PTP client server configuration from taking this reference example. 

 

What I am doing exactly is: I have two Windows 10 VM configurations with me, in one of the VM I installed WSL and behave it like a PTP grandmaster (from ptpd command in Ubuntu as the link mentioned). In another VM, I did the PTP client configuration, this is basically to change the HKEY reg setting to behave it like a PTP client.

 

So, after all this setup I am able to see those 512 and 513 events at the PTP client but in the last step when I was synchronizing the clock with the PTP master (which is WSL here in another VM) it shows clock is synchronized to LOCAL CMOS CLOCK because no time data was available.

 

What exactly is the problem, why PTP client is not getting synchronized with PTP master instead of getting events like 512 and 513.

 

Any other suggestions are also welcome of getting the clock offset for two windows machines.

Copper Contributor

Hi @Dan Cuomo 

I am yet another person with request for PTP domain parameter addition. We are working with professional video distribution and in that case ST2110 standard is being used to send media over managed network. PTP is being used there as a master clock to synchronize all packets in the network. According to the ST2059 standard (basically SMPTE PTP profile) default PTP domain is 127 so in that case we have to reach for third party solutions in order to have our Windows machines synced to the PTP clock. I did some tests at our lab and as long as I set domain to 0 in our test network, Windows Time service syncs with PTP clock while all other PTP grandmaster settings are SMPTE compliant. However, for many big organizations changing domain number is simply out of the question. So, broadcast industry would be very grateful if there would be a way to select PTP domain number other than 0.

Copper Contributor

Agreed, the lack of control of the PTP domain is a real show stopper for us in broadcast.  

Copper Contributor

Hi @Dan Cuomo 

 

We are trying to setup a PTP client on on Windows Server 2019 system to a GrandMaster system providing PTP Hybrid Unicast/Multicast profile. We have done all suggested configuration on registry/firewall and verify we receive GM announce/synch messages with a wireshark capture but still fail to connect.

 

Seems that it is long time anyone followed up with answers regarding PTP client support on Windows Systems. Is there anyone we can contact for helping us with the issue? Can you provide/upload here or on GitHub a wireshark trace of successful Hybrid Unicast/Multicast connection?

 

Thanks in advance

Copper Contributor

@Dan Cuomo , who can I contact for support using the PtpClient provider?  

 

I've been evaluating using the ptpprov.dll to synchronize a Windows client to a https://selinc.com/products/2488/.  I'm unable to get Windows to connect with the grandmaster.  In Wireshark I can see the clock sending multicast announce, sync, and follow up messages, but the Windows client never sends a Delay_Req.  When I turn on debug logs using `w32tm /debug /enable /file:C:\users\user\documents\time.log /entries:0-300 /size:10000000` I see this in the log:
No clocks qualified as a master clock. MasterCount:0

Wireshark shows the PTP sync flags are 0x200 and announce flags are 0x003c in my current configuration of our PTP clock. Any help you could offer would be greatly appreciated.

 

- Shane

Copper Contributor

Tips about PowerShell (running as a Administrator):

To reboot Time services:
> stop-service w32time
> start-service w32time

To check Time Configuration:

> w32tm /query /configuration (this will tell you if PTP is the only service enabled)
> w32tm /query /status /verbose (this will tell you when last sync and if it's all set ok)

 

Tips about networking:

- VM and WSL should be in the same network. If dont, you'll never get Delay packets unless you managed to do NAT.

- If you have Windows Home, you won't find Hyper-V. There is a way but you have to dig in.

- At the begging of your test, deactivate windows firewall to execute ping easily. At the end set up Firewall again and add the UDP rules.

- Wait for a minute to receive Delay packets.

 

Options to test easily:

- 1: Use Hyper-V to create a windows VM and a Ubuntu WSL. Both should be configured with the same "Default Switch".  (Wireshark wont work)

- 2: Use your Windows PC as a subordinate and get another machine running linux as a Grand Master (I used Raspberry PI). Both should be in the same LAN net.

 

Copper Contributor

Hi all

 

I don't get it.

It tried everything above with Hyper-V-Manager and virtual Windows 11, virtual Windows Server. I installed Ubuntu 20.4, Ubuntu 22.4. I can start and stop w32tm (with enabled PTPclient). I can start and stop ptpd on Ubuntu. I included the correct IPs in PTPdUnicast.conf and Registry PtpClient. I tried it on two different computers. I doesn't work.

-> I cannot resync w32tm "The computer did not resync because no time data was available."

-> I get one 515 event only.

 

Has someone an idea?

 

Regards

 

 

Version history
Last update:
‎Jul 13 2020 10:00 AM
Updated by: