PTP synchronization on Windows 10 and Intel i210

Question

Dear support, I would like to synchronize my PC running Windows 10 Enterprise LTSC v.1809 OS Build 17763.8511 using PTP. The PTP master source is a GNSS receiver that will be directly connected via LAN to an Intel i210 network interface.

However, in the network adapter settings and in the Windows W32Time registry keys, there is no option to use PTP as a time provider. How can I resolve this?

I remain available to provide any additional information if needed.

Kind regards,

Francesco

Answer 1

Hi Francesco S,

How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VP

Answer 2

Francesco S

The service failure you are experiencing is entirely expected under these specific conditions. Error 3534 indicates that the ptpprov.dll library encountered a fatal exception during its initialization routine. Upon startup, the Windows Time service provider immediately queries the Windows IP Helper and NDIS APIs for any network adapters declaring IEEE 1588 hardware timestamping capabilities. If the operating system returns no compatible interfaces, the PTP provider fails to initialize, which subsequently causes the entire W32Time service to abort before any network traffic is ever processed. This confirms your suspicion that the interaction between the DLL and the network driver is failing at the hardware discovery phase.

Regarding the Intel i210, the hardware fully supports Precision Time Protocol, but simply installing the official PROSet driver is insufficient. The driver natively hides and disables the required NDIS packet timestamping hooks by default. To expose these capabilities to Windows 10 version 1809, you must manually inject the standardized NDIS registry keywords into the network adapter's configuration. You will need to locate your specific adapter's instance under the network class registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4d36e972-e325-11ce-bfc1-08002be10318} and create the string values *PtpHardwareTimestamp and *SoftwareTimestamp, setting both to 1. Once these keywords are present and the adapter is restarted, PowerShell's Get-NetAdapterAdvancedProperty command will successfully report the capabilities, allowing ptpprov.dll to initialize without crashing W32Time.

About your remaining questions, there is no requirement to manually bind the PTP provider to a specific network interface index or GUID. The Windows Time stack handles this dynamically, automatically attaching to any active interface that reports the requisite NDIS timestamp capabilities during the startup query. Finally, Windows 10 Enterprise LTSC 1809 fully supports this implementation with the Intel i210, but because version 1809 was the foundational release for native Windows PTP, the architecture is exceptionally rigid. It possesses zero tolerance for missing driver hooks and requires strict compliance with the NDIS capability reporting, meaning the service will always refuse to start until those specific adapter registry keys are explicitly defined.

Hope this helps :)

VP

Answer 3

Hi Francesco S,

The behavior you are observing occurs because while Windows 10 version 1809 introduced native Precision Time Protocol support, the configuration interface and registry keys are often omitted by default on client editions like LTSC. To successfully synchronize, your GNSS receiver must be strictly configured to match the Windows PTP client network requirements. It must broadcast Precision Time Protocol version 2 over IPv4 using UDP ports 319 and 320. Furthermore, Windows exclusively supports the End-to-End delay measurement mechanism. If your master clock is set to Peer-to-Peer delay measurement or broadcasts directly over raw Ethernet at Layer 2, the Windows network stack will silently drop the packets.

To resolve the missing configuration, you must manually register the PTP provider library into the Windows Time service. Open the Registry Editor as an administrator and navigate to the TimeProviders key located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders. You will need to create a new subkey named PtpClient to serve as the container for your instructions. Inside this new key, create a DWORD value named Enabled and set it to 1, create another DWORD value named InputProvider and set it to 1, and finally create an Expandable String Value named DllName with the data %SystemRoot%\System32\ptpprov.dll.

Once the registry is prepared, you must instruct the operating system to apply these changes. Open an elevated Command Prompt and execute the command net stop w32time followed by net start w32time to restart the time service. You can then confirm the integration was successful by running the command w32tm /query /providers, which should now list PtpClient as an active input provider. Finally, ensure your Intel i210 network adapter is running the full Intel PROSet driver package rather than generic Windows Update drivers. The dedicated Intel drivers are strictly required to expose the NDIS packet timestamping hooks that bridge the hardware capabilities to the Windows 1809 time stack for accurate synchronization.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

Answer 4

Windows 10 Enterprise LTSC 1809 can participate in PTP-based time synchronization, but only within the scope of the PTP features introduced with Windows Server 2019 / Windows 10 (version 1809). There is no separate “PTP” provider entry in the classic W32Time registry configuration, and PTP over raw Ethernet is not supported.

Key points and limitations:

1. PTP transport and mode
   • Windows PTP support is scoped to Precision Time Protocol version 2 (PTPv2) over UDP only; PTP over raw Ethernet frames is not supported.
   • Supported operation is PTPv2 in 2‑step mode, where timestamps are retrieved from hardware and conveyed in follow‑up messages rather than being inserted on the fly in hardware.
2. NIC and timestamping support
   • The Intel i210 must expose hardware timestamping capabilities to Windows via NDIS packet timestamping.
   • NDIS packet timestamping and the IP Helper packet timestamping APIs allow:
     • Discovery of the NIC’s timestamping capabilities.
     • Association of NIC hardware timestamps with PTPv2-over-UDP traffic (e.g., ports 319/320).
     • Use of the NIC’s hardware clock as a free‑running clock and generation of cross‑timestamps between NIC and system clocks.
   • Hardware and software timestamping cannot be enabled simultaneously; only one mode is supported at a time.
3. Windows time service and PTP
   • A new time provider in Windows Server 2019 and Windows 10 (version 1809) allows time synchronization using PTP, improving accuracy by accounting for per‑hop latency.
   • This provider is integrated into the Windows time stack; it does not appear as a separate, user‑selectable “PTP” provider in the W32Time registry in the same way as traditional NTP settings.
   • PTP support is intended primarily for enterprise/IT scenarios where PTPv2 over UDP is deployed and where NIC drivers implement NDIS packet timestamping.
4. Application-level integration
   • For custom or third‑party PTP clients, Windows exposes packet timestamping via:
     • IP Helper packet timestamping APIs to query adapter capabilities and cross‑timestamps.
     • Winsock timestamping support to consume timestamps associated with PTPv2 packets.
   • A PTPv2 client application can use these APIs to achieve high‑accuracy synchronization with a GNSS‑disciplined PTP master, provided the NIC and driver support hardware timestamping.

In practice, to synchronize a Windows 10 Enterprise LTSC 1809 system with a GNSS PTP master over an Intel i210:

• Ensure the i210 driver supports NDIS packet timestamping and PTPv2 over UDP (2‑step mode).
• Deploy or configure a PTPv2 client that uses Windows packet timestamping (IP Helper + Winsock timestamping) to talk to the GNSS PTP master on UDP ports 319/320.
• Do not expect a visible “PTP” toggle in the adapter UI or a distinct PTP provider entry in W32Time; PTP support is provided through the newer time provider and timestamping APIs rather than classic W32Time registry options.

---

References:

• Insider preview
• Overview of NDIS packet timestamping
• Packet timestamping