wowczarek / ptpd Goto Github PK

https://github.com/wowczarek/ptpd/blob/wowczarek-2.3.2-libcck/src/libcck/net_utils.h
void prepareMsgHdr(struct msghdr *msg, struct iovec *vec, char *dataBuf, size_t dataBufSize, char *controlBuf, size_t controlLen, struct sockaddr *addr, int addrLen);

https://github.com/wowczarek/ptpd/blob/wowczarek-2.3.2-libcck/src/libcck/net_utils.c
prepareMsgHdr(struct msghdr *msg, struct iovec *vec, char *dataBuf, size_t dataBufSize, char *controlBuf, size_t controlLen, struct sockaddr *fromAddr, int fromAddrLen)

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

Scenario:

• Bonded interface on Linux, member A) is vendor X (say Solarflare) for which libcck loads vendor extensions
• Bonded interface member B) is vendor Y, for which libcck also loads vendor extensions

...or vice versa (A<->B).

The MAC address of all bond members becomes the same once bonded. This will cause incorrect extensions to be loaded, or no extensions to be loaded, if mixing NIC vendors. The only way around this is to try acquiring the actual burned-in hardware MAC.

Hi Wojciech,

Please, take a look if you get a chance. I tested this fork with and without HW support. HW works fine, but without HW when I change active slave in bond0 it stucks in ussing high CPU on the selected core.
OS: Debian 9.2, kernel: 4.9.0-4-amd64

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: pri0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: pri0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 24:b6:fd:87:2d:1f
Slave queue ID: 0

Slave Interface: sec0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 24:b6:fd:87:2d:20
Slave queue ID: 0

2017-12-04 05:00:19.124103 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.124115 ptpd[2970].bond0 (debug1) (slv) netRecvEvent: Flushed errqueue
2017-12-04 05:00:19.126336 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.126349 ptpd[2970].bond0 (debug1) (slv) ==> DelayResp message received, sequence 309
2017-12-04 05:00:19.126359 ptpd[2970].bond0 (debug1) (slv) ==> Handle DelayResp (309)
2017-12-04 05:00:19.126370 ptpd[2970].bond0 (debug1) (slv) Ignored DelayResp sequence 309 - wasn't waiting for one
2017-12-04 05:00:19.142836 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.142850 ptpd[2970].bond0 (debug1) (slv) ==> Sync message received, sequence 26307
2017-12-04 05:00:19.142862 ptpd[2970].bond0 (debug1) (slv) UpdateOffset: max delay hit: 0
2017-12-04 05:00:19.157694 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.157710 ptpd[2970].bond0 (debug1) (slv) Ignored message Sync received from 0 domain
2017-12-04 05:00:19.174081 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.174097 ptpd[2970].bond0 (debug1) (slv) ==> Sync message received, sequence 26308
2017-12-04 05:00:19.174109 ptpd[2970].bond0 (debug1) (slv) UpdateOffset: max delay hit: 0
2017-12-04 05:00:19.174120 ptpd[2970].bond0 (debug1) (slv) tuning outlier filter: delayMS
2017-12-04 05:00:19.174129 ptpd[2970].bond0 (debug1) (slv) delayMS filter autotune: counter 10, samples 10, outliers, 0 percentage 0, new threshold 1.50
2017-12-04 05:00:19.189049 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.189065 ptpd[2970].bond0 (debug1) (slv) Ignored message Sync received from 0 domain
2017-12-04 05:00:19.205329 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.205343 ptpd[2970].bond0 (debug1) (slv) ==> Sync message received, sequence 26309
2017-12-04 05:00:19.205355 ptpd[2970].bond0 (debug1) (slv) UpdateOffset: max delay hit: 0
2017-12-04 05:00:19.209316 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.209332 ptpd[2970].bond0 (debug1) (slv) ==> DelayReq message received, sequence 49305
2017-12-04 05:00:19.209342 ptpd[2970].bond0 (debug1) (slv) delayReq message received :
2017-12-04 05:00:19.209352 ptpd[2970].bond0 (debug1) (slv) ==> DelayResp message received, sequence 49305
2017-12-04 05:00:19.209362 ptpd[2970].bond0 (debug1) (slv) HandledelayResp : delayResp doesn't match with the delayReq.
2017-12-04 05:00:19.220408 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.220423 ptpd[2970].bond0 (debug1) (slv) Ignored message Sync received from 0 domain

echo 'sec0' > /sys/class/net/bond0/bonding/active_slave

2017-12-04 05:00:19.227626 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227639 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227651 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227661 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227674 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227690 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227702 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227712 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227724 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227734 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227745 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227755 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227766 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227776 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227787 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227797 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227808 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227818 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227829 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227839 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227850 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227860 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length
2017-12-04 05:00:19.227871 ptpd[2970].bond0 (debug1) (slv) handle: something
2017-12-04 05:00:19.227881 ptpd[2970].bond0 (debug1) (slv) Error: message shorter than header length

Hi All,
I am working to bringup ptpd application with my hardware PTP feature, I am confused about the PI calculation in the source codes,
there is calculation in the source file as blow,
self->integral += (self->tau / self->delayFactor) * ((input + 0.0 ) * self->kI);
self->output = (self->kP * (input + 0.0) ) + self->integral;

but what are kP and kI and what should be the value?

(Apologies if this isn't the proper venue for this question; I couldn't find any other obvious way to contact Mr. Owczarek)

Hi Wojciech, I'm in charge of a (non-internet-connected) set of a dozen or so headless, IPv6-only Debian boxes, all co-located on the same subnet, that need to keep their system-clocks synchronized to each other (to within a couple of milliseconds). Currently they use PTPv1 to do that, via an old build of ptpd that I hacked (years ago) to add in IPv6-over-multicast support and some basic ethernet-port-failover logic. It all works fine AFAICT.

In order to keep things up-to-date, I'd like to upgrade to PTPv2, and I see that your fork of ptpd already supports IPv6 and failover, which sounds like just the thing I need. Great!

My question is, is this fork's code stable to the point where you would recommend it for a production environment? (if not, I'll just stick with PTPv1 for now, or perhaps try to re-apply my IPv6 and failover patches to the current mainline ptpd codebase instead) And if it is stable, which git-branch do you recommend I grab code from? (I assume origin/wowczarek-2.3.2-libcck is the probably the "most up-to-date" branch but it's always good to get confirmation from someone knowledgable)

Thanks,
Jeremy

I have PTPd running on an edge server and I want to sync the time of a smartphone to that edge server, to measure various network metrics. The software works fine with WiFi, but once I transition to a 4G/5G network, the packets from the master (server) are not seen by the slave (phone), even if I point with an IP with unicast. If I reverse the roles, the server is able to find the initial packet from the master phone, but then no synchorinsation happens.

I'm guessing that PTPd doesn't work for mobile networks, since the protocol was mainly designed for Ethernet (?), and includes an Ethernet II frame which is missing from packets sent over a 4G/5G network?

Am I missing something with the implementation? Or is deployment on a cellular network not supported at all?

current master logs lines like the following

2024-07-18 22:48:26.579812, slv, 000efefffe00008d/1, 0.000000000, 0.000000000, 0.000000000, 0.000000000, 6856.445312500, I, 50359, 0.000000000, 0, 0.000000000, 0 0.000000000, 0.000000000

note the two adjacent fields without a separating comma

also:

the following was commented out, this mangles the format a bit and causes the line to not match the header printed at top of file

/*
len += snprintf(sbuf + len, sizeof(sbuf) - len, ", %.0f, %.0f, ",
ptpClock->servo.driftMean,
ptpClock->servo.driftStdDev);
*/

I have ptpd running on a few machines, and it seems to work fine for a while. But without fail, the ptpd process eventually starts to use 100% of a single CPU. I've seen multiple people post issues about this problem in the past along with responses from @wowczarek, so I know it's not just me who has experienced this problem.

The version of ptpd I'm using is https://github.com/ptpd/ptpd (master branch). When I run ptpd2 --version, it says ptpd2 version 2.3.2.

Has this problem been fixed? If so, where can I find the fixed version?

Thank you,
Lucas