Discussion:
[Linuxptp-devel] Offset Filters
Shlomi Tubul
2015-11-04 13:02:34 UTC
Permalink
Hi All,
I have a question regarding offset filters. I saw that there are 2 type of filters for the delay that helps correcting it to.
Is there a reason not to do so also to offset?

Thank you

Shlomi Tubul
System Engineer
Application Acceleration
Mellanox Technologies
Phone: +972 (74) 7237667;
Cell:+972-54-4533843
Richard Cochran
2015-11-04 13:24:24 UTC
Permalink
Post by Shlomi Tubul
Is there a reason not to do so also to offset?
Well, the PI servo (or the linear regression servo) does "filter" the
inputs based on the weights. Also, take a look at the tsproc module.
If you can't find what you need, then you can go ahead and implement
your own servo or tsproc mode that does what *you* want it to do.

(You didn't really tell us what your problem is, BTW.)

Thanks,
Richard

------------------------------------------------------------------------------
Shlomi Tubul
2015-11-04 13:46:52 UTC
Permalink
Thx Richard,

For some reason, I see spikes at clients, which are unreasonable. Most of the time the offset is around +- 200ns, but from time to time it jumps to more than 20 micro second.
This tells the client it needs to adjust its clock, but the adjustment is not correct.

ptp4l[103482.432]: master offset 17 s2 freq +3069 path delay 654
ptp4l[103483.432]: master offset 18 s2 freq +3075 path delay 648
ptp4l[103484.432]: master offset 23197 s2 freq +26260 path delay 636
ptp4l[103485.432]: master offset -23069 s2 freq -13047 path delay 636
ptp4l[103486.432]: master offset -7042 s2 freq -3941 path delay 617
ptp4l[103487.432]: master offset -51 s2 freq +938 path delay 617
ptp4l[103488.432]: master offset 2091 s2 freq +3064 path delay 607
ptp4l[103489.432]: master offset 2089 s2 freq +3690 path delay 617
ptp4l[103490.433]: master offset 1447 s2 freq +3674 path delay 617
ptp4l[103491.433]: master offset 884 s2 freq +3545 path delay 609
ptp4l[103492.433]: master offset 357 s2 freq +3284 path delay 613
ptp4l[103493.433]: master offset 186 s2 freq +3220 path delay 613
ptp4l[103494.433]: master offset 94 s2 freq +3183 path delay 613
ptp4l[103495.433]: master offset -2 s2 freq +3116 path delay 622
ptp4l[103496.433]: master offset -166 s2 freq +2951 path delay 622
ptp4l[103497.433]: master offset 54 s2 freq +3121 path delay 616
ptp4l[103498.433]: master offset -138 s2 freq +2945 path delay 636
ptp4l[103499.433]: master offset 17 s2 freq +3059 path delay 636

Looking at the code of ptp4l, I see that there are filters for the delay but not for the offset.
I updated the code a little it in my environment, just to see if the offset is real. For every offset greater than 1 microsecond, I updated it to 0. This caused the client to synchronize better and not trying to adjust huge offsets.


ptp4l[101694.561]: master offset 23 s2 freq +3132 path delay 654
ptp4l[101695.561]: master offset 16 s2 freq +3132 path delay 635
ptp4l[101696.561]: master offset 153 s2 freq +3274 path delay 619
ptp4l[101697.561]: master offset -110 s2 freq +3057 path delay 619
ptp4l[101698.561]: master offset 0 s2 freq +3134 path delay 619
ptp4l[101699.561]: master offset -456 s2 freq +2678 path delay 619
ptp4l[101700.561]: master offset 430 s2 freq +3427 path delay 625
ptp4l[101701.561]: master offset 104 s2 freq +3230 path delay 625
ptp4l[101702.562]: master offset 45 s2 freq +3202 path delay 625
ptp4l[101703.562]: bad offset!!! old offset=45 new offset=24486
ptp4l[101703.562]: master offset 0 s2 freq +3170 path delay 635
ptp4l[101704.562]: master offset -25 s2 freq +3145 path delay 639
ptp4l[101705.562]: bad offset!!! old offset=-25 new offset=7523
ptp4l[101705.562]: master offset 0 s2 freq +3163 path delay 664
ptp4l[101706.562]: master offset -151 s2 freq +3012 path delay 699
ptp4l[101707.562]: master offset -138 s2 freq +2980 path delay 699
ptp4l[101708.562]: master offset 51 s2 freq +3127 path delay 664
ptp4l[101709.562]: master offset 10 s2 freq +3102 path delay 664
ptp4l[101710.562]: master offset 77 s2 freq +3172 path delay 642
ptp4l[101711.563]: master offset 60 s2 freq +3178 path delay 647
ptp4l[101712.563]: master offset -80 s2 freq +3056 path delay 659
ptp4l[101713.563]: master offset -47 s2 freq +3065 path delay 659
ptp4l[101714.563]: master offset 44 s2 freq +3142 path delay 647
ptp4l[101715.563]: master offset -12 s2 freq +3099 path delay 640
ptp4l[101716.563]: master offset 5 s2 freq +3112 path delay 640
ptp4l[101717.563]: master offset -46 s2 freq +3063 path delay 647

is there a better/already implemented way to handle these hiccups?
Both server and client are running Intel I210, RH 7.1, linux ptp 1.6.
The setup is running also other applications (Hadoop etc), so I am not sure how much it affects.

Thank You,
Shlomi Tubul
Mellanox Technologies

-----Original Message-----
From: Richard Cochran [mailto:***@gmail.com]
Sent: Wednesday, November 04, 2015 3:24 PM
To: Shlomi Tubul <***@mellanox.com>
Cc: linuxptp-***@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Offset Filters
Post by Shlomi Tubul
Is there a reason not to do so also to offset?
Well, the PI servo (or the linear regression servo) does "filter" the inputs based on the weights. Also, take a look at the tsproc module.
If you can't find what you need, then you can go ahead and implement your own servo or tsproc mode that does what *you* want it to do.

(You didn't really tell us what your problem is, BTW.)

Thanks,
Richard

------------------------------------------------------------------------------
Richard Cochran
2015-11-04 17:29:16 UTC
Permalink
Post by Shlomi Tubul
For some reason, I see spikes at clients, which are
unreasonable. Most of the time the offset is around +- 200ns,
but from time to time it jumps to more than 20 micro second.
You shouldn't have such spikes.
Post by Shlomi Tubul
Looking at the code of ptp4l, I see that there are filters for
the delay but not for the offset.
That is because they are not needed.
Post by Shlomi Tubul
I updated the code a little it in my environment, just to see
if the offset is real. For every offset greater than 1
microsecond, I updated it to 0. This caused the client to
synchronize better and not trying to adjust huge offsets.
You made a band aid, and this papers over the problem. Why not find
out the cause of those spikes?
Post by Shlomi Tubul
Both server and client are running Intel I210, RH 7.1, linux ptp 1.6.
I have used the i210 quite a lot, and I have never seen such spikes.

Do you have a direct point to point connection? If not, probably the
equipment in between is to blame.
Post by Shlomi Tubul
The setup is running also other applications (Hadoop etc), so
I am not sure how much it affects.
The time stamps are taken in hardware at the MAC level, and so
applications should have no effect.

Thanks,
Richard

------------------------------------------------------------------------------
Keller, Jacob E
2015-11-04 17:52:11 UTC
Permalink
Post by Richard Cochran
Post by Shlomi Tubul
For some reason, I see spikes at clients, which are
unreasonable. Most of the time the offset is around +- 200ns,
but from time to time it jumps to more than 20 micro second.
You shouldn't have such spikes.
Indeed, spikes like this are unexpected.
Post by Richard Cochran
Post by Shlomi Tubul
Looking at the code of ptp4l, I see that there are filters for
the delay but not for the offset.
That is because they are not needed.
Offset should be stable, while delay actually can jitter about for
various reasons.
Post by Richard Cochran
Post by Shlomi Tubul
I updated the code a little it in my environment, just to see
if the offset is real. For every offset greater than 1
microsecond, I updated it to 0. This caused the client to
synchronize better and not trying to adjust huge offsets.
You made a band aid, and this papers over the problem. Why not find
out the cause of those spikes?
Post by Shlomi Tubul
Both server and client are running Intel I210, RH 7.1, linux ptp 1.6.
I have used the i210 quite a lot, and I have never seen such spikes.
Do you have a direct point to point connection? If not, probably the
equipment in between is to blame.
Yes likely the equipment between is an issue if there is any.
Post by Richard Cochran
Post by Shlomi Tubul
The setup is running also other applications (Hadoop etc), so
I am not sure how much it affects.
The time stamps are taken in hardware at the MAC level, and so
applications should have no effect.
I do not believe that latency affects the actual timestamping equipment
in hardware. It could delay the overall timestamp return process, but
that doesn't actually add any latency to the timestamp itself since it
was already captured, only in how long it takes to return it. Note that
the i210 can only timestamp one Tx packet at a time, but the outcome
you are seeing is not dropped Tx timestamps, but just spikes in the
value?

Regards,
Jake
Post by Richard Cochran
Thanks,
Richard
---------------------------------------------------------------------
---------
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
------------------------------------------------------------------------------
Loading...