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