I would like to evaluate the accuracy one can reach with PTPd between 2 PCs linked with a cross-cable.
I have installed an RTAI environment, in order to output (based on the system clock) square waveforms on the parallel port of both PCs.
These waveforms are displayed thanks to an oscilloscope.
My problem is that roughly after 20 minutes of synchro, the PTPd debug messages state that I reached an accuracy of about 500ns, sometimes less, but on the oscilloscope, I measure a difference between both waveforms of 16us.
I tried to look for a way to suppress this offset, as much as possible, but I can't figure out exactly how the "-l" argument works. If someone could give me some advice about this, that could be very helpful for me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The PTP offset from master calculation assumes that the master-to-slave delay is the same a the slave-to-master delay. This is often not the case, which results a constant offset in the real synchronization. As you noted, the "-l" option is included to compensate for this. The "-l" option lets you set the inbound and outbound latency separately, but all that should matter is the difference between the values, so you really only need to specify one value (i.e. "-l 20000" or "-l -20000").
The goal to to have each device see symmetric inbound versus outbound latencies. You can derive the "-l" value empirically. Start with a simple network configuration, like a direct cable connection. Then you can use a known good device for the master, and tweak the slave's "-l" value to get to zero offset. If both master and slave have unknown inbound/outbound latencies, then you can tweak the "-l" value on one to get to zero offset, but there's no way to determine what portion of the asymmetry is from the master what is from the slave. If you have the same type of device for the master and the slave, then the inbound/outbound delays should theoretically cancel, and you shouldn't see any offset. However, there could be affects from the network equipment that cause asymmetric delays.
Congrats on getting stability below 1 us. I hope this helps you get rid of the 16 us constant offset.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot for your answer.
After many tries and measures, it appears that the problem solved itself.
But my setup was not very stable after all. From one day to the following day, I could get completely different results, without changing any parameter.
Now my study is finished. I would have needed more time to have a perfect setup.
Good luck in your project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to evaluate the accuracy one can reach with PTPd between 2 PCs linked with a cross-cable.
I have installed an RTAI environment, in order to output (based on the system clock) square waveforms on the parallel port of both PCs.
These waveforms are displayed thanks to an oscilloscope.
My problem is that roughly after 20 minutes of synchro, the PTPd debug messages state that I reached an accuracy of about 500ns, sometimes less, but on the oscilloscope, I measure a difference between both waveforms of 16us.
I tried to look for a way to suppress this offset, as much as possible, but I can't figure out exactly how the "-l" argument works. If someone could give me some advice about this, that could be very helpful for me.
The PTP offset from master calculation assumes that the master-to-slave delay is the same a the slave-to-master delay. This is often not the case, which results a constant offset in the real synchronization. As you noted, the "-l" option is included to compensate for this. The "-l" option lets you set the inbound and outbound latency separately, but all that should matter is the difference between the values, so you really only need to specify one value (i.e. "-l 20000" or "-l -20000").
The goal to to have each device see symmetric inbound versus outbound latencies. You can derive the "-l" value empirically. Start with a simple network configuration, like a direct cable connection. Then you can use a known good device for the master, and tweak the slave's "-l" value to get to zero offset. If both master and slave have unknown inbound/outbound latencies, then you can tweak the "-l" value on one to get to zero offset, but there's no way to determine what portion of the asymmetry is from the master what is from the slave. If you have the same type of device for the master and the slave, then the inbound/outbound delays should theoretically cancel, and you shouldn't see any offset. However, there could be affects from the network equipment that cause asymmetric delays.
Congrats on getting stability below 1 us. I hope this helps you get rid of the 16 us constant offset.
Thanks a lot for your answer.
After many tries and measures, it appears that the problem solved itself.
But my setup was not very stable after all. From one day to the following day, I could get completely different results, without changing any parameter.
Now my study is finished. I would have needed more time to have a perfect setup.
Good luck in your project.