Hi community,
There are two servers in my test environment. One of these should be the
grandmaster server and one should be the slave server.
*PTP Grandmaster*
*Ethernet Adapter:* Intel Gigabit 82579LM (rev 05)
*Ethernet Driver:* e1000e, version 3.2.6-k
*Operating System:* CoreOS 1353.8.0
*Linux Kernel version:* 4.9.24-coreos-rt20 (uname -r)
*PTP Slave*
*Ethernet Adapter:* Intel Gigabit i217-LM (rev 04)
*Ethernet Driver:* e1000e, version 3.2.5-k
*Operating System:* Fedora 22
*Linux Kernel version:* 4.2.6-200.fc22.x86_64 (uname -r)
*Note*
*ptp4l* and *phc2sys* are both started by launching a ptp4l container and a
phc2sys container (Docker) on both above mentioned systems. Configurations
are specified below:
*Objectives*
*1)* Synchronise the physical hardware clock on the NIC of the PTP
Grandmaster to the system clock of the PTP Grandmaster.
*i.e.:* *PTP Grandmaster* *# ptp4l -i enp0s25 -m -q -4 -H *
*i.e.: **PTP Grandmaster* *# phc2sys -s CLOCK_REALTIME -c enp0s25 -m -q -w*
*2)* Synchronise the physical hardware clock on the NIC of the PTP Slave
server to the physical hardware clock of the PTP Grandmaster.
*i.e.:* *PTP Slave server* *# ptp4l -i eno1 -s -m -q -4 -H*
*3)* Synchronise the system clock of the PTP Slave server to the physical
hardware clock of the PTP Slave server.
*i.e.:* *PTP Slave server* *# phc2sys -s eno1 -c CLOCK_REALTIME -m -q -w *
*Observations*
*1)* When trying to synchronise the physical hardware clock to the system
clock by using the command specified above (*# phc2sys -c enp0s25 -s
CLOCK_REALTIME -m -q -w* *and* *# ptp4l -i enp0s25 -m -q -4 -H*) the
phc2sys output states that it only stays in s0 mode and will not reach s1
or s2 states. Also, the offset is extremely high, as is the frequency
adjustment. It continuously returns the message "Clock Check: Clock jumped
forward or running faster than expected!". I checked and both timesyncd and
ntpd are disbabled. Furthermore, it displays messages 'waiting for ptp4l..'
in the beginning when de ptp4l container is not yet up and running. *This
does not even makes sense *since I am trying to synchronise the physical
hardware clock to the system clock, so *why* should phc2sys have to wait
for ptp4l in order to synchronise the physical hardware clock?
However, after some trial and error, when trying to synchronise the
physical hardware clock to the system clock by using the following
commands, it does reach s1 and s2 immediately including accurate offset and
frequency adjustment values:
*# phc2sys -c /dev/ptp* -s CLOCK_REALTIME -m -q -w*
*# ptp4l -i enp0s25 /dev/ptp* -m -q -4 -H *
*(Please note that also this makes no sense in the ptp4l command;
specifying basically two 'devices' to the -i flag. When not specifying
enp0s25 but only /dev/ptp* it also does the same as stated above; high
offset, high frequency adjustment, clock check messages, not reaching s1 or
s2)*
*2)* By using the last stated two commands on the PTP Grandmaster, which
seems to be the only configuration reaching s1 and s2 with accurate values,
the next step is to synchronise the PTP Slave server to the physical
hardware clock of the PTP Grandmaster. I have tried this with the following
command:
*# ptp4l -i eno1 -s -m -q -4 -H*
This results in extremely high offset values and a frequency adjustment
of + or - 599999999. When specifying the ptp4l.conf in the command (to
force ptp4l to step the clock when the offset is larger than 1.0 seconds)
by using the -f flag it continuously outputs the first message in s0,
followed by an s1 message, two times s0, one time s1, two times s0, one
time s1 and so on, infinitely. It never reaches s2 and also the offset and
frequency adjustment values seem to only stack up until a certain point
(16.800 seconds or sometimes even 70.000 seconds) and then it tries to slew
them down, which should take forever..
So.. the first thought to came in mind was that the PTP Grandmaster server
was the problem due to the unexplainable issues with getting the system
clock to synchronise the physical hardware clock. I disconnected the PTP
Grandmaster server from my network and connected a HP Z440 with a i218-LM
rev 04, e1000e driver 3.2.5-k and a clean Ubuntu 16.04 LTS installation. I
installed linuxptp on the clean installed Ubuntu and started this server as
the replacement PTP Grandmaster server by using the exact same command: *#
ptp4l -i eno1 -m -q -4 -H*
What happened on the PTP Slave Server was exactly the same as if it was
synchronising to what was the PTP Grandmaster in the first case: very high
offset, very high frequency adjustment and when hitting the 16.800+ seconds
offset it tried to slew it down again. The phc2sys instance on the slave
side gave offsets of 100.000+ seconds and a frequency adjustment of + of -
10000000..
I disconnected the PTP Slave Server and took another clean installed Ubuntu
server and connected this to my network. Letting this synchronise to the
previously set-up replacement PTP Grandmaster resulted again in exactly the
same offset, frequency adjustment etc etc .. I was lost.
Next, I shutdown both the replacement PTP Slave Server and PTP Grandmaster
server and restarted the linuxptp daemons again: synchronising
perfectly...? Also the phc2sys instance on the slave side synchronised the
system clock perfectly to the physical hardware clock..
So I decided to pull the Docker image I had created and used for both the
first initial PTP Grandmaster and PTP Slave servers to see if this was the
problem. I installed Docker on both the replacement PTP Grandmaster and PTP
Slave Server machines and started the containers with exactly the same
configurations, except for the commands for synchronising the physical
hardware clock of the PTP Grandmaster to the system clock; this worked
immediately without any trouble on the replacement PTP Grandmaster server
by using just the 'normal' commands: *# phc2sys -c eno1 -s CLOCK_REALTIME
-m -q -w* *and* *# ptp4l -i eno1 -m -q -4 -H*
Next, I disconnected the replacement PTP Slave Server and connected the
first initial PTP Slave Server to the replacement PTP Grandmaster again,
resulting in a properly functioning setup with accurate values by using the
exact same commands as I did initially... Also the phc2sys instance
functioned properly on the slave side in synchronising the system clock to
the physical hardware clock
So this gave me hope that when reconnecting the first initial PTP
Grandmaster to the network and disconnecting the replacement PTP
Grandmaster immediately after, I would end up with a properly functioning
setup as I had first intended it. But sadly, when reconnecting the first
initial PTP Grandmaster to the network, the offsets and frequency
adjustments of both the first initial PTP Slave Server *and* the
replacement PTP Grandmaster (which then switched to slave mode) immediately
jumped up to 16.800+ seconds and again trying to slew down...
I am totally lost and don't know what to do anymore.. I can't seem to find
where the problems are. Note that I have disabled chronyd, ntpd and
timesyncd on literally every system mentioned above.
If anyone could help me out that would be great!
Gwynn
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
