Re: [Linuxptp-devel] linuxptp filter architure
On Mon, Sep 23, 2019 at 08:31:30PM +, Stuart Venters wrote: > 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? Sounds like a great step backwards. Really. I didn't quite follow the explanation of your correction field counter thing, but I can only recommend this. - Make a proper PHC for your fpga. - Implement the SO_TIMESTAMPING API for your fpga. - Use the modular tsproc and servo in linuxptp for your filters. Good luck, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Richard, > -Original Message- > From: Richard Cochran > Sent: Tuesday, September 24, 2019 2:28 AM > To: Y.b. Lu > Cc: Андрей Иванов ; rodney.greenstr...@gmail.com; > erik.h...@ni.com; linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > On Mon, Sep 23, 2019 at 04:17:02AM +, Y.b. Lu wrote: > > May I have your suggestion here? To maintain gPTP time in software, I > > just copied kernel timecounter code into linuxptp for usage. > > Why? That sounds wrong. [Y.b. Lu] May I know TAB based on linuxptp plans to adjust physical clock, or to maintain gPTP time in software. Regarding to physical clock adjustment, that's confusing. This will changes neighbor rate ratio frequently, so the cumulative rate ratio and corrected residence time/path delay in follow_up and TLV will be not correct for the receiver. Regarding to maintaining gPTP time in software, I think this was described in "10.2.12 ClockSlaveSync state machine" of 802.1AS-2011. I currently copied kernel timecounter for this. Is there any better solution? 10.2.12.2.1 updateSlaveTime(): updates the global variable clockSlaveTime (see 10.2.3.3), based on information received from the SiteSync and LocalClock entities. It is the responsibility of the application to filter slave times appropriately (see B.3 and B.4 for examples). As one example, clockSlaveTime can be incremented by localClockTickInterval (see 10.2.3.18) divided by rateRatio member of the received PortSyncSync structure. If no time-aware system is grandmaster-capable, i.e., gmPresent is FALSE, then clockSlaveTime is set to the time provided by the LocalClock. This function is invoked when rcvdLocalClockTick is TRUE. Thanks a lot. Yangbo Lu > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp filter architure
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 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,
Re: [Linuxptp-devel] linuxptp filter architure
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
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Mon, Sep 23, 2019 at 04:17:02AM +, Y.b. Lu wrote: > May I have your suggestion here? To maintain gPTP time in software, > I just copied kernel timecounter code into linuxptp for usage. Why? That sounds wrong. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Mon, Sep 23, 2019 at 04:17:02AM +, Y.b. Lu wrote: > BTW, I have another problem. Usually hardware has a 1588 PHC clock > which is shared by Qbv/Qci for TSN. We are facing problem that > 802.1AS requires free-running clock which TSN requires synchronized > PHC. Right. If you want to use HW features, then you msut synchronize the PHC. End of story. It does not matter what 802.1-AS requires or recommends. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp filter architure
On Fri, Sep 20, 2019 at 04:39:06PM +, Stuart Venters wrote: > To support separate filtering and give the filter access to everything it > needs, I think what I would like to see is the following refactoring and see > how it works out: > > Change the argument list for filter_create to add an indication of which > filter is being created, and pointers to the clock_type and config. > > Change the argument list for filter_sample to be local time of the experiment > and observed delay. Return value would be filtered delay. Where delay is > rxtimestamp - txtimestamp with corrections. > > Change port.c to create two filters and use them on the one-way measurements > before calling clock_synchronize and clock_path_delay. Why port.c? As Richard suggested, tsproc might be a better place. It would help if you could describe your approach in a bit more detail. Is the minimum delay configurable or estimated? How do you prevent it from getting stuck on rapid frequency changes? To me it sounds like you want to drop the measurements as if the packets were lost, i.e. something different than what the filter.h API is intended for. That wouldn't work well with the current servo architecture. Reusing old measurements might be easier, but I suspect it could be tricky. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Richard, That's great to see this discussion. I'm working on the TAB implementation too. What I didn’t see in the discussion is how to synchronize gPTP time with free-running clock. As I understand, 802.1AS uses free-running clock and corresponding timestamping, but maintains synchronized time in software. Not adjusting physical clock makes synchronization more efficient than 1588. Although adjusting physical clock is allowed by 802.1AS, the whole standard describes the implementation for free-running clock. I have no idea in my mind to run 802.1AS if physical clock is adjusted which makes neighbor rate ratio changes frequently, couldn’t correct path delay/residence time, and calculate a correct accumulative rate ratio. May I have your suggestion here? To maintain gPTP time in software, I just copied kernel timecounter code into linuxptp for usage. BTW, I have another problem. Usually hardware has a 1588 PHC clock which is shared by Qbv/Qci for TSN. We are facing problem that 802.1AS requires free-running clock which TSN requires synchronized PHC. Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Richard Cochran > Sent: Monday, September 16, 2019 11:00 AM > To: Андрей Иванов > Cc: rodney.greenstr...@gmail.com; erik.h...@ni.com; > linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > On Sat, Sep 14, 2019 at 09:23:15PM +0300, Андрей Иванов wrote: > > > Moving on the way of realization of 802.1AS TAB I ask to describe the > > modified algorithm of functioning of linuxptp taking into account need > > of processing of a timeout of reception of the SYNC message. > > I'm taking this discussion onto the linuxptp-devel list. > > Back in 2017, Rodney Greenstreet was working on TAB support for linuxptp. > Since then, he has moved on to other things, but he did agree to share his > design notes with us. > > At the time, Rodney did a comparison between the IEEE 1588 TC and the > 802.1-AS TAB. He sent me his notes, and I replied to a few points. > The following is the conversation between Rodney and me. I present it as a > starting point for a discussion about what exactly is needed to implement TAB > support in linuxptp. > > Rodney: > --- > I am discovering there are several differences between a TAB and > TC regarding time transfer. The following are highlights of the > differences I > am > referring to: > > > > A two-step TC forwards a Sync Event message as soon as it is received > (IEEE > 1588-2008 11.5.2.2 Two-step transparent clocks). > > A TAB waits for a matched Sync/FUP pair before pushing data up to the > PortSyncSyncReceive SM (IEEE 802.1AS-2011 11.2.13 MDSyncReceiveSM > state > machine). > > > > RC: From the perspective of the downstream receiving port, this difference is > of no consequence. The local synchronization function has to wait for the > FUP anyhow, and whether the Sync came immediately before or some short > time before is irrelevant. Unless there is some picky conformance test > checking exactly this behavior, then I would say we can ignore this > difference. > > > > A two-step TC maintains a record of forwarded Sync Event messages and > associated residence times. If and when a FUP that corresponds to a Sync > Event in the record is received, the recorded residence time is added to > the > correction field and the FUP is forwarded (IEEE 1588-2008 11.5.2.2 > Two-step > transparent clocks; note 2). > > A TAB only maintains a reference to the last Sync Event received to pair > up > with a corresponding FUP message. If two consecutive Sync event > messages are > received, the first of the two is discarded (IEEE 802.1AS-2011 11.2.13 > MDSyncReceiveSM state machine). > > > > RC: I don't see the difference here. > > > > A TC forwards Sync Event and FUP messages, only adjusting the > correction > field (IEEE 1588-2008 11.5.2 Residence time correction for Sync > messages). > > A TAB terminates the received Sync/FUP pair and generates a new > Sync/FUP > pair for each downstream port (IEEE 802.1AS-2011 11.2.14 > MDSyncSendSM state > machine). > > > > RC: Well, this is really a matter of perspective. Inside ptp4l, of course we > don't want to free/allocate message buffers. Instead, we keep the existing > buffer and change the
