First post here, but I've been working with the daemon for 3 months now. I'm just now getting around to looking at testing on different systems and I've never ported a piece of software before. I'm looking to use the windows port that is available on this site. Is anyone willing to give me a quick rundown on how to do it?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
- it can compile only by MinGW, no MSVC support yet.
- running PTPd as windows service is NOT supported as well as logging to system log
- there is prepared project for code:blocks and makefile
- if you want just passive mode, just remove -DPCAP and -lwpcap from makefile or codeblocks project and run PTPD with appropriate switches
- if you want more precise timestamps, you have to install WinPCAP and its development packages for windows and after that compile ptpd.
About WinPCAP:
Windows itself does not provide timestamps of packets like linux. If you want timestamp, you can just save actual time in the appropriate function and this is not precise (it can't be precise more then few mili seconds). WinPCAP can help it little bit, because it saves timestamp at driver level. For the future, WinPCAP should be solution also for Layer 2 ethernet mode for PTPd, because windows can't send custom layer 2 packets without additional driver.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I completely failed in trying to compile ptpd for Windows via mingw.
As in ptpd.h there is inclusion of sys/resource.h, sys/timex.h, sys/socket.h, syslog.h, etc. the build under mingw fails, because the files are not there.
So how did you ever compile it with mingw?
Any hint highly appreciated.
Regards
Axel
PS: I used 2.2.0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Windows port is not part of official PTPd. It is available as set of patches. The functionality of windows port is incomplete and it does not currently work with PCAP and slave mode. Slave mode without PCAP can work, but it is not precise (error about 10ms).
Regards,
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for your reply. Where can I find the patches?
Slave mode would be most interesting (who wants to run a master under Windows? ;-)
10ms isn't really "precise" anymore, but never mind, I'm mainly interested in learning from the project and perhaps I could help to improve the situation on Windows.
Cheers
Axel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please note the page above mentions a parameter "LPFILETIME *lpSystemTimeAsFileTime". This is wrong since LPFILETIME is already a pointer. I've already submitted a bug report to some MS guys who have confirmed that the calling parameters are the same as for the older GetSystemTimeAsFileTime() API, so an application can use a function pointer which is set to the new API call if the function can be imported at program startup, and fall back to the older call otherwise.
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The final limiting factor for windows implementation is precision of packet timestamp. Getting packet timestamp at application level is late for precise implementation. Or am I misunderstood something?
Regards,
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The final limiting factor for windows implementation is precision of packet timestamp. Getting packet timestamp at application level is late for precise implementation. Or am I misunderstood something?
Of course you are right.
I've played around a little bit with the new API call in an own tiny test program, and the results really look good, so the implementation of the system clock seems to be much better than in earlier Windows versions.
I'm pretty sure there is an equivalent call in kernel mode, and I'm expecting MS themselves will use this in their drivers to benefit from the new high precision timekeeping. If they have high resolution time I'm sure they finally also want the time to be accurate.
For example, for GPS PCI card drivers I'm maintaining the availability of this API call in kernel mode will be sufficient to yield high accuracy.
I'm pretty sure there will also be timestamping support in Windows NIC drivers, but the question is whether these API calls will be published by MS.
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Jan: Thanks a lot for the linkt to your patches. I downloaded them and am currently struggling to apply them. Please forgive me for my naivety: How do I find out what was the orognial version? I saw that the patches were built from your local git repository (I guess). I have downloaded 2.2.0 but your patches were made from an earlier version (I guess again).
So am I right that I have to merge the patches manually with the 2.2.0 code?
@Martin: This is indeed good news. My latest info I got from the IEEE 802 meeting at TÜV in Munich was "We're not interested." But perhaps high performance trading already made its way to Redmond.
Still this would "only" be software timestamping and even if it was done in the network driver it would still be late. As nearly every new PCIe MAC or PHY nowadays offers hardware timestamping what is missing is NDIS support for hardware timestamping.
Also GetSystemTimePreciseAsFileTime only helps if you really want to synchronise your Windows clock via PTP from the GrandMaster. But there are also cases where you just want to offer precise time but not force the user (or the IT department ;-) to synchronise your/their Windows box(es) from PTP.
In general, do you think there is demand for a native (MSVC) ptpd version for Windows with or without hardware timestamping?
Regards
Axel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are OK with a GPL licensed code base, you can checkout my portation of ptpv2d (branched back in 2007 from ptpd code base) where I did a crude port to MSVC and also did put in hooks for system time getting and setting.
As mentioned in this thread, windows operating system nor drivers offer the hooks/methods/etc. for precise timestamping tide to actual time.
But if you are interested in experimenting, this could be something you might find useful.
hi,Alan
I have a serious question about your ptpv2d version(svn revision is 31 in google code path) . when I run the command as follows # ptpv2d -c -p -2 ,the log shows that "...can not receive the time stamp". I think there is no follow-up package be cached by wireshark tool. Could you give some advise. Thanks a lot .Waiting for your reply.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Alan,
it is nice, but GPL is not backward compatible with mainline PTPd project and its BSD license.
Your code is not readable so I can't find some methods. I'm lost in all of the IFDEFs, all of the "compatibility layers" and hardware specific hacks.
How do you determine timestamps of packets on Windows?
Cheers,
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as the fact I had to make the code GPL, that is something I had no choice over, I was allowed to publish it as GPL, I was not allowed to publish it as BSD (which was better to publish it in some form so others could use it). I understand that means nothing directly can go into the ptpd base, but again, it is better than keeping the code private (which was my only other choice).
Anyway, the timestamps are gotten through windows calls at the time the packet arrives at the winsock layer. As was stated in previous posts, there is no way (at least not that I could find) to get timestamps via/through/around/etc. NDIS.
So with the fact that it gets the timestamps at socket layer (well after the packet has actually arrived) and that there the resolution from Windows standard timers sucks, you aren't going to get very good timestamps.
I did have one contributor to my base offer a method whereby the time resolution was improved by getting Windows time and also the Intel CPU performance counter and used that to improve the time base calculations. I just never got around to integrating it as although the contribution looked interesting, I didn't have time personally to integrate it and test it.
Ideally the only way you'll probably ever get decent performance in Windows is to get some method of HW timestamping and add that to the driver and have it available for the application (again, more work than I have time to do in my "spare time").
Anyway, there are those whom have used my code base for some experimentation and if you want to get any of their experiences, there are a few posts on the Google groups forum for ptpv2d. Also when it comes to the source that is in there, I'm OK with use of any of the Windows specific code being ported to ptpd under BSD if someone thinks it is useful as that is code I personally did after the time where I had joint ownership with another party. Also, under SVN, there are the project files for Microsoft C, so it could be a starting point for someone who wants to try at least a partially working version under Windows.
Cheers,
Alan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Alan,
thank you for your response and sorry for my previous message.
As long as your code is not directly usable (different code base, different license), it is possible to reuse ideas.
It is possible to sw timestam packets at driver level as I did in my patches with WinPCAP. This driver uses kQueryPerformanceCounter (or something like that). Timestamps with this are almost as precise as software timestamps on Linux.
Problem is the timescale of this timestamps. It is different from timescale of whole system. Patches in Google group of your project may be the last step for most precise sw implementation on windows.
I will look at this.
Cheers,
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Everyone,
First post here, but I've been working with the daemon for 3 months now. I'm just now getting around to looking at testing on different systems and I've never ported a piece of software before. I'm looking to use the windows port that is available on this site. Is anyone willing to give me a quick rundown on how to do it?
Thanks!
Hi,
- it can compile only by MinGW, no MSVC support yet.
- running PTPd as windows service is NOT supported as well as logging to system log
- there is prepared project for code:blocks and makefile
- if you want just passive mode, just remove -DPCAP and -lwpcap from makefile or codeblocks project and run PTPD with appropriate switches
- if you want more precise timestamps, you have to install WinPCAP and its development packages for windows and after that compile ptpd.
About WinPCAP:
Windows itself does not provide timestamps of packets like linux. If you want timestamp, you can just save actual time in the appropriate function and this is not precise (it can't be precise more then few mili seconds). WinPCAP can help it little bit, because it saves timestamp at driver level. For the future, WinPCAP should be solution also for Layer 2 ethernet mode for PTPd, because windows can't send custom layer 2 packets without additional driver.
Hi everybody,
I completely failed in trying to compile ptpd for Windows via mingw.
As in ptpd.h there is inclusion of sys/resource.h, sys/timex.h, sys/socket.h, syslog.h, etc. the build under mingw fails, because the files are not there.
So how did you ever compile it with mingw?
Any hint highly appreciated.
Regards
Axel
PS: I used 2.2.0.
Hi,
Windows port is not part of official PTPd. It is available as set of patches. The functionality of windows port is incomplete and it does not currently work with PCAP and slave mode. Slave mode without PCAP can work, but it is not precise (error about 10ms).
Regards,
Jan
Hi Jan,
thank you for your reply. Where can I find the patches?
Slave mode would be most interesting (who wants to run a master under Windows? ;-)
10ms isn't really "precise" anymore, but never mind, I'm mainly interested in learning from the project and perhaps I could help to improve the situation on Windows.
Cheers
Axel
Hi Axel,
Have a look at patches section of the project
https://sourceforge.net/tracker/?group_id=139814&atid=744634
Maybe I have more recent version with some more experiments and against newer SVN version but with same problems.
If you are interrested, I can send you something more.
Regards,
Jan
Guys,
did you now Microsoft finally started to support high precision time in Windows?
The new GetSystemTimePreciseAsFileTime() API call has been introduces with the Windows 8 preview:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895%28v=vs.85%29.aspx
Please note the page above mentions a parameter "LPFILETIME *lpSystemTimeAsFileTime". This is wrong since LPFILETIME is already a pointer. I've already submitted a bug report to some MS guys who have confirmed that the calling parameters are the same as for the older GetSystemTimeAsFileTime() API, so an application can use a function pointer which is set to the new API call if the function can be imported at program startup, and fall back to the older call otherwise.
Martin
Hi Martin,
this is nice. I didn't notice this.
The final limiting factor for windows implementation is precision of packet timestamp. Getting packet timestamp at application level is late for precise implementation. Or am I misunderstood something?
Regards,
Jan
Jan,
Of course you are right.
I've played around a little bit with the new API call in an own tiny test program, and the results really look good, so the implementation of the system clock seems to be much better than in earlier Windows versions.
I'm pretty sure there is an equivalent call in kernel mode, and I'm expecting MS themselves will use this in their drivers to benefit from the new high precision timekeeping. If they have high resolution time I'm sure they finally also want the time to be accurate.
For example, for GPS PCI card drivers I'm maintaining the availability of this API call in kernel mode will be sufficient to yield high accuracy.
I'm pretty sure there will also be timestamping support in Windows NIC drivers, but the question is whether these API calls will be published by MS.
Martin
Hi Jan and Martin,
nice that there is a discussion going on again.
@Jan: Thanks a lot for the linkt to your patches. I downloaded them and am currently struggling to apply them. Please forgive me for my naivety: How do I find out what was the orognial version? I saw that the patches were built from your local git repository (I guess). I have downloaded 2.2.0 but your patches were made from an earlier version (I guess again).
So am I right that I have to merge the patches manually with the 2.2.0 code?
@Martin: This is indeed good news. My latest info I got from the IEEE 802 meeting at TÜV in Munich was "We're not interested." But perhaps high performance trading already made its way to Redmond.
Still this would "only" be software timestamping and even if it was done in the network driver it would still be late. As nearly every new PCIe MAC or PHY nowadays offers hardware timestamping what is missing is NDIS support for hardware timestamping.
Also GetSystemTimePreciseAsFileTime only helps if you really want to synchronise your Windows clock via PTP from the GrandMaster. But there are also cases where you just want to offer precise time but not force the user (or the IT department ;-) to synchronise your/their Windows box(es) from PTP.
In general, do you think there is demand for a native (MSVC) ptpd version for Windows with or without hardware timestamping?
Regards
Axel
clemer1, et. al.
If you are OK with a GPL licensed code base, you can checkout my portation of ptpv2d (branched back in 2007 from ptpd code base) where I did a crude port to MSVC and also did put in hooks for system time getting and setting.
As mentioned in this thread, windows operating system nor drivers offer the hooks/methods/etc. for precise timestamping tide to actual time.
But if you are interested in experimenting, this could be something you might find useful.
See: http://code.google.com/p/ptpv2d/
Cheers,
Alan
hi,Alan
I have a serious question about your ptpv2d version(svn revision is 31 in google code path) . when I run the command as follows # ptpv2d -c -p -2 ,the log shows that "...can not receive the time stamp". I think there is no follow-up package be cached by wireshark tool. Could you give some advise. Thanks a lot .Waiting for your reply.
Hi Alan,
it is nice, but GPL is not backward compatible with mainline PTPd project and its BSD license.
Your code is not readable so I can't find some methods. I'm lost in all of the IFDEFs, all of the "compatibility layers" and hardware specific hacks.
How do you determine timestamps of packets on Windows?
Cheers,
Jan
Jan,
As far as the fact I had to make the code GPL, that is something I had no choice over, I was allowed to publish it as GPL, I was not allowed to publish it as BSD (which was better to publish it in some form so others could use it). I understand that means nothing directly can go into the ptpd base, but again, it is better than keeping the code private (which was my only other choice).
Anyway, the timestamps are gotten through windows calls at the time the packet arrives at the winsock layer. As was stated in previous posts, there is no way (at least not that I could find) to get timestamps via/through/around/etc. NDIS.
So with the fact that it gets the timestamps at socket layer (well after the packet has actually arrived) and that there the resolution from Windows standard timers sucks, you aren't going to get very good timestamps.
I did have one contributor to my base offer a method whereby the time resolution was improved by getting Windows time and also the Intel CPU performance counter and used that to improve the time base calculations. I just never got around to integrating it as although the contribution looked interesting, I didn't have time personally to integrate it and test it.
Ideally the only way you'll probably ever get decent performance in Windows is to get some method of HW timestamping and add that to the driver and have it available for the application (again, more work than I have time to do in my "spare time").
Anyway, there are those whom have used my code base for some experimentation and if you want to get any of their experiences, there are a few posts on the Google groups forum for ptpv2d. Also when it comes to the source that is in there, I'm OK with use of any of the Windows specific code being ported to ptpd under BSD if someone thinks it is useful as that is code I personally did after the time where I had joint ownership with another party. Also, under SVN, there are the project files for Microsoft C, so it could be a starting point for someone who wants to try at least a partially working version under Windows.
Cheers,
Alan
Hi Alan,
thank you for your response and sorry for my previous message.
As long as your code is not directly usable (different code base, different license), it is possible to reuse ideas.
It is possible to sw timestam packets at driver level as I did in my patches with WinPCAP. This driver uses kQueryPerformanceCounter (or something like that). Timestamps with this are almost as precise as software timestamps on Linux.
Problem is the timescale of this timestamps. It is different from timescale of whole system. Patches in Google group of your project may be the last step for most precise sw implementation on windows.
I will look at this.
Cheers,
Jan