On Tue, 2015-02-17 at 20:25 +0100, Richard Cochran wrote: > 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
You could have a "weighted-pi" and "weighted-linreg". Then the "weighted.c" module would pick pi or linreg based on name but stack it with weighted mode. Then change the api for servos to take enough data to do weighted mode. Then the weighted servo would simply call out to another servo under the hood. Regards, Jake ------------------------------------------------------------------------------ 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
