On Mon, Feb 16, 2015 at 09:07:12PM +0100, Richard Cochran wrote:
> On Fri, Feb 13, 2015 at 01:56:12PM +0100, Miroslav Lichvar wrote:
> > These patches should improve the synchronization of the clock with
> > larger jitters, e.g. with software timestamping, wireless networks,
> > etc.
>
> What kind of networks did you test this on?
Ethernet, with SW and HW timestamping, and simulations with jitters up
to hundreds of milliseconds.
> > What do you think? Does this make sense?
>
> This code pairs up the Sync measurement with the most recent Delay_Req
> measurement. The assumption here is that a randomly larger Sync delay
> will be paired with a larger Delay_Req delay (if I understood). But
> that is not a valid assumption in general, is it?
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 :).
time --->
sync delay sync delay sync
t1'' t4' t1' t4 t1
master --+------------+-----+-------------+-------+-----------
\ / \ / \
\ / \ / \
\ / \ / \
slave ------+----+-------------+-----+-------------------+---
t2'' t3' t2' t3 t2
There are 6 combinations of four timestamps that can be used to make a
sample and get an offset with delay: t1''t2''t3't4', t1''t2''t3t4,
t1't2't3't4', t1't2't3t4, t1t2t3't4', t1t2t3t4.
Samples t1''t2''t3t4 and t1t2t3't4' are not very useful as it's better
to have the timestamp closer to each other to minimize the error in
the calculated delay due to frequency offset between master and slave.
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.
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.
> I think the best way is to simply leave out (ignore) bad measurements
> altogether. This is what the mean filter does, and the servos are
> supposed to mitigate the effects of outliers.
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.
> Come to think of it, can't your algorithm be implemented within the
> current servo/filter modular architecture? We can change the API to
> provide t1, t2, t3, and t4.
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).
--
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
