Re: [Linuxptp-devel] [PATCH RFC 0/6] Improve accuracy with software timestamping

[Miroslav L. <mli...@re...>]

On Sun, Feb 22, 2015 at 07:16:12PM +0100, Richard Cochran wrote:
> By "error that moves slowly" you mean that a network with much packet
> delay variation (PDV) will add an error into the Sync measurements?

Both delay and sync measurements have an error that is assumed to have
some random distribution. The delay filter reduces the error in the
estimated delay and offset, but the offset is no longer randomly
distributed, which makes it more difficult for the servo to find a
better estimate of the clock's offset.

With ptp4l using software timestamping between two directly connected
computers you can see the printed delay slowly going up and down even
if it should stay constant, right? That error is included in the offset
and the servo may interpret it as changes in the clock's frequency for
instance. The filter could be longer and longer to minimize this
problem, but that would make ptp4l react slower to changes in the
network configuration.

Perhaps I should prepare some graphs that would demonstrate this?

> 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?

No, I think in the balanced mode in general it makes the servo's job
harder. The offset values are smaller, but they are correlated. The
optimal configuration of the servo may be different for the two cases
though.

> > 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

Think of NTP in symmetric or client/server mode (not broadcast). In
PTP that's when the delay or pdelay interval is equal to the sync
interval. With peer delays it could actually make more sense to use
the pdelay response instead of sync and ignore the sync timestamps as
the four pdelay timestamps are closer, but that's for later.

> Unless I misunderstood, your scheme relies on the assumption that the
> PDV will affect the {Sync, Delay_Req} pair in a uniform way.

The delays in the two directions are assumed to be independent. If the
delay request message is delayed in the network, the sync message
doesn't have to be, if that's what you are concerned about.

> - expand the servo/filter APIs to include all of the parameters you
>   will need.

Like this?

servo_sample(offset, local, weight, raw_offset, raw_delay,
	filtered_offset, filtered_delay, sync_delay_rate, state)

I don't like it very much, to be honest.

> - 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.

So pi servo will always use the weight, but balanced pi has to be used
to get values different than 1.0 there?

Also, there is still the problem that the offset/delay values printed
in clock.c will not be the actual values used by the servo.

-- 
Miroslav Lichvar