Very nice read. But some points: The rethinking of old-decisions w.r.t. new info may not be valid as the time to apply them is long gone since the conditions under which those decisions were made. Maybe the local clock was actually leading or lagging behind at that time, which might not be the case any more as seen in the new info. Consuming packets that show a lower than average delay PDV is a good technique, but even that applies to the current window/instant, can it be applied in retrospect to re-evaluate somewhat older offset calculation? The scatter plot is scattered because of the local clock variation w.r.t. the master clock's stability and the n/w, kernel, time-stamping effect etc. Thus, the weighted average that gives importance to more recent data-points is more valuable (after ofcourse filtering our some rogue packets). Also, why assume the former, that it would ever converge to a fixed number unless the slave clock is at-least as stable as the master with lesser drift and frequency variation due to internal crystal characteristics and temprature etc, in which case it should be the master. Isnt it? Mabe it is still good and wise to have the local-clock (un-corrected) available, but if we have SyncE, and the local clock is at-least corrected for the frequency aspect w.r.t. master, the phase variation can then converge to smaller offsets and corections.
On Tue, Sep 24, 2019 at 7:38 AM Stuart Venters <stuart.vent...@adtran.com> wrote: > 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 > -- Best Regards, ~ Jagmeet Singh Hanspal ~
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
