linuxptp-users

[Linuxptp-users] strange behavior with free_running regarding offset display

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

Hi Richard,

I get a strange behavior when using "free_running 1". The summary looks
like this:

$ ptp4l -f /etc/ptp4l.conf -i eth1 -m
ptp4l[3620445.368]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[3620445.368]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[3620445.600]: port 1: new foreign master 008063.fffe.b6706b-13
ptp4l[3620447.600]: selected best master clock 00606e.fffe.7c230f
ptp4l[3620447.600]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[3620448.515]: port 1: minimum delay request interval 2^3
ptp4l[3620452.600]: rms 34999153762 max 34999173342 freq -19583 +/-   2
delay  7694 +/- 246
ptp4l[3620456.599]: rms 34999231855 max 34999251436 freq -19587 +/-   3
delay  5256 +/-   0
ptp4l[3620460.599]: rms 34999309648 max 34999328697 freq -19591 +/-   8
delay  5141 +/-   0
ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq -19592 +/-   0
ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq -19595 +/-   7

Querying ptp4l using pmc gives this output (note the first
offsetFromMaster value):

$ pmc -u "get CURRENT_DATA_SET"
sending: GET CURRENT_DATA_SET
	001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET 
		stepsRemoved     2
		offsetFromMaster -35000968295.0
		meanPathDelay    5354.0
	008063.fffe.b6706b-13 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET 
		stepsRemoved     1
		offsetFromMaster -33.0
		meanPathDelay    87.4
	000b72.fffe.0585b6-1 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET 
		stepsRemoved     2
		offsetFromMaster -2.0
		meanPathDelay    3818.0

Everything is fine as soon as I use "free_running 0".

Regards,
Tino

Re: [Linuxptp-users] strange behavior with free_running regarding offset display

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

Tino,

On Wed, Jan 07, 2015 at 03:10:21PM +0100, Tino Keitel wrote:
> ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq -19592 +/-   0
> ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq -19595 +/-   7

Max here is always positive. It is the absolute value (magnitude) of
the maximum offset during the interval.
 
> Querying ptp4l using pmc gives this output (note the first
> offsetFromMaster value):
> 
> $ pmc -u "get CURRENT_DATA_SET"
> sending: GET CURRENT_DATA_SET
> 	001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET 
> 		stepsRemoved     2
> 		offsetFromMaster -35000968295.0

Here the plain offset is given.

Both values show the offset error to be about 35 seconds, which is the
TAI/UTC offset. Probably your PHC driver sets its time to the UTC
system time when loading.

HTH,
Richard

Re: [Linuxptp-users] strange behavior with free_running regarding offset display

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

On Wed, 2015-01-07 at 16:30 +0100, Richard Cochran wrote:
> Tino,
> 
> On Wed, Jan 07, 2015 at 03:10:21PM +0100, Tino Keitel wrote:
> > ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq -19592 +/-   0
> > ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq -19595 +/-   7
> 
> Max here is always positive. It is the absolute value (magnitude) of
> the maximum offset during the interval.
>  
> > Querying ptp4l using pmc gives this output (note the first
> > offsetFromMaster value):
> > 
> > $ pmc -u "get CURRENT_DATA_SET"
> > sending: GET CURRENT_DATA_SET
> > 	001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET 
> > 		stepsRemoved     2
> > 		offsetFromMaster -35000968295.0
> 
> Here the plain offset is given.
> 
> Both values show the offset error to be about 35 seconds, which is the
> TAI/UTC offset. Probably your PHC driver sets its time to the UTC
> system time when loading.

Hi Richard,

this sounds like it is normal behavior to show the offset to the PHC
even if the PHC is not touched (free_running set to 1).

Regards,
Tino

Re: [Linuxptp-users] strange behavior with free_running regarding offset display

[Holzinger, A. (A. N. GmbH) <Axe...@al...>]

On Wed, 2015-01-07 at 16:38 +0100, Tino Keitel wrote:
> On Wed, 2015-01-07 at 16:30 +0100, Richard Cochran wrote:
> > Tino,
> >
> > On Wed, Jan 07, 2015 at 03:10:21PM +0100, Tino Keitel wrote:
> > > ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq -
> > > 19592 +/-   0
> > > ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq -
> > > 19595 +/-   7
> >
> > Max here is always positive. It is the absolute value
> > (magnitude) of the maximum offset during the interval.
> >
> > > Querying ptp4l using pmc gives this output (note the first
> > > offsetFromMaster value):
> > >
> > > $ pmc -u "get CURRENT_DATA_SET"
> > > sending: GET CURRENT_DATA_SET
> > > 	001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT
> > >       CURRENT_DATA_SET
> > > 		stepsRemoved     2
> > > 		offsetFromMaster -35000968295.0
> >
> > Here the plain offset is given.
> >
> > Both values show the offset error to be about 35 seconds, which
> > is the TAI/UTC offset. Probably your PHC driver sets its time
> > to the UTC system time when loading.
> 
> Hi Richard,
> 
> this sounds like it is normal behavior to show the offset to the
> PHC even if the PHC is not touched (free_running set to 1).
> 
> Regards,
> Tino

Rchard, Tino et al.

Does it make sense to print the offset error of the PHC when it's free running?

This value will always increase as the PHC drifts away over time, if it's free running. Shouldn't the message contain the true offset after calculation with the software offset? IMHO in free running mode it doesn't matter at which position the PHC starts (with or without UTC offset or any other weird position like zero = 01/01/1970).

Just my 0.02€
Axel

Re: [Linuxptp-users] strange behavior with free_running regarding offset display

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

On Wed, Jan 07, 2015 at 03:48:24PM +0000, Holzinger, Axel  (ALC NetworX GmbH) wrote:
> Does it make sense to print the offset error of the PHC when it's free running?

(Sometimes it does ;)

1. I often use "free_running 1" with software time stamping to test my
   NTP performance against a local GPS GM clock.

2. When developing a GPS GM with hardware time stamping and a PHC, it
   is interesting to steer the PHC with the GPS PPS, and check the
   result with another GPS GM with ptp4l free running.

So YRMV with the free running error statistics. Sometimes they don't
make sense.

One new feature idea is programmable output strings... patches?

Thanks,
Richard

Re: [Linuxptp-users] strange behavior with free_running regarding offset display

[Holzinger, A. (A. N. GmbH) <Axe...@al...>]

On Wed, 2015-01-07 at 17:27 +0100, Richard Cochran wrote:
> So YRMV with the free running error statistics. Sometimes they
> don't make sense.

Thanks for the explanation. I think I remember that running in gPTP mode I didn't saw the huge (offset) numbers, so it might be that on this system the PHC was running on TAI initially.

> One new feature idea is programmable output strings... patches?

Good answer :-) Got us!

Well this would lead to additional configuration params I guess. We'll keep that in mind if we stumble over this another time. Using free running mode was just a test to see if results differ significantly.

Thanks a lot!
Axel