Hello,
by default, ptp4l sends its PTP announce messages with currentUtcOffset
set to 37 and currentUtcOffsetValid set to 0.
AFAICS, there is no configuration file pragma for setting
currentUtcOffsetValid to 1 to make sure that ptp4l is always sending
all announce messages with that value.
I know that one can dynamically change a ptp4l's currentUtcOffsetValid
value after startup, i.e. by sending a GRANDMASTER_SETTINGS_NP like
this:
pmc -d 23 -u -s /var/run/ptp4l -b0 'SET GRANDMASTER_SETTINGS_NP clockClass 13
clockAccuracy 0x21 offsetScaledLogVariance 0xffff
currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1
ptpTimescale 1 timeTraceable 1 frequencyTraceable 0
timeSource 0x20'
However, I'm curious, is this a deliberate design decision to not provide
a configuration setting for the currentUtcOffsetValid value, as well?
Or is such configuration simply missing because nobody has bothered adding one?
I'm also asking because I observed several PTP slave devices ignoring the
transmitted currentUtcOffset when currentUtcOffsetValid is set to 0, even when
the transmitted currentUtcOffset matches their local default, i.e. the value such
devices would use when running as master.
For example:
- Solarflare PTPD (sfptpd), latest version, i.e. PHCs and system clock are
running under TAI, by default (sfptpd has a configuration option to always
use the transmitted offset, independent of the currentUtcOffsetValid flag)
- Cisco Nexus 93180YC-FX3, latest firmware, running as boundary clock, i.e.
switch system clock is running under TAI (if set to PTP 'protocol') and its own
announce messages also set currentUtcOffsetValid to 0
Thus, when running Linuxptp ptp4l as master with such clients, it would
be convenient to being able to simply set currentUtcOffsetValid to 1 in
the ptp4l configuration file and being done with it.
AFAICS, right now, to avoid that some third party PTP clients step to TAI when a
ptp4l starts until it receives a GRANDMASTER_SETTINGS_NP message,
one has to tweak the ptp4l's best master selection algorithm attributes
such that they are worse than the one of any client, such that those
clients don't select the newly started ptp4l as their master, yet.
Then the ptp4l startup job can send a GRANDMASTER_SETTINGS_NP with the right
currentUtcOffsetValid and - say - reset the clockClass value and
set priority1 via another management message, such that this ptp4l
is now safely selected as master by all the clients.
That necessary pmc call after startup could be done via the systemd
`ExecStartPost=` directive, when starting ptp4l via systemd. But perhaps
this would also need a sleep command before the pmc to avoid a race
condition between ptp4l starting up and creating the UDS socket and
systemd invoking pmc.
So all this is a bit tedious and errorprone, in comparison to a
possible currentUtcOffsetValid configuration file setting.
Best regards,
Georg
--
'BUGS
So many numbers print out that its sometimes hard
to figure out what to watch.' (vmstat(1), 3BSD, 1979)
|
