Thanks Richard. I saw your email and found the relevant sections of the
documentation [ts2phc.8]. Now I have more questions. A consequence of the
clock device I'm using is that I need to poll and read the timestamp on
/dev/pps0, but actually adjust /dev/ptp0. They timestamp on /dev/pps0 is the
system time of the occurrence of the 1pps pulse. I used the pps-tools method
[as in ppstest.c here: https://github.com/redlab-i/pps-tools ] to read the time
mark message from the receiver. This contains the UTC time of the 1pps pulse.
We configured ptp4l to run off of /dev/ptp0. When the board boots, both the
system clock and the gianfar clock on the board [/dev/ptp0], start at 0, and
consequently, appear to run from the unix epoch. I have receiver issues, so my
timestamps are spurious. When I do get a valid timestamp from the receiver, I
see ptp time across the system update, but the local processor time remains
where it was relative to the epoch.
I tried running phc2sys to synch the processor clock with the phc, by running
it: phc2sys -r -O 0 -s /dev/ptp0 but this had no effect. The usage statement
in phc2sys.c does not indicate that the -a and -r, but the documentation [now
that I'm looking at it] seems to say that -r is only valid in conjunction with
-a. I'm fuzzy on how getopts works, so I can't judge anything from that line
in the code. Since I need to point phc2sys at /dev/ptp0 as its master clock, I
was not sure that autoconfiguration was valid. Do I need to update my
invocation to `phc2sys -ar -O 0 -s /dev/ptp0`, or do I require some other
configuration?
Thanks!
-- David
-----Original Message-----
From: Richard Cochran <richardcoch...@gmail.com>
Sent: Friday, January 15, 2021 12:31 PM
To: Coughlin, David S (US) <david.s.cough...@lmco.com>
Cc: linuxptp-users@lists.sourceforge.net
Subject: EXTERNAL: Re: [Linuxptp-users] Start cold
On Fri, Jan 15, 2021 at 11:32:47AM +0000, Coughlin, David S wrote:
> I'm using an Extreme Engineering XPort 3200 grandmaster clock in my
> system. It expects to get its base timing signal from a 1PPS signal
> driven by an ICD-GPS-153 compliant receiver, and publish it via ptp.
> I had to work out an upstream replacement for the stock ts2phc, and as
> I fix my last bugs on that I have a question about its behavior.
> When the board comes up cold, the clock just runs from zero in both
> the phc clock and system clock on the board. The current UTC time is
> a long way from zero. Will ts2phc try to steer it to current time, or
> will it recognize that there is a big gap, and just reset the phc
> clock? Likewise, will phc2sys steer the system clock or jump it?
All of the programs that have a servo, ptp4l, phc2sys, and ts2phc, accept
configuration options that control the stepping behavior.
step_threshold
The maximum offset the servo will correct by changing the clock
frequency instead of stepping the clock. When set to 0.0, the
servo will never step the clock except on start. It's specified
in seconds. The default is 0.0. This option used to be called
pi_offset_const.
first_step_threshold
The maximum offset the servo will correct by changing the clock
frequency instead of stepping the clock. This is only applied on
the first update. It's specified in seconds. When set to 0.0,
the servo won't step the clock on start. The default is 0.00002
(20 microseconds). This option used to be called pi_f_off-
set_const.
HTH,
Richard
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
