My company recently upgraded to PTPd2. We have a Meinberg M600 with a PTP module that controls a dedicated, quiet PTP sync network. When we were using version 1 we found we had to enable the slave mode "-g" in order for the clients to sync correctly. If we did not do this, the clients would never recognize the Meinberg as the preferred master. Inevtiably the times would start marching quickly to the future (within a minute the client machine would think the year was 2032). Upgrading to PTPv2 the first thing I noticed was the time quickly when to 2032, as though the -g flag was not set. Investigation showed traffic from the clients on the ptp-general port, even with the -g flag. Further investigation showed that ptpd-2.1.0 would issuePDelayResp() in PDelayReq() even though the PDelay response message should only be a master to slave message. I moved the case statements around so the PTP_SLAVE portState would disreguard rather than generating this response. Things improved greatly, and now the clocks are always within 10-20 usec of real time and each other. This is one order of magnitude worse than what we saw in PTPv1.
1) Was my change correct / should I submit a patch for it?
2) Has anyone else experienced degraded accuracy in ptpdv2?
Many thanks!
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My company recently upgraded to PTPd2. We have a Meinberg M600 with a PTP module that controls a dedicated, quiet PTP sync network. When we were using version 1 we found we had to enable the slave mode "-g" in order for the clients to sync correctly. If we did not do this, the clients would never recognize the Meinberg as the preferred master. Inevtiably the times would start marching quickly to the future (within a minute the client machine would think the year was 2032). Upgrading to PTPv2 the first thing I noticed was the time quickly when to 2032, as though the -g flag was not set. Investigation showed traffic from the clients on the ptp-general port, even with the -g flag. Further investigation showed that ptpd-2.1.0 would issuePDelayResp() in PDelayReq() even though the PDelay response message should only be a master to slave message. I moved the case statements around so the PTP_SLAVE portState would disreguard rather than generating this response. Things improved greatly, and now the clocks are always within 10-20 usec of real time and each other. This is one order of magnitude worse than what we saw in PTPv1.
1) Was my change correct / should I submit a patch for it?
2) Has anyone else experienced degraded accuracy in ptpdv2?
Many thanks!
Michael
You need to use the -h flag to use end to end mode. That would be the appropriate way to start the daemon in your case.