linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] sanity_freq_limit

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

On Fri, Jun 19, 2015 at 04:15:20AM +0000, Daniel Le wrote:
> And the log messages at start in "good case". I didn't save the log where my system time was initially off a few minutes, though I remember the master offsets were above 200000000. I'll need to reproduce such condition in order to capture the exact log messages.

Your config looks good to me. The default value of first_step_threshold
is 20 microseconds, so in your test with ~1.5 millisecond initial
offset it should have stepped.

> ptp4l[792717.068]: master offset   -1567668 s0 freq  -13556 path delay      1194
> ptp4l[792718.068]: master offset   -1569978 s0 freq  -13556 path delay      1200
> ptp4l[792719.068]: master offset   -1554292 s1 freq  -13510 path delay     -4826
> ptp4l[792720.068]: master offset   -1556592 s2 freq -170726 path delay     -4826

But as we can see, it didn't step for some reason. Here is a test I
did using the same config file and it does step for me.

ptp4l[8898442.271]: master offset   -1093869 s0 freq   -1946 path delay     54642
ptp4l[8898443.271]: master offset   -1094931 s0 freq   -1946 path delay     54642
ptp4l[8898444.271]: master offset   -1102224 s1 freq   -6078 path delay     55329
ptp4l[8898445.271]: master offset       9378 s2 freq   -5131 path delay     55329

What linuxptp and kernel versions are you using?

-- 
Miroslav Lichvar

[Linuxptp-users] Interpretation of ptp4l results

[Chandra M. <sma...@al...>]

Hi Friends,

I would like to double-check whether my following interpretation is correct. Please elucidate me.

For the following ptp4l output, the ptp4l reports rms value and the max deviation from the mean offset. Thus, if I have to report the worstcase accuracy, I take the (rms+max). For example, , looking at the first line, I see that the maximum offset uncertainty/inaccuracy  observed is 2 +7 = 9ns. The maximum frequency uncertainty is (156403 + 7) pbb.


ptp4l[833.369]: rms    2 max    7 freq -156403 +/-   7 delay    28 +/-   0

ptp4l[834.399]: rms    2 max    7 freq -156403 +/-   8 delay    29 +/-   0

ptp4l[835.428]: rms    2 max    7 freq -156403 +/-   7

ptp4l[836.457]: rms    2 max    6 freq -156403 +/-   7 delay    28 +/-   0

ptp4l[837.487]: rms    2 max    6 freq -156403 +/-   7 delay    28 +/-   0

ptp4l[838.516]: rms    2 max    6 freq -156403 +/-   7 delay    27 +/-   0

ptp4l[839.549]: rms    2 max    7 freq -156403 +/-   7

ptp4l[840.583]: rms    2 max    8 freq -156403 +/-   8 delay    29 +/-   0


Thanking you in anticipation,
Regards,
Chandra

(c) : +60.175508142
(O): +60.4.636.6412

"Knowledge speaks, Wisdom listens"



________________________________

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.

Re: [Linuxptp-users] sanity_freq_limit

[Daniel Le <dan...@ex...>]

Below is my ptp4l config file.

$cat ptp4l.conf
[global]
domainNumber                   0
slaveOnly                               1
priority1                                  128
priority2                                  128
clockClass                               248
clockAccuracy                        254
offsetScaledLogVariance  65535
freq_est_interval                 1
time_stamping                      software
tx_timestamp_timeout     1
logging_level                         6
verbose                                    0
use_syslog                              1
summary_interval               0
[eth2]
delay_mechanism                  E2E
network_transport                UDPv4
delayAsymmetry                    0
logAnnounceInterval            1
logSyncInterval                        0
logMinDelayReqInterval      0
logMinPdelayReqInterval    0
announceReceiptTimeout   3
syncReceiptTimeout              0
delay_filter                                moving_average
delay_filter_length                10
path_trace_enabled              0
fault_reset_interval              4

And the log messages at start in "good case". I didn't save the log where my system time was initially off a few minutes, though I remember the master offsets were above 200000000. I'll need to reproduce such condition in order to capture the exact log messages.

ptp4l[792695.130]: port 1: get_ts_info not supported
ptp4l[792695.131]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[792695.131]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[792697.130]: port 1: new foreign master 00b0ae.fffe.02d103-1
ptp4l[792701.130]: selected best master clock 00b0ae.fffe.02d103
ptp4l[792701.130]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[792701.991]: port 1: minimum delay request interval 2^-7
ptp4l[792703.068]: master offset   -1555032 s0 freq  -13556 path delay     -5078
ptp4l[792704.068]: master offset   -1563606 s0 freq  -13556 path delay      1196
ptp4l[792705.068]: master offset   -1565962 s0 freq  -13556 path delay      1212
ptp4l[792706.068]: master offset   -1568258 s0 freq  -13556 path delay      1204
ptp4l[792707.068]: master offset   -1570542 s0 freq  -13556 path delay      1184
ptp4l[792708.068]: master offset   -1553450 s0 freq  -13556 path delay     -5284
ptp4l[792709.068]: master offset   -1562224 s0 freq  -13556 path delay      1186
ptp4l[792710.068]: master offset   -1564536 s0 freq  -13556 path delay      1198
ptp4l[792711.068]: master offset   -1566872 s0 freq  -13556 path delay      1194
ptp4l[792712.068]: master offset   -1569158 s0 freq  -13556 path delay      1180
ptp4l[792713.068]: master offset   -1571482 s0 freq  -13556 path delay      1196
ptp4l[792714.068]: master offset   -1554204 s0 freq  -13556 path delay     -5330
ptp4l[792715.068]: master offset   -1563042 s0 freq  -13556 path delay      1204
ptp4l[792716.068]: master offset   -1565384 s0 freq  -13556 path delay      1210
ptp4l[792717.068]: master offset   -1567668 s0 freq  -13556 path delay      1194
ptp4l[792718.068]: master offset   -1569978 s0 freq  -13556 path delay      1200
ptp4l[792719.068]: master offset   -1554292 s1 freq  -13510 path delay     -4826
ptp4l[792720.068]: master offset   -1556592 s2 freq -170726 path delay     -4826
ptp4l[792720.068]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[792721.068]: master offset   -1564970 s2 freq -173128 path delay      1212
ptp4l[792722.068]: master offset   -1567220 s2 freq -174921 path delay      1162
ptp4l[792723.068]: master offset   -1569548 s2 freq -176723 path delay      1186
ptp4l[792724.068]: master offset   -1571854 s2 freq -178525 path delay      1188
ptp4l[792725.068]: master offset    -523684 s2 freq  -74232 path delay   -348970

/Daniel

-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...] 
Sent: Thursday, June 18, 2015 4:20 AM
To: Daniel Le
Cc: Lin...@li...
Subject: Re: [Linuxptp-users] sanity_freq_limit

On Thu, Jun 18, 2015 at 07:18:53AM +0000, Daniel Le wrote:
> > On Jun 18, 2015, at 2:58 AM, Miroslav Lichvar <mli...@re...> wrote:
> > 
> >> On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
> >> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?
> > 
> > ptp4l should do that by default, it's set by the 
> > first_step_threshold option.
> 
> Somehow when my system clock is initially (for example after a reboot) off the GM time by a couple of minutes, the master offset is huge and ptp4l takes hours to converge.

That's odd. Can you post your ptp4l config and log when it starts?

--
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

[Keller, J. E <jac...@in...>]

On Wed, 2015-06-17 at 22:35 +0000, Daniel Le wrote:
> Hello,
> 

Hi,

> I have a couple of questions about the frequency limit. How much may 
> it be reasonably increased from the default of 200000000 (20%)? And 
> this parameter is only configurable via the config file. Is that 
> correct?
>  

The sanity_freq_limit shouldn't really be increased beyond 20%.
Especially most hardware doesn't really support larger frequency
offsets. Some might, but it's not really necessary.


As for the other issue with clock jump, make sure your
first_step_threshold is low enough that it will perform a jump. It
should be by default but if you wouldn't mind including your config
here, and the resulting output of ptp4l as suggested by Miroslav.

Regards,
Jake

> Thanks,
> Daniel
>  
> ---------------------------------------------------------------------
> ---------
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] sanity_freq_limit

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

On Thu, Jun 18, 2015 at 07:18:53AM +0000, Daniel Le wrote:
> > On Jun 18, 2015, at 2:58 AM, Miroslav Lichvar <mli...@re...> wrote:
> > 
> >> On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
> >> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?
> > 
> > ptp4l should do that by default, it's set by the first_step_threshold
> > option.
> 
> Somehow when my system clock is initially (for example after a reboot) off the GM time by a couple of minutes, the master offset is huge and ptp4l takes hours to converge.

That's odd. Can you post your ptp4l config and log when it starts?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

[Daniel Le <dan...@ex...>]

> On Jun 18, 2015, at 2:58 AM, Miroslav Lichvar <mli...@re...> wrote:
> 
>> On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
>> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?
> 
> ptp4l should do that by default, it's set by the first_step_threshold
> option.

Somehow when my system clock is initially (for example after a reboot) off the GM time by a couple of minutes, the master offset is huge and ptp4l takes hours to converge.

Thanks.

> 
>> I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?
> 
> Why do you need to increase it? 20% is a safe value for SW
> timestamping. If you see clockcheck warning messages, it's probably a
> bug in the kernel/driver. With HW timestamping a limit of a few
> hundreds of ppm should be enough to cover the frequency offset between
> a typical system clock and PTP clock.
> 
> -- 
> Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

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

On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?

ptp4l should do that by default, it's set by the first_step_threshold
option.

> I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?

Why do you need to increase it? 20% is a safe value for SW
timestamping. If you see clockcheck warning messages, it's probably a
bug in the kernel/driver. With HW timestamping a limit of a few
hundreds of ppm should be enough to cover the frequency offset between
a typical system clock and PTP clock.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

[Daniel Le <dan...@ex...>]

Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?

/Daniel

From: Daniel Le 
Sent: Wednesday, June 17, 2015 6:36 PM
To: Lin...@li...
Subject: [Linuxptp-users] sanity_freq_limit

Hello,

I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?

Thanks,
Daniel

[Linuxptp-users] sanity_freq_limit

[Daniel Le <dan...@ex...>]

Hello,

I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?

Thanks,
Daniel

[Linuxptp-users] linuxptp in Debian

[Tino M. <tin...@al...>]

Hi,

just in case anyone here uses Debian or a Debian based distribution and
didn't notice: linuxptp is now part of Debian unstable and testing.

https://packages.debian.org/search?keywords=linuxptp

Ubuntu already picked it up.

https://launchpad.net/ubuntu/+source/linuxptp/1.5-1

Regards,
Tino

Re: [Linuxptp-users] Does PTP require NTP?

[Richard C. <ric...@gm...>]

On Fri, Jun 12, 2015 at 05:18:57PM -0500, Robb wrote:
> I have two freshly installed machines that I am trying to sync the
> CLOCK_REALTIME between the two.  Do I need to have them get close in
> time using ntp before I can use PTP?

No.

> How far apart can the clocks be and still have PTP work?

You can correct any offset by letting ptp4l reset the clock (which is
the default setting).

> They currently have a difference of 36 seconds but ptp4l and phc2sys
> are both telling me <5uS.

The 36 second offset [1] is the result of a configuration error.  Your
system time is UTC but PTP uses the TAI time scale.  See the section
titled "TIME SCALE USAGE" in the phc2sys man page.

> Machine1 (master):
> sudo ptp4l -i eth1 -m -2 -q
> sudo phc2sys -s CLOCK_REALTIME -c eth1 -O 0 -u 60
> 
> Machine2:
> sudo ptp4l -i eth0 -m -2 -q -s
> sudo phc2sys -s eth0 -c CLOCK_REALTIME -w -u 60

If your network is not connected to the outside world WRT time, then
the TAI offset is not so important.  Just leave off the the "-O 0" on
the master node, since that is wrong in any case.

Thanks,
Richard

1. Actually I would expect 35 and not 36.

[Linuxptp-users] Does PTP require NTP?

[Robb <rba...@gm...>]

I have two freshly installed machines that I am trying to sync the
CLOCK_REALTIME between the two.  Do I need to have them get close in
time using ntp before I can use PTP?  How far apart can the clocks be
and still have PTP work?  They currently have a difference of 36
seconds but ptp4l and phc2sys are both telling me <5uS.

My setup is as follows:

Two CentOS 6.5 machines
2.6.32-504.8.1.el6.x86_64
linuxptp-1.3-1.el6.x86_64

Machine1 eth1 [igb    5.0.5-k] Intel I210 (rev 03)
Machine2 eth0 [e1000e 3.1.0.2] Intel I217-LM (rev 05)
(slightly modifed e1000
http://blog.gmane.org/gmane.comp.linux.ptp.user/month=20150601)

Machine1 eth1 hooked directly to Machine2 eth0

Machine1 (master):
sudo ptp4l -i eth1 -m -2 -q
sudo phc2sys -s CLOCK_REALTIME -c eth1 -O 0 -u 60

Machine2:
sudo ptp4l -i eth0 -m -2 -q -s
sudo phc2sys -s eth0 -c CLOCK_REALTIME -w -u 60


Thanks.

Re: [Linuxptp-users] spelling errors

[Richard C. <ric...@gm...>]

On Tue, Jun 02, 2015 at 04:20:05PM +0200, IOhannes m zmölnig wrote:
> attached are two git patches that fix these problems.

Can you please resend with each patch in its own plain text email?

> PS: i hope it is ok to use this list for these kind of messages; but
> there is no bug tracker on the sf page; and there are no other mailing
> lists announced.

We do have a -devel list for this kind of thing. See:

   http://linuxptp.sourceforge.net

> btw, if i click on [1] i am directed to [2], which gives me a 403-error;
> maybe the "support" section could be made a bit more welcoming :-)

Yes, that is an automatic SF page, and I am sorry that I cannot fix it.

Thanks,
Richard

[Linuxptp-users] spelling errors

[IOhannes m z. <zmo...@ie...>]

while packaging linuxptp for debian, we found a few minor spelling errors:

cmf.c: prints MANAGMENT instead of MANAGEMENT

manpages (ptp4l.8, timemaster.8): confuses minus- and hyphen-signs.
in groff, the '-' is rendered as a hyphen, if we want a real minus we
need to write '\-'.
mostly the manpages are correct, but there are some exceptions (e.g.
"-128", where we really want a minus)

attached are two git patches that fix these problems.

mgfards
IOhannes

PS: i hope it is ok to use this list for these kind of messages; but
there is no bug tracker on the sf page; and there are no other mailing
lists announced.
btw, if i click on [1] i am directed to [2], which gives me a 403-error;
maybe the "support" section could be made a bit more welcoming :-)


[1] https://sourceforge.net/projects/linuxptp/support
[2] https://sourceforge.net/p/linuxptp/mailman

Re: [Linuxptp-users] Wildly jumping offsets casued by phc2sys

[Keller, J. E <jac...@in...>]

Ah. I was about to forward you to Yanir when I saw this email. I believe
the e1000e team is currently working on validating a release that can be
put on sourceforge which will include this fix.

Regards,
Jake

On Mon, 2015-06-01 at 10:42 -0500, Robb wrote:
> Yanir at:
> https://sourceforge.net/p/e1000/mailman/message/34158396/
> was able to help me with this problem.
> 
> He provided me with a patch to get this working.
> I have tested it and it has been working for > hour with
> no errors!
> 
> Here is a the patch + what I did in case it helps anyone else.
> 
> wget -O e1000e-3.1.0.2.tar.gz
> "http://sourceforge.net/projects/e1000/files/e1000e%20stable/3.1.0.2/e1000e-3.1.0.2.tar.gz/download"
> tar xvf e1000e-3.1.0.2.tar.gz
> cd e1000e-3.1.0.2/src; patch < ../../fix_systim_issues-3.1.0.2.patch
> sudo make install
> 
> $ cat fix_systim_issues-3.1.0.2.patch
> --- netdev.c.orig 2015-06-01 16:49:37.802312304 +0300
> +++ netdev.c 2015-06-01 16:51:19.468306452 +0300
> @@ -4614,7 +4614,10 @@ static cycle_t e1000e_cyclecounter_read(
>   cycle_t systim, systim_next;
> 
>   /* latch SYSTIMH on read of SYSTIML */
> - systim = (cycle_t)er32(SYSTIML);
> + u32 systim_overflow_latch_fix = 0x3FFFFFFF;
> + do {
> + systim = (cycle_t)er32(SYSTIML);
> + } while (systim > systim_overflow_latch_fix);
>   systim |= (cycle_t)er32(SYSTIMH) << 32;
> 
>   if ((hw->mac.type == e1000_82574) || (hw->mac.type == e1000_82583)) {
> 
> 
> 
> I apologize, my email composer (gmail) seems to delete the tabs in the patch.
> 
> 
> 
> On Sat, May 30, 2015 at 12:11 AM, Richard Cochran
> <ric...@gm...> wrote:
> > On Fri, May 29, 2015 at 04:59:29PM -0500, Robb wrote:
> >> For whatever reason phc2sys seems to be blowing up the offsets.
> >>
> >> My set up is as follows:
> >>
> >> Two CentOS 6.5 machines
> >> 2.6.32-504.16.2.el6.x86_64
> >> linuxptp-1.3-1.el6.x86_64
> >>
> >> Machine1 eth1 [igb    5.0.5-k]    Intel I210 (rev 03)
> >> Machine2 eth0 [e1000e 2.3.2-k] Intel I217-LM (rev 05)
> >
> > The I217-LM has a known HW bug.
> >
> >> I have read that there was some problems with the e1000e driver so I tried with
> >> the 3.1.0.2-NAPI version, but still have the same problem as above.
> >>
> >> Does anyone have any ideas what could be the problem here?
> >
> > This isn't a driver problem but rather a HW bug.  I don't have that HW,
> > and I have not yet heard of any SW (driver) work arounds.  You might
> > ask on the e1000e list if Intel has a solution to this problem.
> >
> > Thanks,
> > Richard
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Wildly jumping offsets casued by phc2sys

[Robb <rba...@gm...>]

Yanir at:
https://sourceforge.net/p/e1000/mailman/message/34158396/
was able to help me with this problem.

He provided me with a patch to get this working.
I have tested it and it has been working for > hour with
no errors!

Here is a the patch + what I did in case it helps anyone else.

wget -O e1000e-3.1.0.2.tar.gz
"http://sourceforge.net/projects/e1000/files/e1000e%20stable/3.1.0.2/e1000e-3.1.0.2.tar.gz/download"
tar xvf e1000e-3.1.0.2.tar.gz
cd e1000e-3.1.0.2/src; patch < ../../fix_systim_issues-3.1.0.2.patch
sudo make install

$ cat fix_systim_issues-3.1.0.2.patch
--- netdev.c.orig 2015-06-01 16:49:37.802312304 +0300
+++ netdev.c 2015-06-01 16:51:19.468306452 +0300
@@ -4614,7 +4614,10 @@ static cycle_t e1000e_cyclecounter_read(
  cycle_t systim, systim_next;

  /* latch SYSTIMH on read of SYSTIML */
- systim = (cycle_t)er32(SYSTIML);
+ u32 systim_overflow_latch_fix = 0x3FFFFFFF;
+ do {
+ systim = (cycle_t)er32(SYSTIML);
+ } while (systim > systim_overflow_latch_fix);
  systim |= (cycle_t)er32(SYSTIMH) << 32;

  if ((hw->mac.type == e1000_82574) || (hw->mac.type == e1000_82583)) {



I apologize, my email composer (gmail) seems to delete the tabs in the patch.



On Sat, May 30, 2015 at 12:11 AM, Richard Cochran
<ric...@gm...> wrote:
> On Fri, May 29, 2015 at 04:59:29PM -0500, Robb wrote:
>> For whatever reason phc2sys seems to be blowing up the offsets.
>>
>> My set up is as follows:
>>
>> Two CentOS 6.5 machines
>> 2.6.32-504.16.2.el6.x86_64
>> linuxptp-1.3-1.el6.x86_64
>>
>> Machine1 eth1 [igb    5.0.5-k]    Intel I210 (rev 03)
>> Machine2 eth0 [e1000e 2.3.2-k] Intel I217-LM (rev 05)
>
> The I217-LM has a known HW bug.
>
>> I have read that there was some problems with the e1000e driver so I tried with
>> the 3.1.0.2-NAPI version, but still have the same problem as above.
>>
>> Does anyone have any ideas what could be the problem here?
>
> This isn't a driver problem but rather a HW bug.  I don't have that HW,
> and I have not yet heard of any SW (driver) work arounds.  You might
> ask on the e1000e list if Intel has a solution to this problem.
>
> Thanks,
> Richard

Re: [Linuxptp-users] Wildly jumping offsets casued by phc2sys

[Richard C. <ric...@gm...>]

On Fri, May 29, 2015 at 04:59:29PM -0500, Robb wrote:
> For whatever reason phc2sys seems to be blowing up the offsets.
> 
> My set up is as follows:
> 
> Two CentOS 6.5 machines
> 2.6.32-504.16.2.el6.x86_64
> linuxptp-1.3-1.el6.x86_64
> 
> Machine1 eth1 [igb    5.0.5-k]    Intel I210 (rev 03)
> Machine2 eth0 [e1000e 2.3.2-k] Intel I217-LM (rev 05)

The I217-LM has a known HW bug.

> I have read that there was some problems with the e1000e driver so I tried with
> the 3.1.0.2-NAPI version, but still have the same problem as above.
> 
> Does anyone have any ideas what could be the problem here?

This isn't a driver problem but rather a HW bug.  I don't have that HW,
and I have not yet heard of any SW (driver) work arounds.  You might
ask on the e1000e list if Intel has a solution to this problem.

Thanks,
Richard

Re: [Linuxptp-users] Wildly jumping offsets casued by phc2sys

[Richard C. <ric...@gm...>]

On Fri, May 29, 2015 at 03:23:50PM -0700, Gary E. Miller wrote:
> 
> I have the same problem with hardware sync.  There was a discussion on
> linuxptp-devel on this last May, but since the email archives seem to be
> down right now I can't point you at it.

The SF archives are unusable, IMHO, even when they are up.  Use gmane
instead.  The link to the discussion is:

   http://thread.gmane.org/gmane.comp.linux.ptp.devel/2494/

Thanks,
Richard

Re: [Linuxptp-users] Wildly jumping offsets casued by phc2sys

[Gary E. M. <ge...@re...>]

Yo Robb!

On Fri, 29 May 2015 15:23:50 -0700
"Gary E. Miller" <ge...@re...> wrote:

> There was a discussion on linuxptp-devel on this last May,

Whoops, I meant March.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	ge...@re...  Tel:+1(541)382-8588

Re: [Linuxptp-users] Wildly jumping offsets casued by phc2sys

[Gary E. M. <ge...@re...>]

Yo Robb!

On Fri, 29 May 2015 16:59:29 -0500
Robb <rba...@gm...> wrote:

> For whatever reason phc2sys seems to be blowing up the offsets.

I have the same problem with hardware sync.  There was a discussion on
linuxptp-devel on this last May, but since the email archives seem to be
down right now I can't point you at it.

https://sourceforge.net/p/linuxptp/mailman/linuxptp-devel/

> Does anyone have any ideas what could be the problem here?

Seemingly not.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	ge...@re...  Tel:+1(541)382-8588

[Linuxptp-users] Wildly jumping offsets casued by phc2sys

[Robb <rba...@gm...>]

For whatever reason phc2sys seems to be blowing up the offsets.

My set up is as follows:

Two CentOS 6.5 machines
2.6.32-504.16.2.el6.x86_64
linuxptp-1.3-1.el6.x86_64

Machine1 eth1 [igb    5.0.5-k]    Intel I210 (rev 03)
Machine2 eth0 [e1000e 2.3.2-k] Intel I217-LM (rev 05)

Machine1 eth1 hooked directly to Machine2 eth0

Machine1 (master):
sudo ptp4l -i eth1 -m -2
sudo phc2sys -s eth1 -c CLOCK_REALTIME -w

Machine2:
sudo ptp4l -i eth0 -m -2
sudo phc2sys -s eth0 -c CLOCK_REALTIME -w

Normally the offset blows up immediately unless I sync the machines with NTP
before doing anything else.  If I do get them to sync it doesn't last very
long and the following will happen on Machine2:

16:30:03 ptp4l: [4679.655] master offset        777 s2 freq   +4403
path delay     67209
16:30:04 phc2sys: [4679.935] sys offset      -658 s2 freq   +3877 delay   1836
16:30:04 ptp4l: [4680.655] master offset       2280 s2 freq   +6139
path delay     67209
16:30:05 phc2sys: [4680.936] sys offset      1353 s2 freq   +5690 delay   1504
16:30:05 ptp4l: [4681.655] master offset      -1349 s2 freq   +3194
path delay     67123
16:30:06 phc2sys: [4681.936] sys offset    -14484 s2 freq   -9741 delay   1840
16:30:06 ptp4l: [4682.656] master offset 70368744179084 s2 freq
+599999999 path delay     67123
16:30:07 phc2sys: [4682.936] sys offset -70368575979115 s2 freq
-500000 delay   1440
16:30:07 ptp4l: [4683.656] master offset 70368127382914 s2 freq
+599999999 path delay  17621798
16:30:08 phc2sys: [4683.936] sys offset -70367975616192 s2 freq
-500000 delay   1842
16:30:08 ptp4l: [4684.657] master offset 70367522033588 s2 freq
+599999999 path delay  22920656
16:30:09 phc2sys: [4684.937] sys offset -70367375237559 s2 freq
-500000 delay   1441


I have read that there was some problems with the e1000e driver so I tried with
the 3.1.0.2-NAPI version, but still have the same problem as above.

Does anyone have any ideas what could be the problem here?

Thanks.

Re: [Linuxptp-users] I am trying to get PTP to work over an interesting network topology.

[Robb <rba...@gm...>]

I attempted to enable UDP multicast by setting
net.ipv4.all.rp_filter = 0
in /etc/sysctrl.conf with no luck

However, I used your suggestion to use layer 2 and it did "just work"
which is really nice.  It is also really refreshing to see a mailing list
responded to so quickly, and with such accurate and helpful information.

Thank you very much.

-Robb





On Tue, May 26, 2015 at 3:53 PM, Richard Cochran
<ric...@gm...> wrote:
> On Tue, May 26, 2015 at 03:29:01PM -0500, Robb wrote:
>> I am having trouble getting PTP to work over a network bridge br0.
>
> I have not tried PTP over a Linux SW bridge, and I am not sure if the
> kernel stack will play along.  In my experience, Linux SW bridging is
> a bit flakey.
>
> (PTP *does* work over tun/tap, but only after I patched the kernel.)
>
>> So what is the bridge messing up? And is there a way to fix it?
>
> The default transport is multicast UDP.  Maybe the SW bridge is
> dropping multicast.  Run wireshark on the end points to see if the PTP
> messages are getting through.
>
>> I would appreciate any insight I can get.  Even if it is a suggestion for a
>> better topology.
>
> One easy thing to try is Layer2 transport:
>
>    ptp4l -i eth0 -m -q -2
>
> This doesn't require the stack to join the multicast group, and so
> maybe it will "just work."
>
> HTH,
> Richard

Re: [Linuxptp-users] I am trying to get PTP to work over an interesting network topology.

[Richard C. <ric...@gm...>]

On Tue, May 26, 2015 at 03:29:01PM -0500, Robb wrote:
> I am having trouble getting PTP to work over a network bridge br0.

I have not tried PTP over a Linux SW bridge, and I am not sure if the
kernel stack will play along.  In my experience, Linux SW bridging is
a bit flakey.

(PTP *does* work over tun/tap, but only after I patched the kernel.)
 
> So what is the bridge messing up? And is there a way to fix it?

The default transport is multicast UDP.  Maybe the SW bridge is
dropping multicast.  Run wireshark on the end points to see if the PTP
messages are getting through.

> I would appreciate any insight I can get.  Even if it is a suggestion for a
> better topology.

One easy thing to try is Layer2 transport:

   ptp4l -i eth0 -m -q -2

This doesn't require the stack to join the multicast group, and so
maybe it will "just work."

HTH,
Richard

[Linuxptp-users] I am trying to get PTP to work over an interesting network topology.

[Robb <rba...@gm...>]

I am having trouble getting PTP to work over a network bridge br0.

They are both CentOS 6.5 machines with 2.6.32-504.8.1.el6.x86_64, and running
linuxptp-1.3-1.el6.x86_64.

Each machine has two NICS.
eth0 [e1000e] Intel I217-LM (rev 05)
eth1 [igb]    Intel I210 (rev 03)


Here is the topology:

Machine1:
br0  192.168.2.1
  -bridges both wlan0 and eth1
  -has a dhcp server running on it.
eth0 192.168.1.17
  -gets it's ip from LAN
eth1
  -connected to eth0 on machine 2
wlan0
  -provides a Wifi Access point to the 192.168.2.* network

Machine2:
eth0 192.168.2.7
  -connected directly to eth1 on Machine1
  -gets its IP from Machine1's dhcp server
eth1 down


What I would like to do is do the following:
[Machine1 ~]# ptp4l -i eth1 -m
[Machine2 ~]# ptp4l -i eth0 -m

I changed the default route on Machine1 and can visually see in iptraf-ng that
the ptp packets are going to 192.168.2.*  and while the machine happily detects
master and slave at first, nothing else happens, the Machine2 assumes grand
master role..

[Machine1 ~]# ptp4l -i eth1 -m
ptp4l[2847.269]: selected /dev/ptp1 as PTP clock
ptp4l[2847.271]: driver changed our HWTSTAMP options
ptp4l[2847.271]: tx_type   1 not 1
ptp4l[2847.271]: rx_filter 1 not 12
ptp4l[2847.271]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[2847.271]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[2853.271]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2853.271]: selected best master clock d05099.fffe.09aaf4
ptp4l[2853.271]: assuming the grand master role

[Machine2 ~]# ptp4l -i eth0 -m
ptp4l[966.068]: selected /dev/ptp0 as PTP clock
ptp4l[966.075]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[966.075]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[967.756]: port 1: new foreign master d05099.fffe.09aaf4-1
ptp4l[971.756]: selected best master clock d05099.fffe.09aaf4
ptp4l[971.757]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1191.765]: port 1: UNCALIBRATED to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1191.765]: selected best master clock d05099.fffe.5df7e6
ptp4l[1191.765]: assuming the grand master role


iptables is down on both machines.
Works fine (as expected) with NO bridge when Machine1:eth1 192.168.2.1 (master)
and Machine2:eth0 192.168.2.7 (slave).

So what is the bridge messing up? And is there a way to fix it?

I would appreciate any insight I can get.  Even if it is a suggestion for a
better topology.

Thanks,

Robb

Re: [Linuxptp-users] Linuxptp: clock jumps

[Richard C. <ric...@gm...>]

On Wed, May 06, 2015 at 06:27:38PM +0000, Keller, Jacob E wrote:
> You don't by chance still have that email? I am trying to find it in the
> archive..

Here it is:

  http://article.gmane.org/gmane.comp.linux.ptp.devel/2503

Cheers,
Richard