Sync rx timeout should be set only after receiving the first sync, see
section 10.2.7, figure 10-4 PortSyncSyncReceive state machine in 802.1AS
Signed-off-by: Delio Brignoli <dbrignoli@audioscience.com>
Add new options delay_filter and delay_filter_length to select the
filter and its length. They set both the clock delay filter and the port
peer delay filter. The default is now moving median with 10 samples.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Median filter has an advantage over moving average that it is much less
sensitive to outliers.
For instance, it allows much faster recovery from an external clock
time step which happened between receiving sync message and sending
delay_req message. The measured delay includes a large error, but the
median is still a good estimate of the delay and the first step
correction applied by the servo is right.
In this implementation the median update has linear time complexity.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Similarly to the servo interface, allow multiple filters to be
used for delay filtering. Convert mave to the new interface.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
This patch cleans up the error message for the Tx timestamp polling, and adds a
line which indicates where the bug might have originated. This should help a
user more easily diagnose what went wrong.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Check the sanity of the synchronized clock by comparing its uncorrected
frequency with the system monotonic clock. When the measured frequency
offset is larger than the value of the sanity_freq_limit option (20% by
default), a warning message will be printed and the servo will be reset.
Setting the option to zero disables the check.
This is useful to detect when the clock is broken or adjusted by another
program.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
When a new master is selected, drop the old sync time stamp to prevent
calculating invalid delay in case delay_resp will be received before
first sync from the new master.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
When a new master appears, it will start to respond to our delay_req
messages. Make sure we process only responses from our current master
before switching to the new master.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
This patch increases the maximum length of an interface name to
accommodate a UNIX domain socket address of 108 bytes. (This value is
hard coded in the glibc headers, and so we cannot use the Linux kernel
header macro, UNIX_PATH_MAX.)
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch changes the macro for the server socket address into a global
variable so that a subsequent patch can provide a way to set the variable.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch introduces a shell script to figure out the proper definitions
for the HAVE_CLOCK_ADJTIME and HAVE_ONESTEP_SYNC macros, as well as the
include path. The intent is to "do the right thing" for three different
user scenarios, namely cross compiling, compiling against a custom kernel,
and using a plain old disto kernel.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
When the socket couldn't be opened (e.g. in clknetsim), the file
descriptor is invalid and shouldn't be used for sending.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
When ptp4l was configured to use the auto delay mechanism and the first
pdelay request was not received in the slave or uncalibrated state, it
would not make any pdelay requests itself, because there was no delay
timer running.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
This patch adds a semicolon forgotten in commit
5bf265e "missing: add onestep sync to missing.h"
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Following command produces unexpected update rate.
# phc2sys -s eth0 -q -m -O0 -R1.0842021724855044e-19
This is caused by wrong validation of phc_interval related to
significant digits of double precision and phc_interval_tp.tv_sec
overflow.
To avoid these unwanted trouble, this patch limits lower bound of
phc_rate to 1e-9.
There is no profound meaning in the lower bound value. I just think
it's enough to actual use and it doesn't cause phc_interval_tp.tv_sec
overflow in not only 64bit environment but also 32bit environment.
Thereby, messy validation of phc_interval is no longer needed.
Signed-off-by: Ken ICHIKAWA <ichikawa.ken@jp.fujitsu.com>
this patch uses grep to test whether the net_tstamp.h header has
HWTSTAMP_TX_ONESTEP_SYNC flag defined. If it doesn't then we can simply define
it with the correct value. This works because proper drivers should just report
that the value is not allowed if they don't support onestep mode. This is the
cleanest way to ensure that linuxptp will still work on kernels which have not
defined the one step flag, and also works for any distributions which backport
the feature.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Because of packet reordering that can occur in the network, in the
hardware, or in the networking stack, a follow up message can appear
to arrive in the application before the matching sync message. As this
is a normal occurrence, and the sequenceID message field ensures
proper matching, the ptp4l program accepts out of order packets.
This patch adds an additional check using the software time stamps
from the networking stack to verify that the sync message did arrive
first. This check is only useful if the sequence IDs generated by
the master might possibly be incorrect.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch lets a port send the first announce message one millisecond
after the port state transition, rather than waiting one announce interval.
This change is needed because it is desirable to reconfigure the time
network without delay, especially in P2P mode.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch adds a new timer for use in 802.1AS-2011 applications. When
running as a slave in gPTP mode, the program must monitor both announce
and sync messages from the master. If either one goes missing, then we
trigger a BMC election. The sync timeout is actually reset by a valid
sync/follow up pair of messages.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch renames the per-port timer in order to make room in the
namespace for a timer that detects a sync message input timeout.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The closing and reopening of the transport when in slave only mode is not
necessary if the port is using the peer delay mechanism. In that case, the
port will discover the network error by transmitting a peer delay request.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Acked-by: Delio Brignoli <dbrignoli@audioscience.com>
Add 1 to port numbers printed in the log messages to make them
consistent with messages from port.c. The port number 0 is the UDS port,
which is last in the clock->port array.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Ken Ichikawa has identified a situation in which a sync message can be
wrongly associated with a follow up after the sequence counter wraps
around.
Port is LISTENING
Sync (seqId 0) : ignored
Fup (seqId 0) : ignored
Sync (seqId 1) : ignored
Port becomes UNCALIBRATED here
Fup (seqId 1) : cached!
Sync (seqId 2) : cached
Fup (seqId 2) : match
Sync (seqId 3) : cached
Fup (seqId 3) : match
...
Sync (seqId 65535) : cached
Fup (seqId 65535) : match
Sync (seqId 0) : cached
Fup (seqId 0) : match
Sync (seqId 1) : match with old Fup!!
Fup (seqId 1) : cached!
Sync (seqId 2) : cached
Fup (seqId 2) : match
Actually, I experienced 65500 secs offset every about 65500 secs.
I'm thinking this is the cause.
This patch fixes the issue by changing the port code to remember one
sync or one follow up, never both. The previous ad hoc logic has been
replaced with a small state machine that handles the messages in the
proper order.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Ken ICHIKAWA <ichikawa.ken@jp.fujitsu.com>
This patch adds a new pmc command called "target" that lets the user
address a particular clock and port. Previously all management requests
were sent to the wild card address.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch replaces the hard coded wild card target port identity with
a variable initially set to the wild card value. The intent is to allow
the caller to set specific targets.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch makes the original behavior of sending the
TLV values for GET actions with a length of zero.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This commit makes the GET messages have data bodies, just like the erratum
says to. It really doesn't make sense, but have to do it anyhow. We also
introduce a variable that will enable the legacy behavior of sending
empty bodies.
http://standards.ieee.org/findstds/interps/1588-2008.html
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch lets the TLV length field of GET messages come from a
function. For now, the function still results in a length of two,
but the intent is to allow different values later.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch adds proper byte order processing for the target port
identity field of management messages. This bug was not previously
noticed due to the fact that our client had always set this field
to the wild card port number of 0xffff.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch fixes a bug with time mysteriously jumping back and forth:
ptp4l[930.687]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[931.687]: master offset 17 s2 freq +33014 path delay 2728
ptp4l[932.687]: master offset -74 s2 freq +32928 path delay 2734
ptp4l[933.687]: master offset 2 s2 freq +32982 path delay 2734
ptp4l[934.687]: master offset -3 s2 freq +32977 path delay 2728
ptp4l[935.687]: master offset 17 s2 freq +32996 path delay 2729
ptp4l[936.687]: master offset -10 s2 freq +32974 path delay 2729
ptp4l[937.687]: master offset 35 s2 freq +33016 path delay 2727
ptp4l[938.686]: master offset 60001851388 s2 freq +62499999 path delay 2728
ptp4l[939.687]: master offset -62464938 s2 freq -62431946 path delay 2728
The last follow up message arriving out of order is cached. Before the state
machine changes to UNCALIBRATED, all sync and follow up messages are discarded.
If we get into that state between a sync and follow up message, the latter is
cached. When there's no real roerdering happening, it's kept cached forever.
When we restart the master, it starts numbering the messages from zero again.
The initial synchronization doesn't take always the same amount of time, so it
can happen that we get into UNCALIBRATED a little bit faster than before,
managing to get the sync message with the sequenceId that we missed last time.
As it has the same sequenceId as the cached (old) follow up message, it's
incorrectly assumed those two belong together.
Flush the cache when changing to UNCALIBRATED. Also, do similar thing for other
cached packets.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
This patch cleans up the BMC logic to allow assuming the GM role when no
other clocks are found in the network. By allowing the "best" to be NULL,
we can let the BMC to naturally pick the local clock as GM. As an added
bonus, this also get rid of the hacky check for a lost master.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Instead of using fixed constants, set them by the following formula from
the current sync to allow good performance of the servo even when the
sync interval changes in runtime and to avoid instability.
kp = min(kp_scale * sync^kp_exponent, kp_norm_max / sync)
ki = min(ki_scale * sync^ki_exponent, ki_norm_max / sync)
The scale, exponent and norm_max constants are configurable. The
defaults are chosen so there is no change to the previous default
constants of the servo with one second sync interval. The automatic
adjustment can be disabled by setting the pi_proportional_const and
pi_integral_const options to a non-zero value, but stability of the
servo is always enforced.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
A slow servo (with smaller constants and lower sync rate) needs a
longer, better frequency estimation, but a higher sync rate hardly
needs any estimation at all, since it learns the frequency right away
in any case.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch adds a new servo method to let the algorithm know about the
master clock's reported sync message interval. This information can be
used by the servo to adapt its synchronization parameters.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Delio Brignoli
Miroslav Lichvar
Jacob Keller
Richard Cochran
Ken ICHIKAWA
Andy Lutomirski
Jiri Benc