Richard, Miroslav, Thanks for the response.
Yes definitely, tsproc instead of port.c, not sure what I was thinking. I'm glad I asked. I'm trying to figure out how to fit an experiment into LinuxPtp and end up with as much as possible worth pushing back up. It looks like the dual filters are easy to fit in. Let me talk about the rest of the story and see if you have any other ideas. The parts talked about are a Timekeeping framework, filtering framework, packet selection, and timestamping. For timekeeping I'm drawn to history in the way ship's navigators used the chronometer. They never adjusted it and instead just kept notes on what they learned about it's error. That way if something they learned turned out to be in error, they could sort it out later. For PTP, I wish to do the same. Keep the local clock steady, unaffected by the servo. Keep a history of measurements based on the local clock. This gives ability to rethink previous decisions as new information comes in. This client's job is then to find the offset to add to local time to make the reconstructed master's time. Depending on the local clock, this offset may converge to a fixed number, or (as you point out) vary in interesting ways. To describe the filtering framework, let me paint a picture I like to call a time tunnel because it has a hole in the middle we are steering the offset through. Given this local reference, one can calculate an apparent offset for each measurement assuming zero transport delay. (For PTP these are the corrected t1-t2 and t4-t3.) If you do a scatter plot of these versus local time, you will get a clump for each direction, one above and one below the actual offset. The scatter plot combines stats from the local clock offset variations and the pdv in each direction. The distance between the clumps is the RTT. The center of the space between the clumps is the offset. Given this, you can sketch two curves, picking out the statistic you desire (perhaps average or lowest delay times) for the packets in each direction. Then draw a curve half way between these as the measured offset. Then use this to drive a servo to construct the smoothed, estimated offset. The packet selectors implementing the above sketch depend on the local reference. Without SyncE, the local reference will vary in phase and frequency. But, there are still bounds on the how much it can vary in the short term depending on the spec for the local oscillator. These can be used to propagate expanding error bounds on measurements forward and backwards in time. (This is why I'd like to have the local time along with the measurement.) These can be used to let good measurements outweigh measurements which contain no useful information. This gives a starting point for picking measurements. You can add more complex bounds mechanisms which track how the local reference is moving if you wish. With SyncE to condition the local clock, the offset is not time varying (a flat line). So the constructed bounds are also flat, but maybe still decreasing weight after a while to favor newer measurements. (Since I'm interested in higher accuracy, this is the use case I'm focused on for now.) For timestamping, I have hardware which looks like a half of a TC function. It has a local clock which counts time since boot in the correction field format. (Clocked from the Ethernet RX clock for SyncE.) On packet receive, it picks out the event packets and subtracts the local clock from the correction field in the packet. (Incrementally updating the udp and fcs.) On packet transmit, it picks out the event packets and adds the local clock to the correction field. It's a half TC function because packet switching hardware supporting TC might implement these functions so a packet transiting the box encounters both the receive and transmit functions. I plan to do the other half in the PTP packet handling software. S/W rx reads local time and both sets the rx timestamp to this value and adds it to the correction field. S/W tx reads local time and both sets the tx timestamp and subtracts same from the correction field. Given this, no special per-packet timestamping functions are required in the kernel and the reading of local time does not need to be especially accurate. For output, I can tell the hardware what local time to put out a 1PPS for testing. Not particularly interested in synchronizing the Linux system time to the ptp time. The above seems a mind shift from where things are today, so I'd like to first do something easy to see if it works before making it pretty. I'd like to stay out of kernel space for now to keep the scope of the experiment small enough to actually get done. (Open /dev/mem and map a window to the fpga regs into the ptp4l.) Given this, I can add another timestamping mode and put the s/w timestamping into bc_event and port_prepare_and_send. You have pointed out where to put in the dual filters. The servo looks straight forward. The remaining part appears to be figuring out how to turn off the all the kernel packet timestamping help. Also, turning off the /dev/ptp0 stuff. Thoughts? _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
