I have a rather annoying problem which I am hoping someone can point me towards the right direction. I am fairly new at this so my understanding might be limited in some areas.
I have managed to get 3 devices (3 evaluation boards) to get in sync (sort of) using ptpd-1.1.0. There is no OS running so the lwip stack below is interrupt driven. The timestamping is performed by the unit and not manually (i.e., no peripheral timers are being used etc).
The issue that I am facing is that the slaves are both very close (less than 200ns) but they are both 1ms away from the master. These values are very stable, i.e., no jumping around or absurd amounts of jitter. Also the rate adjustment values (ppb) that come out of each board are very consistent once the PIR controler has converged. I am using a traditional switch for all three of them to communicate, and they are on their own, i.e., no other traffic.
Any help or pointers would be much appreciated.
Evros
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand that you are using 1.1.0 because of how light the code was at the time. It is considered very much a legacy version, never mind it supporting PTP v1 only.
The 200 ns error you are seeing, is it reported by PTPd itself or do you see it based on external measurement of signals coming out of the boards?
A constant error (reported by PTPd) is usually a problem with PI servo constants I find it, but it could possibly be a rounding error as well, because the servo in ptpd 1.x is all integer based.
Where is the 1ms path delay coming from - is it because of a long distance or is the forwarding delay of the switch so high? If the error is actually measured, then it could just be the the link asymmetries, which are down to things like multicast replication, queuing, and finally physics. What media are you using for this - copper, fibre?
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I apologise for the late response, I thought I'd subscribed to email updates on any replies to this post. Turns out I didn't.
I managed to get sub 250ns syncronisation between nodes eventually.
All the errors and bugs are attributed to the lwip/ptpd ports provided by the MCU manufacturer. After spending more or less a week to get the ported code sorted it all worked fine. Also many discrepancies in the datasheet and responses on their forum did not make the situation any better. Moreover, the provided examples did not do exactly what they were supposed to be doing which added more to the confusion, leading me to believe there is something wrong with the ptpd v1 code; especially after it being halted due to the v2.
Thank you for getting back to me and for your effort. Yes, I think ptpd 1.x code will do just fine for this sort of applciation.
Regards,
Evros
Last edit: Evripidis Karseras 2016-03-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
I have a rather annoying problem which I am hoping someone can point me towards the right direction. I am fairly new at this so my understanding might be limited in some areas.
I have managed to get 3 devices (3 evaluation boards) to get in sync (sort of) using ptpd-1.1.0. There is no OS running so the lwip stack below is interrupt driven. The timestamping is performed by the unit and not manually (i.e., no peripheral timers are being used etc).
The issue that I am facing is that the slaves are both very close (less than 200ns) but they are both 1ms away from the master. These values are very stable, i.e., no jumping around or absurd amounts of jitter. Also the rate adjustment values (ppb) that come out of each board are very consistent once the PIR controler has converged. I am using a traditional switch for all three of them to communicate, and they are on their own, i.e., no other traffic.
Any help or pointers would be much appreciated.
Evros
Hi Evros,
I understand that you are using 1.1.0 because of how light the code was at the time. It is considered very much a legacy version, never mind it supporting PTP v1 only.
The 200 ns error you are seeing, is it reported by PTPd itself or do you see it based on external measurement of signals coming out of the boards?
A constant error (reported by PTPd) is usually a problem with PI servo constants I find it, but it could possibly be a rounding error as well, because the servo in ptpd 1.x is all integer based.
Where is the 1ms path delay coming from - is it because of a long distance or is the forwarding delay of the switch so high? If the error is actually measured, then it could just be the the link asymmetries, which are down to things like multicast replication, queuing, and finally physics. What media are you using for this - copper, fibre?
Thanks,
Wojciech
Hi Wojciech,
I apologise for the late response, I thought I'd subscribed to email updates on any replies to this post. Turns out I didn't.
I managed to get sub 250ns syncronisation between nodes eventually.
All the errors and bugs are attributed to the lwip/ptpd ports provided by the MCU manufacturer. After spending more or less a week to get the ported code sorted it all worked fine. Also many discrepancies in the datasheet and responses on their forum did not make the situation any better. Moreover, the provided examples did not do exactly what they were supposed to be doing which added more to the confusion, leading me to believe there is something wrong with the ptpd v1 code; especially after it being halted due to the v2.
Thank you for getting back to me and for your effort. Yes, I think ptpd 1.x code will do just fine for this sort of applciation.
Regards,
Evros
Last edit: Evripidis Karseras 2016-03-18