On Tue, Feb 17, 2015 at 12:31:44PM +0100, Miroslav Lichvar wrote: > The delay message doesn't have to be delayed for the sample to have a > smaller weight. The delay calculated from the four timestamps will be > larger than the average when the sync message is delayed, the delay > message is delayed, or both are delayed. Let's make some ASCII art, > maybe it can explain it better :).
Nice chart. (Looks just like one I made recently to explain PTP in a private email ;) > time ---> > sync delay sync delay sync > t1'' t4' t1' t4 t1 > master --+------------+-----+-------------+-------+----------- > \ / \ / \ > \ / \ / \ > \ / \ / \ > slave ------+----+-------------+-----+-------------------+--- > t2'' t3' t2' t3 t2 > In the current code the filtered path delay is updated from samples > t1''t2''t3't4' and t1't2't3t4. The offset is calculated from t1t2, > t1't2' and the current filtered value of the path delay. The problem > is this can't detect that the sync message was delayed. The extra > delay will be included in the following update of the path delay, > after the offset was used to update the clock. The extra delay is included in the path delay, yes, but the median filter should remove it again. > With the change I'm proposing, the offsets/delays of t1't2't3't4' and > t1t2t3t4 samples are used directly to update the clock and the > filtered value is used just to determine the weight of the sample. But in the case where the delay measurement has an error, you penalize a perfectly good sync measurement? > Dropping samples completely could be a nice feature too. The problem > is that the servos are currently not ready to have missed updates and > it's tricky to determine the right value of the delay at which the > samples should be dropped. If it's too large, there will be too few > servo updates, if it's too small, too many bad samples will get in. Let the end user decide, just like with PI weights. > It can, but it would duplicate the code. That's how I tried to do it > originally. The servo sample function would need to get the offset > from the filtered delay, the sync/delay rate and t1, t2, t3, t4 (or > the sample offset and delay). You mean that you would duplicate pi.c for example? I would prefer that to having the "weight" filter hard coded in line. Possibly you could stack the filter on top of the servos? Thanks, Richard ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
