On Mon, Oct 30, 2017 at 08:07:49PM -0700, Gary E. Miller wrote:
> Miroslav Lichvar <mlich...@redhat.com> wrote:
> > Is there a "LISTENING to UNCALIBRATED on RS_SLAVE" message in the log?
> > If not, ptp4l is probably not receiving master's messages, e.g. due to
> > firewall or switch configuration.
> 
> Nope.  Can you suggest a working configuration or a howto?  I thought
> it used to work.

A minimal configuration using software timestamping and the NTP SHM
segment #2 would be:

1. on master run: ptp4l -S -i eth0 -m
2. on slave run: ptp4l -s -S -i eth0 -m --clock_servo NTPSHM --ntpshm_segment 2

The slave ptp4l should print something like this:

ptp4l[3444911.527]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[3444911.528]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[3444916.592]: port 1: new foreign master xxxxxx.xxxx.xxxxxx-1
ptp4l[3444918.313]: selected best master clock yyyyyy.yyyy.yyyyyy
ptp4l[3444920.592]: selected best master clock xxxxxx.xxxx.xxxxxx
ptp4l[3444920.592]: foreign master not using PTP timescale
ptp4l[3444920.592]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[3444922.592]: master offset    -333886 s0 freq      +0 path delay     
87021
ptp4l[3444923.592]: master offset    -335317 s0 freq      +0 path delay     
89726

For each "master offset" message there should be an update of the SHM
segment.

# ntpshmmon 
ntpshmmon version 1
#      Name Seen@                Clock                Real                 L 
Prec
sample NTP2 1509446684.245300996 1509446683.444564513 1509446683.444868882 0 -30
sample NTP2 1509446684.445200649 1509446684.444584459 1509446684.444876828 0 -30
sample NTP2 1509446685.444777467 1509446685.444555127 1509446685.444893429 0 -30
sample NTP2 1509446686.444997907 1509446686.444603946 1509446686.444903255 0 -30
sample NTP2 1509446687.445353599 1509446687.444604192 1509446687.444912416 0 -30
sample NTP2 1509446688.445426052 1509446688.444619136 1509446688.444923429 0 -30


If the slave does not synchronize, you can try on slave

# tcpdump -i eth0 -n port ptp-event or port ptp-general
11:47:10.446485 IP 192.168.101.1.ptp-event > 224.0.1.129.ptp-event: UDP, length 
44
11:47:10.446503 IP 192.168.101.1.ptp-general > 224.0.1.129.ptp-general: UDP, 
length 44
11:47:10.446508 IP 192.168.101.1.ptp-general > 224.0.1.129.ptp-general: UDP, 
length 64
11:47:11.446489 IP 192.168.101.1.ptp-event > 224.0.1.129.ptp-event: UDP, length 
44
11:47:11.446515 IP 192.168.101.1.ptp-general > 224.0.1.129.ptp-general: UDP, 
length 44

If there are some ptp message from the master, it's likely a firewall
rule which blocks the messages from reaching ptp4l. UDP ports 319 and
320 need to be allowed.

If no messages appear, the switch (if it's a managed switch) might
need to be configured to allow multicast traffic between the hosts.

-- 
Miroslav Lichvar

------------------------------------------------------------------------------
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

Reply via email to