PTPd on Windows

[Niels Hornung]

Hello,
this topic has been discussed extensively but at the moment how hard is it to port this protocol to windows? I know windows has pretty bad timestamp mechanics, but maybe i need to port it for my work. I have very little experience in windows programming (came fresh from the university). I already tested this protocol on my Raspberry pis with great success with an accuracy of +-25 us.

[Wojciech Owczarek]

Hi Niels,

Firstly, just to get this out of the way, Windows, as you say, is not a good platform for timing.

A Windows port of ptpd should be made easy once the modular transport and clock driver code is in place with ptpd, but it is probably mostly possible now using a toolchain like mingw-w64, with some exceptions.

Main points:

1. Windows provides no packet timestamping. There are no socket options like SO_TIMESTAMP. This can be worked around using libpcap / winPcap which ptpd already supports. Because there is no native packet timestamping mechanism and no kernel API for precise clocks, to my knowledge no NIC drivers provide a standard way to access hardware timestamping either.
2. Time adjustment functions like adjtime() and ntp_adjtime() have not been ported to the POSIX toolchains like cygwin or mingw-w64. Some equivalent should be written using native Windows API. The existing Windows clock adjustment function can only adjust by increments of 100 nanoseconds and due to some bug (see note here), on some Windows platforms, adjustments below 16 units will be ignored.
3. PTPd is a UNIX daemon. It will run on Windows, but it's not fully suitable as a Windows service as is. It uses flat text files for configuration, status output and logs. To be really usable it should run as a system service, and ideally at least some minimal GUI tool should be written to allow reloading configuration, maybe editing configuration, and displaying status.

There is currently a Windows PTP client for Windows, Domain Time II, which is a commercial product.

You are most welcome to give it a try and work on a Windows port, if you have a patch ready, we can take it apart and merge it with ptpd code.

I would suggest to look into the following:

• set up a mingw-w64 environment up to a point where you can attempt compiling ptpd
• get WinPcap working with mingw
• get familiar with GNU Autotools as you will likely need to make changes to library and header detection. Look at configure.ac, Makefile.in and the m4/ directory in ptpd code tree.
• attempt at implementing adjtime(), or actually better adjfreq() using SetSystemTimeAdjustment()
• maybe get in touch with Martin Burnicki who has been maintaining a Windows port of ntpd for Meinberg. He has a lot of experience with Windows timing (he knows all the horrors of it).

Hope this helps,

thanks,
Wojciech

[Jan Breuer]

Hello,
I did some work in this but it does not work well. It is not a service but simple console application. Here is my 3 years old port of version 2.0.0
https://github.com/j123b567/ptpd/tree/windows
You can take some inspiration for porting new version in files
https://github.com/j123b567/ptpd/blob/windows/src/dep/sys_win32.c
https://github.com/j123b567/ptpd/blob/windows/src/dep/net_win32.c

It is not possible to use WinPcap, because it uses its own time scale from the time you initialize it. There is no way to synchronize between system time and Pcap time. It is also not possible to adjust Pcap timescale. WinPcap also use different timescale for every application using it. Some patches to WinPcap can solve this, but currently it is no go.

Jan

[Wojciech Owczarek]

I knew somebody had made a win32 port! :)

Shame about WinPcap, that was my only hope.

[Wojciech Owczarek]

Well, maybe there is some hope after all, there are some options here:

http://seclists.org/wireshark/2010/Aug/311

Still far from perfect, but could be exlored. Still, you'll probably get bether results with ntpd on Windows.

[Jan Breuer]

This is possible, but this will affect all applications using WinPcap and the precision 15 ms is far from perfect.

[Niels Hornung]

Thanks for the response, i have to learn a lot first. So i will try it later. I really appreciate the support from you guys. It doesnt really has to be precise i just want to show, that windows is not suited for the task.

[Wojciech Owczarek]

Well I can tell you now: Windows is not suited for the task :D

You can look at Martin Burnicki's great document about timing - chapter 12 tells you what you can come across when working with Windows.

[Jan Breuer]

Nice reading! Maybe, Windows 8 and 10 can be good enough.

[Niels Hornung]

Thanks again, what about the new windows function getSystemTimePreciseAsFileTime. maybe this could improve the accuracy. In the ntp forum lots of people noticed improvements from ms to us with ntp.

edit: I see the Embedded PC has an Intel 82579LM wich is PTP compatible, but till now ptpd has no implementation of hardware support am i right? so if im porting it with hardware timestamping this would be pretty hard :/

edit2: I phoned with real time systems and it seems that the 82579LM has a hardware failure which reduces the accuracy and therefore is not suited for the task. The new i211 is the better solution. Just wanted to let you guys know and save you some trouble if you try to implement HW-Timestamping in the future