On Tue, Feb 17, 2015 at 08:25:03PM +0100, Richard Cochran wrote: > On Tue, Feb 17, 2015 at 12:31:44PM +0100, Miroslav Lichvar wrote: > > 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?
You mean that it's better to use the offset based on the filtered delay as the current code does? The problem is that after the filtering the delay is no longer random, there is an error that moves slowly and is included in the offsets passed to the servo, which is not able to remove the error. A longer filter would make this problem smaller, but it's better to let the servo deal with the noise and not make its job harder when not necessary. Look at it in another way. There are two modes of synchronization based on how many measurements are there on the remote and local side. In "unbalanced" mode on one side there is a significantly larger number of measurements, this happens when broadcast/multicast is used to save server or network resources. The four timestamps are too far apart for most samples, so an assumption is made that the delay is constant and the offset is calculated just from the two timestamps and an estimate of the delay. In "balanced" mode the number of measurements is similar on both sides and samples can be safely created from all four timestamps. Each sample has a delay and offset that is independent from others. This is a huge advantage over the unbalanced mode. It's possible to put an upper bound on the error in the offset, the samples can be filtered, or they can have weight. > > 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 meant that the weight calculation would be duplicated. If we wanted to improve it (e.g. square the weight or offset it by minimum delay), we would have to do in multiple places. > I would prefer > that to having the "weight" filter hard coded in line. It's not a really a filter, it provides the servo with extra information that's available in the balanced mode. > Possibly you > could stack the filter on top of the servos? How would the API look like? I don't mind reworking the patches, it's just that adding a single parameter for weight to the servo function looked to me like a simple and clean approach. -- Miroslav Lichvar ------------------------------------------------------------------------------ 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
