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

Re: [Linuxptp-users] About ptp4l sync completed time

[Takahiro S. <tsh...@gm...>]

Hello Keller,

Thank you for the suggestion.

I doubted the wrong part.
Now the sync completion time is fine by the latest ptp4l.

Thanks and Best regards,
Takahiro Shimizu
2012/3/10 Keller, Jacob E <jac...@in...>

>  ** **
>
> ** **
>
> *From:* Takahiro Shimizu [mailto:tsh...@gm...]
> *Sent:* Friday, March 09, 2012 1:34 AM
> *To:* Richard Cochran; lin...@li...
> *Subject:* Re: [Linuxptp-users] About ptp4l sync completed time****
>
> ** **
>
> Hello Richard,
>
> Thank you for the reply.****
>
> ** **
>
> No, it is not normal.
>
> With hardware time stamping, you should get withn 0.1 usec in about
> one or two minutes.****
>
>  ** **
>
> OK. I see. I will check the driver again.****
>
> ** **
>
> Here is the result of ptp4l.****
>
> After 5 sec, master offset is decreasing gradually.****
>
> I doubt the part of adjust in the ptp driver now.****
>
> ** **
>
> time (sec)       master offset (ns)        adj       path delay (ns)****
>
> 1        60830880        0          5664****
>
> :****
>
> : <snip>****
>
> :****
>
> 4420  -20       32758513        2964****
>
> 4421  -54       32758473        2966****
>
>   ****
>
> > 2. Can I speed up the time till sync completed?
>
> The clock servo (in pi.c) has a PI controller, and its constants do
> affect the convergence performance.
>
> However, I think you have errors in the time stamps, or missing time
> stamps.
>
> HTH,
> Richard****
>
>  I see. I will check it too.****
>
> ** **
>
> Thanks and Best regards,****
>
> Takahiro Shimizu****
>
> ** **
>
> I would suggest looking into your clock rate adjustment function. This is
> where the driver should be tuning the frequency of the clock. It might be
> possible that you aren’t adjusting it correctly.****
>
> ** **
>
> However, I should note that with my testing, different values in the PI
> servo can have a fair impact on convergence times. You might play around
> with those and see what kind of impact it has. I don’t think changing those
> alone will be enough but it might help you find the cause of the issue.***
> *
>

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

[Takahiro S. <tsh...@gm...>]

Hello Richard,

I tried the latest linuxptp.

The sync completion time is fine and it is robust even if the timestamp
sometimes gets fail.
I can see "received SYNC without timestamp" and "port 1: bad message"
sometimes.

Thanks and Best regards,
2012/3/12 Takahiro Shimizu <tsh...@gm...>

> Hello Richard,
>
> Thank you. I'll try the latest one today.
>
> 2012/3/12 Richard Cochran <ric...@gm...>
>
>> I went ahead and pushed a fix for this issue, so please just try the
>> latest git version of linuxptp (7421e74a).
>>
>> Thanks,
>> Richard
>>
>
> Best regards,
>
> Takahiro Shimizu
>

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

[Takahiro S. <tsh...@gm...>]

Hello Richard,

Thank you. I'll try the latest one today.

2012/3/12 Richard Cochran <ric...@gm...>

> I went ahead and pushed a fix for this issue, so please just try the
> latest git version of linuxptp (7421e74a).
>
> Thanks,
> Richard
>

Best regards,

Takahiro Shimizu

Re: [Linuxptp-users] The ptp4l is not sync sometimes.

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

On Fri, Mar 09, 2012 at 10:55:38AM +0900, Takahiro Shimizu wrote:
> > > 2. Is my modification correct?
> >
> > A better fix is to drop event packets with missing time stamps in
> > port.c.

This also is now implemented in the lastest git linuxptp.

Thanks,
Richard

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

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

I went ahead and pushed a fix for this issue, so please just try the
latest git version of linuxptp (7421e74a).

Thanks,
Richard

Re: [Linuxptp-users] The ptp4l is not sync sometimes.

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

On Fri, Mar 09, 2012 at 10:55:38AM +0900, Takahiro Shimizu wrote:
> > > 2. Is my modification correct?
> >
> > A better fix is to drop event packets with missing time stamps in
> > port.c.
> 

The ptp4l program should really complain about missing time stamps on
event messages. This will make the synchronization more robust and
will help you track down your driver/hw issues.  Please try the
following patch.

Thanks,
Richard

---

diff --git a/msg.c b/msg.c
index e51bcbe..b3e5bf1 100644
--- a/msg.c
+++ b/msg.c
@@ -23,6 +23,7 @@
 #include <asm/byteorder.h>
 
 #include "msg.h"
+#include "print.h"
 
 #define VERSION_MASK 0x0f
 #define VERSION      0x02
@@ -192,6 +193,12 @@ int msg_post_recv(struct ptp_message *m, int cnt)
 	default:
 		return -1;
 	}
+
+	if (msg_sots_missing(m)) {
+		pr_err("received %s without timestamp", msg_type_string(type));
+		return -1;
+	}
+
 	return 0;
 }
 
@@ -273,3 +280,24 @@ void msg_put(struct ptp_message *m)
 	if (!m)
 		TAILQ_INSERT_HEAD(&msg_pool, m, list);
 }
+
+int msg_sots_missing(struct ptp_message *m)
+{
+	int type = msg_type(m);
+	switch (type) {
+	case SYNC:
+	case DELAY_REQ:
+	case PDELAY_REQ:
+	case PDELAY_RESP:
+		break;
+	case FOLLOW_UP:
+	case DELAY_RESP:
+	case PDELAY_RESP_FOLLOW_UP:
+	case ANNOUNCE:
+	case SIGNALING:
+	case MANAGEMENT:
+	default:
+		return 0;
+	}
+	return (!m->hwts.ts.tv_sec && !m->hwts.ts.tv_nsec) ? 1 : 0;
+}
diff --git a/msg.h b/msg.h
index fab5907..89d99e0 100644
--- a/msg.h
+++ b/msg.h
@@ -237,6 +237,13 @@ void msg_print(struct ptp_message *m, FILE *fp);
 void msg_put(struct ptp_message *m);
 
 /**
+ * Test whether an event message received a valid SO_TIMESTAMPING time stamp.
+ * @param m  Message to test.
+ * @return   One if the message is an event without a time stamp, zero otherwise.
+ */
+int msg_sots_missing(struct ptp_message *m);
+
+/**
  * Test whether a message is one-step message.
  * @param m  Message to test.
  * @return   One if the message is a one-step, zero otherwise.
diff --git a/port.c b/port.c
index 82c6166..978fca3 100644
--- a/port.c
+++ b/port.c
@@ -356,6 +356,10 @@ static int port_delay_request(struct port *p)
 		pr_err("port %hu: send delay request failed", portnum(p));
 		goto out;
 	}
+	if (msg_sots_missing(msg)) {
+		pr_err("missing timestamp on transmitted delay request");
+		goto out;
+	}
 
 	if (p->delay_req)
 		msg_put(p->delay_req);
@@ -466,6 +470,11 @@ static int port_tx_sync(struct port *p)
 		err = -1;
 		goto out;
 	}
+	if (msg_sots_missing(msg)) {
+		pr_err("missing timestamp on transmitted sync");
+		err = -1;
+		goto out;
+	}
 
 	/*
 	 * Send the follow up message right away.

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

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

On Fri, Mar 09, 2012 at 11:30:17PM +0900, Takahiro Shimizu wrote:
> Hello Richard,
> 
> Thank you for the information.
> 
> Please forget what I said.
> >
> > I think I see the bug. I will send a patch to try out soon.
> >
> >
>  I will wait your patch.

I think you are sometimes not getting any time stamp at all, and this
causes the try_again loop to end without ever calling recvmsg()
successfully. When this happens, the control[] buffer contains
uninitialized data from the stack.

Can you please try the following patch?

Thanks,
Richard

---

diff --git a/udp.c b/udp.c
index 8a3dc7b..d097f98 100644
--- a/udp.c
+++ b/udp.c
@@ -257,6 +257,7 @@ static int receive(int fd, void *buf, int buflen,
 	struct msghdr msg;
 	struct timespec *ts = NULL;
 
+	memset(control, 0, sizeof(control));
 	memset(&msg, 0, sizeof(msg));
 	msg.msg_iov = &iov;
 	msg.msg_iovlen = 1;

Re: [Linuxptp-users] The ptp4l is not sync sometimes.

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

On Thu, Mar 08, 2012 at 04:22:37PM +0900, Takahiro Shimizu wrote:
> 
> I chedked t1, .. t4 value.
> t2 or t4 is 0 at the time.

Both t2 and t4 are the receive time stamps (slave and master).  I bet
your driver (or hardware) is dropping Rx time stamps.

Still, the ptp4l program should handle missing time stamps.  I will
send you a patch.

Thanks,

Richard

Re: [Linuxptp-users] About ptp4l sync completed time

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

From: Takahiro Shimizu [mailto:tsh...@gm...]
Sent: Friday, March 09, 2012 1:34 AM
To: Richard Cochran; lin...@li...
Subject: Re: [Linuxptp-users] About ptp4l sync completed time

Hello Richard,

Thank you for the reply.

No, it is not normal.

With hardware time stamping, you should get withn 0.1 usec in about
one or two minutes.

OK. I see. I will check the driver again.

Here is the result of ptp4l.
After 5 sec, master offset is decreasing gradually.
I doubt the part of adjust in the ptp driver now.

time (sec)       master offset (ns)        adj       path delay (ns)
1        60830880        0          5664
:
: <snip>
:
4420  -20       32758513        2964
4421  -54       32758473        2966

> 2. Can I speed up the time till sync completed?

The clock servo (in pi.c) has a PI controller, and its constants do
affect the convergence performance.

However, I think you have errors in the time stamps, or missing time
stamps.

HTH,
Richard
I see. I will check it too.

Thanks and Best regards,
Takahiro Shimizu

I would suggest looking into your clock rate adjustment function. This is where the driver should be tuning the frequency of the clock. It might be possible that you aren't adjusting it correctly.

However, I should note that with my testing, different values in the PI servo can have a fair impact on convergence times. You might play around with those and see what kind of impact it has. I don't think changing those alone will be enough but it might help you find the cause of the issue.

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

[Takahiro S. <tsh...@gm...>]

Hello Richard,

Thank you for the information.

Please forget what I said.
>
> I think I see the bug. I will send a patch to try out soon.
>
>
 I will wait your patch.

Thanks,
Takahiro Shimizu

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

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

On Fri, Mar 09, 2012 at 06:59:29PM +0900, Takahiro Shimizu wrote:
> Hello Richard,
> 
> Can you provide a hex dump of the control[] buffer and the values of
> >> 'struct msghdr msg' before and after the call to recvmsg?
> >>
> >
> > OK. I'll try it.
> >
> >
> 
> I am trying to dump them.
> However if I modify the source code to dump it, the issue is not happened.
> It depends on the time critically.
> I am continuing to try it. If I will be able to get the dump, I will send
> it.

Please forget what I said.

I think I see the bug. I will send a patch to try out soon.

Thanks,
Richard

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

[Takahiro S. <tsh...@gm...>]

Hello Richard,

Can you provide a hex dump of the control[] buffer and the values of
>> 'struct msghdr msg' before and after the call to recvmsg?
>>
>
> OK. I'll try it.
>
>

I am trying to dump them.
However if I modify the source code to dump it, the issue is not happened.
It depends on the time critically.
I am continuing to try it. If I will be able to get the dump, I will send
it.

Thanks,
Takahiro Shimizu

Re: [Linuxptp-users] About ptp4l sync completed time

[Takahiro S. <tsh...@gm...>]

Hello Richard,

Thank you for the reply.

No, it is not normal.
>
> With hardware time stamping, you should get withn 0.1 usec in about
> one or two minutes.
>

OK. I see. I will check the driver again.

Here is the result of ptp4l.
After 5 sec, master offset is decreasing gradually.
I doubt the part of adjust in the ptp driver now.

time (sec) master offset (ns) adj path delay (ns)
1 60830880 0 5664
2 60821056 0 5664
3 60813078 0 4202
4 60802764 0 5076
5 -6095222 -6095222 6086198
6 32729162 30900595 6086198
7 34621386 42611568 6086198
8 36350508 50000000 4348852
9 36340812 50000000 4348852
10 36874096 50000000 3805968
11 37286637 50000000 3383795
12 37614629 50000000 3046171
13 37604965 50000000 3046171
14 37595272 50000000 3046232
15 37585167 50000000 3046673
16 37575567 50000000 3046673
17 37565746 50000000 3046862
18 37556132 50000000 3046652
19 40587180 50000000 6164
20 40577580 50000000 6164
21 40567788 50000000 6292
22 40558188 50000000 6292
23 40548557 50000000 6259
24 40539149 50000000 6259
25 40529431 50000000 6121
26 40519704 50000000 6184
27 40510104 50000000 6184
28 40500567 50000000 6089
29 40491186 50000000 5806
30 40481616 50000000 5744
31 40471957 50000000 5771
32 40462424 50000000 5672
33 40453071 50000000 5617
34 40443239 50000000 5561
35 40433989 50000000 5179
:
:
:
4393 -123348 32673175 5364
4394 -37972 32721547 5364
4395 -948 32747179 5364
4396 10444 32758287 5364
4397 11048 32762024 5176
4398 7655 32761945 4889
4399 4199 32760786 4889
4400 1863 32759710 4921
4401 903 32759308 4921
4402 133 32758809 4667
4403 199 32758915 4313
4404 135 32758911 3961
4405 -57 32758759 3769
4406 -195 32758604 3683
4407 -291 32758450 3683
4408 268 32758922 3220
4409 -201 32758533 3241
4410 -209 32758465 3249
4411 5 32758616 3099
4412 -6 32758606 3014
4413 -121 32758490 3001
4414 -107 32758467 2987
4415 -11 32758531 2987
4416 -9 32758530 2985
4417 -36 32758500 2980
4418 44 32758569 2964
4419 -20 32758519 2964
4420 -20 32758513 2964
4421 -54 32758473 2966


> > 2. Can I speed up the time till sync completed?
>
> The clock servo (in pi.c) has a PI controller, and its constants do
> affect the convergence performance.
>
> However, I think you have errors in the time stamps, or missing time
> stamps.
>
> HTH,
> Richard
>
I see. I will check it too.

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] About ptp4l sync completed time

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

On Fri, Mar 09, 2012 at 11:30:15AM +0900, Takahiro Shimizu wrote:
> Hello,
> 
> I ran ptp4l around 12 hours.
> The hardware is Intel EG20T.
> The performance is fine.
> The master offset is around 30 (msec) at the beginning.
> And the master offset keeps in +- 1 (usec) after sync is completed.
> However it needs long time till the sync is completed.
> I needed 1 hour about it.
> 
> Question:
> 1. Is this the normal behaviour? Does it need so long time on other
> platforms?

No, it is not normal.

With hardware time stamping, you should get withn 0.1 usec in about
one or two minutes.

> 2. Can I speed up the time till sync completed?

The clock servo (in pi.c) has a PI controller, and its constants do
affect the convergence performance.

However, I think you have errors in the time stamps, or missing time
stamps.

HTH,
Richard

[Linuxptp-users] About ptp4l sync completed time

[Takahiro S. <tsh...@gm...>]

Hello,

I ran ptp4l around 12 hours.
The hardware is Intel EG20T.
The performance is fine.
The master offset is around 30 (msec) at the beginning.
And the master offset keeps in +- 1 (usec) after sync is completed.
However it needs long time till the sync is completed.
I needed 1 hour about it.

Question:
1. Is this the normal behaviour? Does it need so long time on other
platforms?
2. Can I speed up the time till sync completed?

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] The ptp4l is not sync sometimes.

[Takahiro S. <tsh...@gm...>]

Hello Richard,

Thank you for your response.

Yes, the hardware does have a limitation of dropping time stamps, and
> that stinks. The driver should try to read the time stamp ASAP. If
> dropped time stamps happens frequently, then you probably have a
> driver issue.
>
>
OK. It might be.


> I was able to use the IXP as a slave with a master sending one sync
> per second without any drop outs.
>
> What is your sync rate?
>

According to the capture of Wireshark, the sync rate is 1 second.
However sometimes Sync and FollowUp is sent shorter than 1 usec.
I think FollowUp message may be droped if the GbE driver is busy.


> > 2. Is my modification correct?
>
> A better fix is to drop event packets with missing time stamps in
> port.c.


Thank you. I will check it.

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

[Takahiro S. <tsh...@gm...>]

Hello Richard,

Thank you for the response.

What do you mean by "many data simultaneously"?
>

I connect 2 CrownBay(Intel E6xx CPU + Intel PCH EG20T) boards and 1 PC in
the same network.
I installed Linux kernel 3.3-rc6 on 2 CrownBays.
I installed Windows 7 on PC.
CrownBay-1 is a PTP master.
CrownBay-2 is a PTP slave.
Samba server is running on the CrownBay-2.
The ptp4l is running on the both CrownBay.
I mount the directory of CrownBay-2 on PC.
I copied many files between PC and CrwonBay-2 when I am running ptp4l.


> Wow, you have a lot of interfaces! ----+
>

I am testing many boards (with different MAC addresses) using the same HDD.
Therefore the interface is increased. :)

This is strange. It seems that the control buffer is corrupted.
>
> Did you modify the receive() function?
>

No, I didn't.


> Can you provide a hex dump of the control[] buffer and the values of
> 'struct msghdr msg' before and after the call to recvmsg?
>

OK. I'll try it.


> Yes, this issue appears when the driver is very slow to deliver a Tx
> time stamp.
>

I see.


> I think it is fine to increase the usleep time for testing, but you
> should find out why the time stamp is so slow.
>

I see.
This may be happened. The EG20T GbE DMA hardware is descriptor type DMA.
The GbE driver just assign the Tx buffer address to DMA descriptor. The
actual Tx is executed later.


> The better solution (for ptp4l) is to allow changing the value of
> 'try_again' as command line or config file option.
>

I think it seems better.

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] The ptp4l is not sync sometimes.

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

On Thu, Mar 08, 2012 at 04:22:37PM +0900, Takahiro Shimizu wrote:
... 
> I chedked t1, .. t4 value.
> t2 or t4 is 0 at the time.
> 
> ptp4l[20494]: negative path delay -45370388164880
> ptp4l[20494]: path_delay = (t2 - t3) + (t4 - t1)
> ptp4l[20494]: t2 - t3 = -90741482576736
> ptp4l[20494]: t4 - t1 = +706246976
> ptp4l[20494]: t1 = +90740776333280
> ptp4l[20494]: t2 =         +0
> ptp4l[20494]: t3 = +90741482576736
> ptp4l[20494]: t4 = +90741482580256
> ptp4l[20494]: c1          0
> ptp4l[20494]: c2          0
> ptp4l[20494]: c3          0
> 
> I think EG20T ieee1588 hardware is independent from the GbE hardware.
> The GbE driver get the timestamp from ieee1588 hardware.
> If the 2 PTP messages are received in short period and the GbE driver can
> not get the timestamp in fast response, the timestamp of 2nd message can
> not be locked and the value is 0.

Yes, the hardware does have a limitation of dropping time stamps, and
that stinks. The driver should try to read the time stamp ASAP. If
dropped time stamps happens frequently, then you probably have a
driver issue.

> So I modify the ptp4l as follows. Please see "TS add here".
> 
> ---
> void clock_path_delay(struct clock *c, struct timespec req, struct
> timestamp rx,
> :
> if (pd < 0) {
...
> return; // TS add here
> }
> 
> enum servo_state clock_synchronize(struct clock *c,
> :
> if ((origin != 0) && (ingress != 0)) // TS add here
> c->master_offset = tmv_sub(ingress,
> tmv_add(origin, tmv_add(c->path_delay, tmv_add(c->c1, c->c2))));
> 
> ---
> 
> This means if t1, .. t4 are 0, ptp4l will not update master_offset and
> path_delay.
> After modification, ptp4l is sync always with Intel EG20T hardware.
> 
> My questions are:
> 
> 1. Intel EG20T ieee1588 is similar ixp4xx. Did anyone face the similar
> issue?

I was able to use the IXP as a slave with a master sending one sync
per second without any drop outs.

What is your sync rate?

> 2. Is my modification correct?

A better fix is to drop event packets with missing time stamps in
port.c.


Richard

Re: [Linuxptp-users] ptp4l is dead with Segmentation Fault

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

On Thu, Mar 08, 2012 at 03:57:42PM +0900, Takahiro Shimizu wrote:
> Hello,
> 
> I am trying ptp4l with hardware clock.
> The ieee1588 hardware is Intel EG20T.
> The sync seems OK.
> However ptp4l is sometimes dead when we transfer many data simultaneously.

What do you mean by "many data simultaneously"?

> The error is Segmentation Fault.
> I checked coredump.
> Core was generated by `./ptp4l -i eth7 -m -v'.
                                       |
Wow, you have a lot of interfaces! ----+

> Program terminated with signal 11, Segmentation fault.
> #0  0x002a7f12 in __cmsg_nxthdr () from /lib/libc.so.6

This is strange. It seems that the control buffer is corrupted.

Did you modify the receive() function?

Can you provide a hex dump of the control[] buffer and the values of
'struct msghdr msg' before and after the call to recvmsg?

> The error is occured in receive function in udp.c.
> I assumed that errno == EAGAIN is happened many times.
> I tried usleep(1000); instead of usleep(1);
> 
> The result seems OK.
> My question are:
> 1. Did anyone face the same issue?

Yes, this issue appears when the driver is very slow to deliver a Tx
time stamp.

> 2. Is this modification correct?

I think it is fine to increase the usleep time for testing, but you
should find out why the time stamp is so slow.

The better solution (for ptp4l) is to allow changing the value of
'try_again' as command line or config file option.

HTH,
Richard

[Linuxptp-users] The ptp4l is not sync sometimes.

[Takahiro S. <tsh...@gm...>]

Hello,

I am trying ptp4l with Intel EG20T.
ptp4l is not sync sometimes, when we transfer many data simultaneously like
follwoing.

ptp4l[17353]: master offset          2 s2 adj +32755854 path delay
2942
ptp4l[17353]: master offset         31 s2 adj +32755883 path delay
2945
ptp4l[17353]: master offset        -33 s2 adj +32755828 path delay
2945
ptp4l[17353]: master offset         31 s2 adj +32755883 path delay
2945
ptp4l[17353]: master offset         -1 s2 adj +32755860 path delay
2945
ptp4l[17353]: master offset        -41 s2 adj +32755820 path delay
2953
ptp4l[17353]: master offset         -8 s2 adj +32755840 path delay
2952
ptp4l[17353]: master offset         56 s2 adj +32755902 path delay
2952
ptp4l[17353]: master offset        -14 s2 adj +32755849 path delay
2958
ptp4l[17353]: master offset -55176644235214 s2 adj -50000000 path delay
  2958
ptp4l[17353]: negative path delay -27588322110544
ptp4l[17353]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[17353]: t2 - t3 = -55177301241888
ptp4l[17353]: t4 - t1 = +657020800
ptp4l[17353]: c1          0
ptp4l[17353]: c2          0
ptp4l[17353]: c3          0
ptp4l[17353]: master offset 2758832199206 s2 adj +50000000 path delay
-2758832208390
ptp4l[17353]: master offset 2758832186448 s2 adj +50000000 path delay
-2758832207792
ptp4l[17353]: master offset 2758832174544 s2 adj +50000000 path delay
-2758832207792
ptp4l[17353]: master offset 2758832161990 s2 adj +50000000 path delay
-2758832207590
ptp4l[17353]: master offset 2758832149267 s2 adj +50000000 path delay
-2758832206995
ptp4l[17353]: master offset 2758832137072 s2 adj +50000000 path delay
-2758832206960
ptp4l[17353]: master offset 2758832124875 s2 adj +50000000 path delay
-2758832206891
ptp4l[17353]: master offset 2758832112171 s2 adj +50000000 path delay
-2758832206379
ptp4l[17353]: master offset 2758832100043 s2 adj +50000000 path delay
-2758832206379
ptp4l[17353]: master offset 2758832087416 s2 adj +50000000 path delay
-2758832205880
ptp4l[17353]: master offset    -136851 s2 adj +32619007 path delay
6259
ptp4l[17353]: master offset       -179 s2 adj +32714624 path delay
6259
ptp4l[17353]: negative path delay      -7904
ptp4l[17353]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[17353]: t2 - t3 = -507698240
ptp4l[17353]: t4 - t1 = +507682432
ptp4l[17353]: c1          0
ptp4l[17353]: c2          0
ptp4l[17353]: c3          0
ptp4l[17353]: negative path delay      -9136
ptp4l[17353]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[17353]: t2 - t3 = -566457632
ptp4l[17353]: t4 - t1 = +566439360
ptp4l[17353]: c1          0
ptp4l[17353]: c2          0
ptp4l[17353]: c3          0
ptp4l[17353]: master offset      44452 s2 adj +32759201 path delay
3164
ptp4l[17353]: master offset      40900 s2 adj +32768985 path delay
3164
ptp4l[17353]: master offset      28141 s2 adj +32768496 path delay
3795
ptp4l[17353]: master offset      15981 s2 adj +32764778 path delay
3795
ptp4l[17353]: master offset       6644 s2 adj +32760236 path delay
4204
ptp4l[17353]: master offset       2640 s2 adj +32758225 path delay
3856
ptp4l[17353]: master offset        272 s2 adj +32756649 path delay
3856
ptp4l[17353]: master offset        -11 s2 adj +32756447 path delay
3371
ptp4l[17353]: master offset       -201 s2 adj +32756254 path delay
2985
ptp4l[17353]: master offset       -233 s2 adj +32756162 path delay
2569
ptp4l[17353]: master offset      -1025 s2 adj +32755300 path delay
3105
ptp4l[17353]: master offset       -705 s2 adj +32755312 path delay
3105
ptp4l[17353]: master offset      -1126 s2 adj +32754680 path delay
4294
ptp4l[17353]: master offset        212 s2 adj +32755680 path delay
4140
ptp4l[17353]: master offset       1002 s2 adj +32756534 path delay
3542
ptp4l[17353]: master offset        727 s2 adj +32756559 path delay
3145
ptp4l[17353]: master offset        114 s2 adj +32756164 path delay
3022
ptp4l[17353]: master offset       -153 s2 adj +32755932 path delay
3033
ptp4l[17353]: master offset       -248 s2 adj +32755791 path delay
3032
ptp4l[17353]: master offset       -169 s2 adj +32755795 path delay
3017
ptp4l[17353]: master offset       -105 s2 adj +32755809 path delay
3017
ptp4l[17353]: master offset        -28 s2 adj +32755854 path delay
3004

I chedked t1, .. t4 value.
t2 or t4 is 0 at the time.

ptp4l[20494]: negative path delay -45370388164880
ptp4l[20494]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[20494]: t2 - t3 = -90741482576736
ptp4l[20494]: t4 - t1 = +706246976
ptp4l[20494]: t1 = +90740776333280
ptp4l[20494]: t2 =         +0
ptp4l[20494]: t3 = +90741482576736
ptp4l[20494]: t4 = +90741482580256
ptp4l[20494]: c1          0
ptp4l[20494]: c2          0
ptp4l[20494]: c3          0

I think EG20T ieee1588 hardware is independent from the GbE hardware.
The GbE driver get the timestamp from ieee1588 hardware.
If the 2 PTP messages are received in short period and the GbE driver can
not get the timestamp in fast response, the timestamp of 2nd message can
not be locked and the value is 0.

So I modify the ptp4l as follows. Please see "TS add here".

---
void clock_path_delay(struct clock *c, struct timespec req, struct
timestamp rx,
:
if (pd < 0) {
pr_warning("negative path delay %10lld", pd);
pr_warning("path_delay = (t2 - t3) + (t4 - t1)");
pr_warning("t2 - t3 = %+10lld", t2 - t3);
pr_warning("t4 - t1 = %+10lld", t4 - t1);
pr_warning("t1 = %+10lld", t1);
pr_warning("t2 = %+10lld", t2);
pr_warning("t3 = %+10lld", t3);
pr_warning("t4 = %+10lld", t4);
pr_warning("c1 %10lld", c1);
pr_warning("c2 %10lld", c2);
pr_warning("c3 %10lld", c3);
return; // TS add here
}

enum servo_state clock_synchronize(struct clock *c,
:
if ((origin != 0) && (ingress != 0)) // TS add here
c->master_offset = tmv_sub(ingress,
tmv_add(origin, tmv_add(c->path_delay, tmv_add(c->c1, c->c2))));

---

This means if t1, .. t4 are 0, ptp4l will not update master_offset and
path_delay.
After modification, ptp4l is sync always with Intel EG20T hardware.

My questions are:

1. Intel EG20T ieee1588 is similar ixp4xx. Did anyone face the similar
issue?
2. Is my modification correct?

Thanks and Best regards,
Takahiro Shimizu

[Linuxptp-users] ptp4l is dead with Segmentation Fault

[Takahiro S. <tsh...@gm...>]

Hello,

I am trying ptp4l with hardware clock.
The ieee1588 hardware is Intel EG20T.
The sync seems OK.
However ptp4l is sometimes dead when we transfer many data simultaneously.
The error is Segmentation Fault.
I checked coredump.

[root@Fedora14-LinuxTeam-dev linuxptp-code]# ./ptp4l -i eth7 -m -v
Segmentation fault (coredump)
[root@Fedora14-LinuxTeam-dev linuxptp-code]# gdb ptp4l core.21111
GNU gdb (GDB) Fedora (7.2-51.fc14)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/okada/work/ieee1588/test-app/linuxptp-code/ptp4l...done.
[New Thread 21111]
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install
/usr/lib/debug/.build-id/65/726c76f0ef4466fe3e7f4b0b78d51d49bf149b
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib/libpthread.so.0
Core was generated by `./ptp4l -i eth7 -m -v'.
Program terminated with signal 11, Segmentation fault.
#0  0x002a7f12 in __cmsg_nxthdr () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.13-1.i686
(gdb) where
#0  0x002a7f12 in __cmsg_nxthdr () from /lib/libc.so.6
#1  0x0804ec51 in receive (fd=9, buf=0xbff89258, buflen=44, hwts=0x9abe6e0,
    flags=8192) at udp.c:286
#2  0x0804edda in udp_send (fda=0x9a7b0e0, event=1, buf=0x9abe680, len=44,
    hwts=0x9abe6e0) at udp.c:343
#3  0x0804ca2c in port_delay_request (p=0x9a7b0d0) at port.c:354
#4  0x0804dd60 in port_event (p=0x9a7b0d0, fd_index=3) at port.c:886
#5  0x0804a3bb in clock_poll (c=0x8051360) at clock.c:316
#6  0x080493da in main (argc=5, argv=0xbff89ad4) at ptp4l.c:195
(gdb) q

The error is occured in receive function in udp.c.
I assumed that errno == EAGAIN is happened many times.
I tried usleep(1000); instead of usleep(1);

The result seems OK.
My question are:
1. Did anyone face the same issue?
2. Is this modification correct?

Thanks and Best regards,

Re: [Linuxptp-users] UtcOffset (leap seconds)

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Thursday, February 23, 2012 4:31 AM
> To: Keller, Jacob E
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] UtcOffset (leap seconds)
> 
> On Wed, Feb 22, 2012 at 11:35:40PM +0000, Keller, Jacob E wrote:
> 

> > Is it correct to not properly configure the ptp4l clock when it is
> > in fallback mode, or should it be changed to update the clock
> > settings when it goes to master mode as a fallback? Normally the
> > clock would go to grandmaster mode because there are no other clocks
> > on the network with higher priority.. But it never does this in
> > fallback mode, because it never receives an announce message at all.
> 
> I think the right thing would be to initialize the time properties in
> clock.tds in clock_create(). In that way, if a port enters into master
> state by default, the data set values will be correct.
> 
> I will add this soon (or please post a patch if you DIY).
> 
> Thanks,
> 
> Richard
> 

Yes this seems correct. I can probably make a patch if you haven't done it already.

Jake

Re: [Linuxptp-users] UtcOffset (leap seconds)

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

On Wed, Feb 22, 2012 at 11:35:40PM +0000, Keller, Jacob E wrote:

> I recently had ptp4l running with a symmetricom grandmaster Xli box
> which I am using as an interop test for ptp4l. I noticed something
> odd, when configuring the setup. The grandmaster clock can be in a
> "master only, no slave" mode or a "slave only, no master" mode. When
> in slave only mode, it causes ptp4l to automatically fall back to
> master setup.
>
> The ptp4l state machine then never runs the best master clock
> routine, and so it never sets up the UtcOffset value in the announce
> field. This causes the grand master clock to use the previously
> known utc offset which in this case is 34 seconds. This causes a
> delay of 34 seconds in the clocks. I discovered that the clock
> property fields only get set when in the grand master state, which
> it will *never* enter because it doesn't properly run the best
> master clock algorithm. (Since in this case there is no other
> announcer).
>
> I am not sure what the correct answer to this question should
> be. Under normal circumstances with other ptp4ls, the utc offset is
> ignored. This particular clock, though, cannot have the utc offset
> changed to something outside the -19/-40 range, so I cannot manually
> reset the offset to 0.
>
> Is it correct to not properly configure the ptp4l clock when it is
> in fallback mode, or should it be changed to update the clock
> settings when it goes to master mode as a fallback? Normally the
> clock would go to grandmaster mode because there are no other clocks
> on the network with higher priority.. But it never does this in
> fallback mode, because it never receives an announce message at all.

I think the right thing would be to initialize the time properties in
clock.tds in clock_create(). In that way, if a port enters into master
state by default, the data set values will be correct.

I will add this soon (or please post a patch if you DIY).

Thanks,

Richard

[Linuxptp-users] UtcOffset (leap seconds)

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

I recently had ptp4l running with a symmetricom grandmaster Xli box which I am using as an interop test for ptp4l. I noticed something odd, when configuring the setup. The grandmaster clock can be in a "master only, no slave" mode or a "slave only, no master" mode. When in slave only mode, it causes ptp4l to automatically fall back to master setup.

The ptp4l state machine then never runs the best master clock routine, and so it never sets up the UtcOffset value in the announce field. This causes the grand master clock to use the previously known utc offset which in this case is 34 seconds. This causes a delay of 34 seconds in the clocks. I discovered that the clock property fields only get set when in the grand master state, which it will *never* enter because it doesn't properly run the best master clock algorithm. (Since in this case there is no other announcer).

I am not sure what the correct answer to this question should be. Under normal circumstances with other ptp4ls, the utc offset is ignored. This particular clock, though, cannot have the utc offset changed to something outside the -19/-40 range, so I cannot manually reset the offset to 0.

Is it correct to not properly configure the ptp4l clock when it is in fallback mode, or should it be changed to update the clock settings when it goes to master mode as a fallback? Normally the clock would go to grandmaster mode because there are no other clocks on the network with higher priority.. But it never does this in fallback mode, because it never receives an announce message at all.

Thanks


-          Jake

Re: [Linuxptp-users] Software Based Timestamps does not work

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Saturday, February 18, 2012 12:06 AM
> To: Keller, Jacob E
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] Software Based Timestamps does not work
> 
> On Fri, Feb 17, 2012 at 11:38:40PM +0000, Keller, Jacob E wrote:
> 
> > When enabling software based timestamps via the '-s' switch, the
> > program switches to the faulty state instantly after transmitting a
> > packet that should be timestamped because the software timestamp is
> > never obtained. With further investigation, it turns out that
> > software timestamping appears to be disabled. I tested with the
> > kernel timestamping.c program, and indeed just selecting
> > sof_timestamping_tx_software, sof_timestamping_rx_software and
> > sof_timestamping_software does not return timestamps. The additional
> > option of sof_timestampns must also be enabled.
> 
> But that gets the time stamp using the legacy BSD loopback method.
> I did not support this in ptp4l because it only works on UDPv4
> packets.
> 
Hmm.. When I added SO_TIMESTAMPNS, the value did appear in the software timestamping. I'll take a look at the driver and see if that line is there. Thanks for the input. (I was not aware of that)