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

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

On Mon, Mar 09, 2015 at 08:53:52PM +0100, Richard Cochran wrote:
> On Fri, Mar 06, 2015 at 06:11:25PM +0100, Miroslav Lichvar wrote:
> > The trouble is the raw mode is not a filter that can be easily
> > plugged in, it has a different input than servos. It's a fundamentally
> > different approach in how are the timestamps handled. In the raw mode
> > we use only the last four timestamps, in filtered mode we use the last
> > two timestamps and a long term average of delays from past sets of
> > four timestamps.
> 
> We can really rework clock.c to make it cleaner to implement this sort
> of thing.  We don't have to store t1-4 in the struct clock at all.

If t1-t4 are not stored in clock.c, where will be delay calculated?

> Why not abstract the offset estimator:
> 
> 		   +-------------+
>               t1 --|             |
>               t2 --|  offset     |
>               t3 --|             |-- offset
>               t4 --|  estimator  |
>   smoothed delay --|             |
> 		   +-------------+
>
> There has got to be a nicer way to arrange the code to make this
> work.  Once we add a "balanced mode" that works better in some
> situations, people will want other balanced mode algorithms.

Hm, are there any other algorithms suitable for that?

To me, it would make more sense to calculate the delay and offset at
one place. How about the following approach instead?

- introduce a "time stamp processor" (tsproc.c)
  - input is t1-t4, c1-c3, clock rate ratio and update rate of t1t2 to t3t4
  - output is offset, delay and weight
  - the delay filter is there
  - according to the configuration and t1t2/t3r4 rate, it either
    returns raw offset/delay or values based on filtered delay
  - weighting is configurable too
- clock.c doesn't store t1-t4 and doesn't filter delay, it only calls
  tsproc_update* functions with new input and tsproc_getsample() to
  get a sample for the servo, print it and update the statistics
- port.c can use this too, deduplicating the delay calculation and
  delay filtering

Does it make sense?

-- 
Miroslav Lichvar