Nothing Special   »   [go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

flag hardware_timestamping="n" picked linuxts_udpv6 but it didn't work. Forcing socket_udpv6 worked! #16

Open
junfengbai opened this issue Aug 13, 2018 · 1 comment
Open

flag hardware_timestamping="n" picked linuxts_udpv6 but it didn't work. Forcing socket_udpv6 worked! #16

junfengbai opened this issue Aug 13, 2018 · 1 comment

Comments

@junfengbai
Copy link
junfengbai commented Aug 13, 2018 •
edited
Loading

On the system for eth4 we got two clocks:
Clock 1: syst : name: syst state: FREQEST ref: eth4
Clock 2: eth4 : * name: eth4 state: LOCKED ref: PTP
Clock 1: syst : offs: -400.360176614 adev: 0.000 freq: 0.000
Clock 2: eth4 : * offs: 0.000000040 adev: 6.943 freq: 4082.293

The code we were running is from https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-libcck

We used flag hardware_timestamping="n", to disable hardware clock to try the software clock. But it didn't work:

Transport : linuxts_udpv6, S/W tstamp, unicast negotiation
PTP preset : slaveonly
Delay mechanism : E2E
Sync mode : TWO_STEP
Announce received : 55
Sync received : 0
Follow-up received : 0
DelayReq sent : 0
DelayResp received : 0
State transitions : 4
PTP Engine resets : 1

The syslog showed that "Error: no RX timestamp received!"

2018-07-27 13:01:40.993342 ptpd[11190].(debug1) ttransport.linuxts_udpv6: receiveMesage(General): received 58 bytes from 2000::88 to fc00:6b2:1:22::1
2018-07-27 13:01:41.008154 ptpd[11190].(debug1) ttransport.linuxts_udpv6: receiveMessage(Event): got message destination fc00:6b2:1:22::1 via IPV6_PKTINFO
2018-07-27 13:01:41.008170 ptpd[11190].(debug1) ttransport.linuxts_udpv6: receiveMessage(Event): Error: no RX timestamp received!
2018-07-27 13:01:41.008180 ptpd[11190].(debug1) acl: ACL data_Event is open - permitting message

sudo ethtool -i eth4
driver: i40e
version: 2.3.2-k
firmware-version: 10.2.5
expansion-rom-version:
bus-info: 0000:12:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

sudo ethtool -T eth4
Time stamping parameters for eth4:
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: 4
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)
ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

The log at setup stage:
2018-07-27 13:01:37.855201 ptpd[11190].(debug1) ttransport.linuxts_udpv6: tTransportInit(Event): disabled UDP checksums
2018-07-27 13:01:37.855219 ptpd[11190].(debug1) ttransport.linuxts_udpv6: tTransportInit(Event): successfully bound to fc00:6b2:1:22::1:319 on eth4
2018-07-27 13:01:37.855433 ptpd[11190].(debug1) getLinuxVlanInfo(): failed to call SIOCGIFVLAN ioctl on eth4: Invalid argument
2018-07-27 13:01:37.855466 ptpd[11190].(debug1) ioctlHelper: failed to call ioctl 0x8994 on eth4: Operation not supported
2018-07-27 13:01:37.855495 ptpd[11190].(debug1) getLinuxInterfaceInfo(eth4): Underlying physical device: eth4
2018-07-27 13:01:37.855506 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports s/w mode SOF_TIMESTAMPING_TX_SOFTWARE
2018-07-27 13:01:37.855516 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports s/w mode SOF_TIMESTAMPING_RX_SOFTWARE
2018-07-27 13:01:37.855526 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports s/w mode SOF_TIMESTAMPING_SOFTWARE
2018-07-27 13:01:37.855537 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports h/w mode SOF_TIMESTAMPING_TX_HARDWARE
2018-07-27 13:01:37.855547 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports h/w mode SOF_TIMESTAMPING_RX_HARDWARE
2018-07-27 13:01:37.855558 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports h/w mode SOF_TIMESTAMPING_RAW_HARDWARE
2018-07-27 13:01:37.855568 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports RX filter HWTSTAMP_FILTER_PTP_V2_EVENT (12)
2018-07-27 13:01:37.855579 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Selected RX filter HWTSTAMP_FILTER_PTP_V2_EVENT (12)
2018-07-27 13:01:37.855589 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports RX filter HWTSTAMP_FILTER_PTP_V2_L4_EVENT (6)
2018-07-27 13:01:37.855599 ptpd[11190].(debug1) getLinuxTsInfo(eth4): No support for RX filter HWTSTAMP_FILTER_ALL
2018-07-27 13:01:37.855610 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports RX filter HWTSTAMP_FILTER_PTP_V2_L4_SYNC (7)
2018-07-27 13:01:37.855620 ptpd[11190].(debug1) getLinuxTsInfo(eth4): Interface supports HWTSTAMP_TX_ON
2018-07-27 13:01:37.855630 ptpd[11190].(debug1) getLinuxTsInfo(eth4): No support for HWTSTAMP_TX_ONESTEP_SYNC
2018-07-27 13:01:37.855915 ptpd[11190].(info) initTimestamping(eth4): Linux software timestamping enabled
@junfengbai junfengbai changed the title flag hardware_timestamping="n" picked linuxts_udpv6 but it didn't work. Forcing socket_udp6 worked! flag hardware_timestamping="n" picked linuxts_udpv6 but it didn't work. Forcing socket_udpv6 worked! Aug 13, 2018
@wowczarek
Copy link
Owner
wowczarek commented May 12, 2020 •
edited
Loading

Wow, I think this is my record for a late response...

So - the linuxts* transports handle hardware timestamps, but also software timestamps (SO_TIMESTAMPING with RX_SOFTWARE + TX_SOFTWARE) provided by the Linux PHC API. The main feature that these provide, is transmit timestamps, which standard SO_TIMESTAMP/SO_TIMESTAMPNS do not. The problem is that software timestamping with SO_TIMESTAMPING is often broken, so manually forcing socket_udpv6 is the correct option. Unfortunately the transport does not know that it's broken this way, until it actually tries to send something and then gets no TX timestamp. So this cannot be detected early and this is why socket_udpv6 is not chosen automatically.

Unfortunately socket_udpv6 and socket_udpv4 use a very naive method of capturing TX timestamps if it's unicast (they loop a packet back to themselves). For multicast it's fine as there is a packet loopback option provided. But it may be worth checking if you get better results with pcap_updv6 instead of socket_udpv6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wowczarek @junfengbai