On Wed, Feb 18, 2015 at 06:03:03PM +0100, Miroslav Lichvar wrote: > On Tue, Feb 17, 2015 at 08:25:03PM +0100, Richard Cochran wrote: > > 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.
By "error that moves slowly" you mean that a network with much packet delay variation (PDV) will add an error into the Sync measurements? Sure, but if the error can be removed in the path delay estimation by filtering, then the offset servo's job becomes easier, not harder. Or what are trying to say? > 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. Yes, that is how PTP normally works. The path delay is assumed to be constant. It must not be variable. Actually, if it changes to a new static value (like after a change in the network), ptp4l can handle that too. (In E2E mode there will be a momentary offset error.) > 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. So I really have no idea what "balanced" can mean here. Because the PDV does not affect the two messages in the same way, you cannot "safely" use them. Maybe there is some special case where both messages pick up the same PDV, but in general this isn't true. For an example of what I mean, see the second graph and the following text: http://phk.freebsd.dk/time/20141024.html This plot makes the important feature of NTP phase offset measurements very obvious: Notice how almost all these different blobs have the general shape of a blob near X=Y and a tail up and another tail right. This is because the probability of a packet getting delayed on the way to the server is quite independent of the packet going back being delayed. Not totally independent, but quite independent. Unless I misunderstood, your scheme relies on the assumption that the PDV will affect the {Sync, Delay_Req} pair in a uniform way. > 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. Off the top of my head: - expand the servo/filter APIs to include all of the parameters you will need. - introduce CLOCK_SERVO_PI_BALANCED (or whatever) - servo_create(CLOCK_SERVO_PI_BALANCED, ...) calls balanced_servo_create() - balanced_servo_create() calls pi_servo_create() and stores the pointer in its private data area. - the balanced->sample() method will chain to pi->sample(), but with the weight possibly different than the default 1.0. Thoughts? 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
