Thread: [Linuxptp-users] Timestamp value in PTP Sync & Followup packets
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: RAVEENDRA M <mra...@ya...> - 2019-10-17 07:47:26
|
The following are the ethernet nic interface details
[root@mavdu ~]# ethtool -i eth0
driver: ixgbe
version: 5.1.0-k-rh7.6
firmware-version: 0x800006d6, 1.1275.0
expansion-rom-version:
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
[root@mavdu ~]# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
[root@mavdu ~]#
ptp4l.conf file content
------------------------------
[global]
#
# Default Data Set
#
#twoStepFlag 0
twoStepFlag 1
slaveOnly 0
priority1 128
priority2 128
domainNumber 24
#utc_offset 37
clockClass 248
clockAccuracy 0xFE
offsetScaledLogVariance 0xFFFF
free_running 0
freq_est_interval 1
dscp_event 0
dscp_general 0
#
# Port Data Set
#
logAnnounceInterval -3
logSyncInterval -4
logMinDelayReqInterval -4
logMinPdelayReqInterval -4
announceReceiptTimeout 3
syncReceiptTimeout 0
delayAsymmetry 0
fault_reset_interval 4
neighborPropDelayThresh 20000000
#
# Run time options
#
assume_two_step 1
logging_level 6
path_trace_enabled 0
follow_up_info 0
hybrid_e2e 0
tx_timestamp_timeout 10
use_syslog 1
verbose 0
summary_interval 0
kernel_leap 1
check_fup_sync 0
#
# Servo Options
#
pi_proportional_const 0.0
pi_integral_const 0.0
pi_proportional_scale 0.0
pi_proportional_exponent -0.3
pi_proportional_norm_max 0.7
pi_integral_scale 0.0
pi_integral_exponent 0.4
pi_integral_norm_max 0.3
step_threshold 0.0
first_step_threshold 0.00002
max_frequency 900000000
clock_servo pi
sanity_freq_limit 200000000
ntpshm_segment 0
#
# Transport options
#
transportSpecific 0x0
#ptp_dst_mac 01:1B:19:00:00:00
#ptp_dst_mac 01:80:C2:00:00:0E
ptp_dst_mac 00:0a:35:00:22:11
p2p_dst_mac 01:80:C2:00:00:0E
udp_ttl 1
udp6_scope 0x0E
uds_address /var/run/ptp4l
#
# Default interface options
#
#network_transport UDPv4
network_transport L2
delay_mechanism E2E
time_stamping hardware
tsproc_mode filter
delay_filter moving_median
delay_filter_length 10
egressLatency 0
ingressLatency 0
boundary_clock_jbod 0
#
# Clock description
#
productDescription ;;
revisionData ;;
manufacturerIdentity 00:00:00
userDescription ;
timeSource 0xA0
dataset_comparison G.8275.x
G.8275.defaultDS.localPriority 128
maxStepsRemoved 255
G.8275.portDS.localPriority 128
PTP Sync & Followup packets carrying zero timestamp value.
Is this expected behavior or any other way we can configure it to generate timestamps in PTP packets ?
Thanks,
Raveendra
|
|
From: Richard C. <ric...@gm...> - 2019-10-17 10:36:28
|
On Thu, Oct 17, 2019 at 07:47:15AM +0000, RAVEENDRA M via Linuxptp-users wrote: > PTP Sync & Followup packets carrying zero timestamp value. What do you mean by this? > Is this expected behavior or any other way we can configure it to generate timestamps in PTP packets ? The Sync.originTimestamp is expected to be zero, if sent by ptp4l. The IEEE 1588 standard allows that field to be zero. The FollowUp.preciseOriginTimestamp will carry the non-zero transmit time of the Sync message. You said that the driver is ixgbe. What Intel MAC are you using? Are you sending the Sync and FollowUp messages from the Intel MAC or receiving them there? HTH, Richard |
|
From: RAVEENDRA M <mra...@ya...> - 2019-10-17 11:06:23
|
Thanks for reply. We are using "Ethernet controller: Intel Corporation Ethernet Connection X552 10 GbE SFP+" Yes. We are sending Sync & Followup messages from Intel MAC. Another issue observed with single step ptp operation. I made changes for single step ptp master with making twoStepFlag as zero. twoStepFlag 0 assume_two_step 0 After above if ptp4l master started then we are getting following errors. Jan 07 01:02:15 mavdu.local systemd[1]: Stopping Precision Time Protocol (PTP) service... Jan 07 01:02:15 mavdu.local systemd[1]: Started Precision Time Protocol (PTP) service. Jan 07 01:02:15 mavdu.local systemd[1]: Starting Precision Time Protocol (PTP) service... Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: ptp4l_master[90657.824]: selected /dev/ptp0 as PTP clock Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: [90657.824] selected /dev/ptp0 as PTP clock Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: ptp4l_master[90657.836]: driver rejected most general HWTSTAMP filter Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: [90657.836] driver rejected most general HWTSTAMP filter Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: ptp4l_master[90657.836]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: [90657.836] ioctl SIOCSHWTSTAMP failed: Numerical result out of range Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: ptp4l_master[90657.848]: port 1: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: [90657.848] port 1: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: ptp4l_master[90657.848]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: [90657.848] port 0: INITIALIZING to LISTENING on INIT_COMPLETE Thanks, Raveendra On Thursday, October 17, 2019, 4:06:22 PM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Thu, Oct 17, 2019 at 07:47:15AM +0000, RAVEENDRA M via Linuxptp-users wrote: > PTP Sync & Followup packets carrying zero timestamp value. What do you mean by this? > Is this expected behavior or any other way we can configure it to generate timestamps in PTP packets ? The Sync.originTimestamp is expected to be zero, if sent by ptp4l. The IEEE 1588 standard allows that field to be zero. The FollowUp.preciseOriginTimestamp will carry the non-zero transmit time of the Sync message. You said that the driver is ixgbe. What Intel MAC are you using? Are you sending the Sync and FollowUp messages from the Intel MAC or receiving them there? HTH, Richard |
|
From: Richard C. <ric...@gm...> - 2019-10-17 13:43:06
|
On Thu, Oct 17, 2019 at 11:06:13AM +0000, RAVEENDRA M wrote: > We are using "Ethernet controller: Intel Corporation Ethernet Connection X552 10 GbE SFP+" > Yes. We are sending Sync & Followup messages from Intel MAC. Then the follow up time stamps should be non-zero. > Another issue observed with single step ptp operation. I made changes for single step ptp master with making twoStepFlag as zero. That card does not support one-step. > Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: ptp4l_master[90657.836]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range > Jan 07 01:02:15 mavdu.local ptp4l_master[8503]: [90657.836] ioctl SIOCSHWTSTAMP failed: Numerical result out of range ^^^ See? HTH, Richard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X