Hello, I am investigating the feasibility of using ptpd to sync two Windows
7 machines.
My requirements are:
—Sub-ms precision sync between the two machines
—I do not require these machines to have absolute time syncronization
—There will be no internet but only LAN
I am wondering if the following configuration would work:
—Master clock raspberry pi running ptpd
—Simple (?) LAN router to which all three machines (master, 2 Win slaves)
are connected to via ethernet
—Software PTPv2 slave running on each of the machines
The most expensive part of this appears to be in the software, as the most
obvious solution appears to be from a vendor called Greyware (Domain Time
II). Any less expensive implementation would be preferred, and any help to
achieve this would be greatly appreciated! Please let me know if I can
clarify anything.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As it stands today, ptpd is not ready to run on Windows, and we are not going to develop a Windows-capable version before a generic transport API is introduced. Windows has no socket timestamping mechanisms and very crude time control. Running ptpd or what becomes of ptpd in near future, will eventually be possible on Windows, but currently this is very far down on priority list.
I think you will be better off with NTPd for Windows - I think Martin Burnicki of Meinberg looks after this port.
You have picked some of the worst platforms possible for timing: Windows and Raspberry Pi. Rpi is not tragic, but it uses a USB-based NIC, which introduces a large amount of packet delay variation ("jitter").
What is your use case on Windows that requires tight time sync?
Regards,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By the way, with DomainTime II on Windows, the clock offset jumps around anywhere from +10 to -10 milliseconds all the time, more or less. Not the software's fault - well, partially. The platform is just not suitable for good sync. NTP will be much more conservative and should yield better results over LAN. DT2 can be used to achieve sync using PTP, but unfortunately not good sync. Sometimes it will show a random spike of hundreds of milliseconds. This is based on a test with a an enterprise grade nanosecond-level hardware grandmaster with GPS source.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks for your input. We are dependent on these two machines for synchronizing data acquisition, and the software that it uses relies on Windows. I recognize that this is the ptpd group, but would you happen to know if there is an ntpd implementation that would be appropriate without access to the internet?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As to lack of Internet access - I take it that you care less about sync with UTC, but more about keeping the two machines in sync. In that case just run an NTP server on a third machine and get the two to sync to it. No Internet access required.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, I am investigating the feasibility of using ptpd to sync two Windows
7 machines.
My requirements are:
—Sub-ms precision sync between the two machines
—I do not require these machines to have absolute time syncronization
—There will be no internet but only LAN
I am wondering if the following configuration would work:
—Master clock raspberry pi running ptpd
—Simple (?) LAN router to which all three machines (master, 2 Win slaves)
are connected to via ethernet
—Software PTPv2 slave running on each of the machines
The most expensive part of this appears to be in the software, as the most
obvious solution appears to be from a vendor called Greyware (Domain Time
II). Any less expensive implementation would be preferred, and any help to
achieve this would be greatly appreciated! Please let me know if I can
clarify anything.
Hi,
As it stands today, ptpd is not ready to run on Windows, and we are not going to develop a Windows-capable version before a generic transport API is introduced. Windows has no socket timestamping mechanisms and very crude time control. Running ptpd or what becomes of ptpd in near future, will eventually be possible on Windows, but currently this is very far down on priority list.
I think you will be better off with NTPd for Windows - I think Martin Burnicki of Meinberg looks after this port.
You have picked some of the worst platforms possible for timing: Windows and Raspberry Pi. Rpi is not tragic, but it uses a USB-based NIC, which introduces a large amount of packet delay variation ("jitter").
What is your use case on Windows that requires tight time sync?
Regards,
Wojciech
By the way, with DomainTime II on Windows, the clock offset jumps around anywhere from +10 to -10 milliseconds all the time, more or less. Not the software's fault - well, partially. The platform is just not suitable for good sync. NTP will be much more conservative and should yield better results over LAN. DT2 can be used to achieve sync using PTP, but unfortunately not good sync. Sometimes it will show a random spike of hundreds of milliseconds. This is based on a test with a an enterprise grade nanosecond-level hardware grandmaster with GPS source.
Many thanks for your input. We are dependent on these two machines for synchronizing data acquisition, and the software that it uses relies on Windows. I recognize that this is the ptpd group, but would you happen to know if there is an ntpd implementation that would be appropriate without access to the internet?
https://www.meinbergglobal.com/english/sw/ntp.htm - Meinberg's Windows NTPd.
As to lack of Internet access - I take it that you care less about sync with UTC, but more about keeping the two machines in sync. In that case just run an NTP server on a third machine and get the two to sync to it. No Internet access required.
...or run one machine as server and the other as client.