Good afternoon, everyone, Thanks to some helpful souls here, I have ptpd-2.0.0 running on a number of STM32F7 dev boards. I’ve got them configured to emit the 125ms PPS pulse and using a logic analyzer or scope with persistence on, I can see that the PPS rising edges are able to stay within a couple microseconds of each other. This is fantastic.
I’ve also got the devices emitting ‘offset’ and ‘drift’ values over the network where I can graph them. This is fun to watch but not very interesting otherwise. In ptpd parlance, ‘offset’ is difference between the slave receive time and the master’s send time (in the packet received), and then subtracting off from that the computed mean path delay. Basically this is Tms from the PTP spec; it's the instantaneous difference in clocks from master to slave, which is then filtered and called ‘offset’. Similarly, ‘drift’ seems to be the long term averaged (and scaled) offset. Now my offset numbers make sense; they hover around zero usually +/-200ns. My question is about the ‘drift’ value; the drift value is stable, but it is *huge* (~1075ppm, or 1750000ns) and stays huge, even after days of synchronization: 000702608.050965873 (000335140): state=slave: offset= -76ns drift=1073.444ppm HCLK=216.232MHz (4.325x) 000702609.051064305 (000336140): state=slave: offset= -79ns drift=1073.441ppm HCLK=216.232MHz (4.325x) 000702610.051162376 (000337140): state=slave: offset= -69ns drift=1073.437ppm HCLK=216.232MHz (4.325x) 000702611.051260347 (000338140): state=slave: offset= -98ns drift=1073.433ppm HCLK=216.232MHz (4.325x) 000702612.051358538 (000339140): state=slave: offset= -131ns drift=1073.427ppm HCLK=216.232MHz (4.325x) 000702613.051456870 (000340140): state=slave: offset= -79ns drift=1073.422ppm HCLK=216.232MHz (4.325x) 000702614.051555181 (000341140): state=slave: offset= -61ns drift=1073.421ppm HCLK=216.232MHz (4.325x) 000702615.150663173 (000342239): state=slave: offset= -107ns drift=1073.417ppm HCLK=216.232MHz (4.325x) 000702616.150761324 (000343239): state=slave: offset= -41ns drift=1073.414ppm HCLK=216.232MHz (4.325x) 000702617.150859615 (000344239): state=slave: offset= -63ns drift=1073.414ppm HCLK=216.232MHz (4.325x) 000702618.150957847 (000345239): state=slave: offset= -176ns drift=1073.408ppm HCLK=216.232MHz (4.325x) 000702619.151056198 (000346239): state=slave: offset= -258ns drift=1073.393ppm HCLK=216.232MHz (4.325x) I tried playing around with zeroing the drift once I was synchronized, but that just creates a step response in ‘addend’ value the STM32 uses to finely adjust its time, which usually knocks it out of sync, performs a one-time step in the slave time and my drift is back in this 1000-1100ppm range. This tells me that the drift value is correct, but I can’t figure out why. My question is why would the long-term drift stay so high even though the systems *are* synchronized? I know I’m missing something, I just do not know what it is. Thanks, Andrew _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
