No synchronization using PTP on a Windows 10 machine
PatrickNowak opened this issue · 14 comments
Hi,
I am currently trying to configure my Windows 10 machine as a PTP slave for my PTP Grand Master on a Linux machine using linuxptp. For this purpose I am following this validation guide: https://aka.ms/PTPValidation
- Configured NTP and PTP service in Registry
- Restarting W32Time service
- Executing 'w32tm /resync' on command line with the following output:
C:\Windows\system32>w32tm /resync Sending resync command to local computer The computer did not resync because no time data was available.
The event log shows the following messages, although this message is over eight hours old, there are currently not appearing new messages here as I restart the W32Time service
The PTP provider is available:
This is the query information from the w32tm CLI tool:
I've also evaluated the PTP Announce message from the grand master using Wireshark:
Can anyone help me investigate this further? I am currently at a loss.
Best regards,
Patrick
Hi,
I've looked further into this today. There seems to be no PTP communication from the windows slave whatsoever visible in Wireshark. Is this normal behaviour? Is the slave/client only listening to PTP messages from the configured PTP-Master(s)?
Best regards,
Patrick
The same issue I can observe running ptp4l server on Linux in the network; Other linux client devices can conenct to the server and synchronize, but Windows doesn't;
Any help with it?
@dcuomo thank you for following up!
It seems that github issues are monitored after all!
Would you provide a guideline how to use GM ptp4l that has correct values in announcement [ that can be seen with wiireshark], please? but then it gets into a mess with frequent sync packets , but with w32tm /resync not working?
Did you try enabling EnableMulticastRX? But I'm having the same issue on Server 2019 and can see the traffic, but the time isn't syncing.
@ferrie-One15
enabling MulticastRX on linux server? on windows client? at both? at neither of the two?
On the Windows client, the announce destination address you shown is a multicast address.
Also, the announce and delay intervals need to match the grand-master configuration, for example on Cisco IE switches, the defaults are 1000 (0x3e8) for the announce and 5000 (0x1388) for the delay.
hi, all
I meet the same problem here, I had already enabled MulticastRX on the Windows client
the event log shows below:
But w32tm /resync is failed
I am confused with that, I followed every step as it required.
Does anyone know the reason?
yes, also tried enabling the multicast RX.
The difference seems that there is unicast [ server "broadcasts" to listed computers only], also multicast [ server doesn't broadcast to any specific ip address, but to all computers in the network. However, the issue there might be in some other arguments & parameters;
Which works is the ptpd solution proposed by microsoft that uses provided configuration file,
but we are using ptp4l in our network so it requires different configuration/setup as it is different software package by different maintainers
Yes, I found that in
https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/how-the-windows-time-service-works#windows-time-service-time-protocols
The Windows Time service synchronizes time between computers within the hierarchy, with the most accurate reference clocks at the top. If more than one time source is configured on a computer, Windows Time uses NTP algorithms to select the best time source from the configured sources based on the computer's ability to synchronize with that time source. T**he Windows Time service does not support network synchronization from broadcast or multicast peers.**
I think multicast may not be supported?
I also use ptp4l tools, because ptpd doesn't support hardware timestamp
Here same problem.
I see Announce Messages, Follow_Up messages and Sync messages at client side using Wireshark
For example:
4839 190.165019 146.122.36.248 10.146.251.160 PTPv2 106 Announce Message
Frame 4839: 106 bytes on wire (848 bits), 106 bytes captured (848 bits) on interface \Device\NPF_{3E540252-158A-4F20-8E06-68316A131D10}, id 0
Ethernet II, Src: 02:00:0a:92:fb:a0 (02:00:0a:92:fb:a0), Dst: MS-NLB-PhysServer-05_85:7f:eb:80 (02:05:85:7f:eb:80)
Internet Protocol Version 4, Src: 146.122.36.248, Dst: 10.146.251.160
User Datagram Protocol, Src Port: 62870, Dst Port: 320
Precision Time Protocol (IEEE1588)
0000 .... = transportSpecific: 0x0
.... 1011 = messageId: Announce Message (0xb)
0000 .... = Reserved: 0
.... 0010 = versionPTP: 2
messageLength: 64
subdomainNumber: 0
Reserved: 0
flags: 0x040c
0... .... .... .... = PTP_SECURITY: False
.0.. .... .... .... = PTP profile Specific 2: False
..0. .... .... .... = PTP profile Specific 1: False
.... .1.. .... .... = PTP_UNICAST: True
.... ..0. .... .... = PTP_TWO_STEP: False
.... ...0 .... .... = PTP_ALTERNATE_MASTER: False
.... .... ..0. .... = FREQUENCY_TRACEABLE: False
.... .... ...0 .... = TIME_TRACEABLE: False
.... .... .... 1... = PTP_TIMESCALE: True
.... .... .... .1.. = PTP_UTC_REASONABLE: True
.... .... .... ..0. = PTP_LI_59: False
.... .... .... ...0 = PTP_LI_61: False
correction: 0.000000 nanoseconds
Reserved: 0
ClockIdentity: 0x00155dfffe0de79e
SourcePortID: 1
sequenceId: 30
control: Other Message (5)
logMessagePeriod: 127
originTimestamp (seconds): 0
originTimestamp (nanoseconds): 0
originCurrentUTCOffset: 37
priority1: 120
grandmasterClockClass: 10
grandmasterClockAccuracy: The time is accurate to within 1 us (0x23)
grandmasterClockVariance: 28768
priority2: 125
grandmasterClockIdentity: 0x00155dfffe0de79e
localStepsRemoved: 0
TimeSource: INTERNAL_OSCILLATOR (0xa0)
In the registry at client side I have:
PtpMasters 146.122.36.248 192.168.83.141
All other registry keys are from https://github.com/microsoft/W32Time/blob/master/Precision%20Time%20Protocol/Windows%20Configuration%20Helpers/PTPClientConfig.txt
I restarted the service and ran w32tm /config /update
and I get these results for different commands:
w32tm /query /configuration
[Configuration]
EventLogFlags: 2 (Local)
AnnounceFlags: 0 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 10 (Local)
MaxPollInterval: 15 (Local)
MaxNegPhaseCorrection: 4294967295 (Local)
MaxPosPhaseCorrection: 4294967295 (Local)
MaxAllowedPhaseOffset: 300 (Local)
FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 1 (Local)
UpdateInterval: 30000 (Local)
[TimeProviders]
PtpClient (Local)
DllName: c:\windows\system32\ptpprov.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
Windows Time Agent (Local)
DllName: w32tmdt.cpl (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
NtpClient (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 0 (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)
w32tm /resync
Sending resync command to local computer
The computer did not resync because no time data was available.
w32tm /query /status /verbose
Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0000000s
Root Dispersion: 0.0000000s
ReferenceId: 0x00000000 (unspecified)
Last Successful Sync Time: unspecified
Source: Local CMOS Clock
Poll Interval: 10 (1024s)
Phase Offset: 0.0000000s
ClockRate: 0.0156250s
State Machine: 0 (Unset)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 1 (The computer did not resync because no time data was available.)
Time since Last Good Sync Time: 332.5131215s
The problem is that Windows PTP client sends out Delay_Req as unicast to the IP address from which PTP Sync and Follow_Up packets have been received. However, in many devices like Cisco switches and professional Grandmaster clocks, that IP address is only a virtual one, used as sender source address. There is nobody listening at that IP address nor replying to ARP requests. So in Wireshark you will only see the ARP request going out for that IP address without any reply. That is why the Delay_Req unicast UDP packet cannot be sent out by the IP stack (MAC address unknown) and is therefore not visible in Wireshark although the PTP client ist trying to send out that packet. In the PTP logfile, one can see that the PTP client cannot get the TX timestamp for the Delay_Req unicast UDP packet. That is because that packet never gets sent out because of not being able to resolve the ARP.
You can try pinging the IP of your PTP. The address that in Wireshark is displayed as the source IP for Sync and Follow_Up packets. In most cases ping will not work and arp -a will not show any entry for that IP address.
The only solution to this is that Microsofts makes it possible to configure that Delay_Req packets will be sent to the PTP multicast address instead of sending them as unicast to the IP address from which the Sync and Follow_Up packets have been received.
As many have seen above, a huge amount of PTP equipment simply does not support unicast Delay_Req packets, unfortunately making the Windows implementation of PTP quite useless in professional environments for the moment. The missing setting for the PTP domain number is the other show stopper. There are many existing environments that use a non zero PTP domain number which can simply not be changed to zero domain number. And there is practically no network equipment supporting more than one PTP domain in the same network.
EDIT: Just discovered that Windows 11 and Server 2022 have a new undocumented possibility in w32tm:
w32tm /ptp_monitor /duration:10
This will also display PTP parameters that can be set in the registry. The important ones which are not available under Windows 10 are:
EnableMulticastTx:1
DomainNumber:127
Setting those two to correct values should enable use of PTP without the problems described above. It looks like Microsoft is slowly dropping the PTP support for Windows 10 and Server 2019. At least many APIs for timestamping and similar have been modified in a non-compatible way and are documented as being available from Windows 11 / Server 2022 upwards only. And the PTP functionality is still widely undocumented even for Windows 11 / Server 2022.