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.

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

gPTP: frdm_k64f : can not converge time #29599

Open
hakehuang opened this issue Oct 28, 2020 · 5 comments
Open

gPTP: frdm_k64f : can not converge time #29599

hakehuang opened this issue Oct 28, 2020 · 5 comments

Comments

@hakehuang
Copy link
Collaborator

@hakehuang hakehuang commented Oct 28, 2020

Describe the bug
we set up one pc and run https://github.com/Avnu/gptp.git I attached the windows package
Debug.zip
then we set up frdm_k64f board connect with PC though direct connect ethernet cable.

To Reproduce
Steps to reproduce the behavior:

  1. mkdir build; cd build
  2. cmake -DBOARD=frdm_k64f ..
  3. make
  4. make flash

Expected behavior
the time calculation complete and converged

Impact
PTP usage.

Logs and console output

[00:06:55.751,000] <wrn> net_gptp: Reset Pdelay requests
[00:06:56.756,000] <wrn> net_gptp: Reset Pdelay requests
[00:06:57.760,000] <wrn> net_gptp: Reset Pdelay requests
[00:06:58.764,000] <wrn> net_gptp: Reset Pdelay requests
[00:06:59.769,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:00.773,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:01.777,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:02.782,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:03.786,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:04.790,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:05.794,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:06.799,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:07.803,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:08.807,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:09.812,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:10.816,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:11.820,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:12.825,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:13.829,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:14.833,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:15.837,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:16.842,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:17.846,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:18.850,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:19.855,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:20.859,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:21.863,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:22.868,000] <wrn> net_gptp: Reset Pdelay requests
[00:07:23.872,000] <wrn> net_gptp: Reset Pdelay requests
[00:00:00.003,000] <wrn> net_if: iface 0x20000f40 is down
[00:00:00.007,000] <inf> net_config: Initializing network
[00:00:00.007,000] <inf> net_config: Waiting interface 1 (0x20000f40) to be up...
[00:00:01.005,000] <wrn> net_gptp: Reset Pdelay requests
[00:00:01.008,000] <wrn> net_if: iface 0x20000f40 is down
[00:00:02.010,000] <wrn> net_gptp: Reset Pdelay requests
[00:00:02.012,000] <wrn> net_if: iface 0x20000f40 is down
[00:00:03.001,000] <inf> net_config: Interface 1 (0x20000f40) coming up
[00:00:03.001,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
[00:00:03.001,000] <inf> net_config: IPv4 address: 192.168.0.103
[00:00:03.014,000] <wrn> net_gptp: Reset Pdelay requests
[00:00:03.102,000] <inf> net_config: IPv6 address: 2001:db8::1
uart:~$ net gptp 1
Port id    : 1 (DISABLED)
Interface  : 0x20000f40 [1]
Clock id   : 02:04:9f:ff:fe:31:96:09
Version    : 2
AS capable : no

Configuration:
Time synchronization and Best Master Selection enabled        : yes
The port is measuring the path delay                          : no
One way propagation time on the link attached to this port    : 0 ns
Propagation time threshold for the link attached to this port : 100000 ns
Estimate of the ratio of the frequency with the peer          : 1
Asymmetry on the link relative to the grand master time base  : %ld
Maximum interval between sync messages                        : %lu
Maximum number of Path Delay Requests without a response      : 3
Current Sync sequence id for this port                        : 24570
Current Path Delay Request sequence id for this port          : 50891
Current Announce sequence id for this port                    : 15514
Current Signaling sequence id for this port                   : 22146
Whether neighborRateRatio needs to be computed for this port  : yes
Whether neighborPropDelay needs to be computed for this port  : yes
Initial Announce Interval as a Logarithm to base 2            : 0
Current Announce Interval as a Logarithm to base 2            : 0
Initial Sync Interval as a Logarithm to base 2                : -4
Current Sync Interval as a Logarithm to base 2                : -4
Initial Path Delay Request Interval as a Logarithm to base 2  : 0
Current Path Delay Request Interval as a Logarithm to base 2  : 0
Time without receiving announce messages before running BMCA  : 1 ms (3)
Time without receiving sync messages before running BMCA      : %lu ms (1)
Sync event transmission interval for the port                 : %lu ms
Path Delay Request transmission interval for the port         : %lu ms
BMCA default priority1                                        : 248
BMCA default priority2                                        : 248

Runtime status:
Current global port state                                : DISABLED
Path Delay Request state machine variables:
Current state                                    : WAIT_RESP
Initial Path Delay Response Peer Timestamp       : %lu
Initial Path Delay Response Ingress Timestamp    : %lu
Path Delay Response messages received            : 0
Path Delay Follow Up messages received           : 0
Number of lost Path Delay Responses              : 3
Timer expired send a new Path Delay Request      : 0
NeighborRateRatio has been computed successfully : 0
Path Delay has already been computed after init  : 1
Count consecutive reqs with multiple responses   : 0
Path Delay Response state machine variables:
Current state                                    : INITIAL_WAIT_REQ
SyncReceive state machine variables:
Current state                                    : DISCARD
A Sync Message has been received                 : no
A Follow Up Message has been received            : no
A Follow Up Message timeout                      : no
Time at which a Sync Message without Follow Up
                             will be discarded   : %lu
SyncSend state machine variables:
Current state                                    : INITIALIZING
A MDSyncSend structure has been received         : no
The timestamp for the sync msg has been received : no
PortSyncSyncReceive state machine variables:
Current state                                    : DISCARD
Grand Master / Local Clock frequency ratio       : 0.000000
A MDSyncReceive struct is ready to be processed  : no
Expiry of SyncReceiptTimeoutTimer                : no
PortSyncSyncSend state machine variables:
Current state                                    : TRANSMIT_INIT
Follow Up Correction Field of last recv PSS      : %ld
Upstream Tx Time of the last recv PortSyncSync   : %lu
Rate Ratio of the last received PortSyncSync     : 0.000000
GM Freq Change of the last received PortSyncSync : 0.000000
GM Time Base Indicator of last recv PortSyncSync : 0
Received Port Number of last recv PortSyncSync   : 0
PortSyncSync structure is ready to be processed  : no
Flag when the half_sync_itv_timer has expired    : no
Has half_sync_itv_timer expired twice            : no
Has syncReceiptTimeoutTime expired               : no
PortAnnounceReceive state machine variables:
Current state                                    : RECEIVE
An announce message is ready to be processed     : no
PortAnnounceInformation state machine variables:
Current state                                    : POST_DISABLED
Expired announce information                     : yes
PortAnnounceTransmit state machine variables:
Current state                                    : POST_IDLE
Trigger announce information                     : no

Statistics:
Sync messages received                 : 0
Follow Up messages received            : 0
Path Delay Request messages received   : 0
Path Delay Response messages received  : 0
Path Delay messages threshold exceeded : 0
Path Delay Follow Up messages received : 0
Announce messages received             : 0
ptp messages discarded                 : 0
Sync reception timeout                 : 0
Announce reception timeout             : 0
Path Delay Requests without a response : 173
Sync messages sent                     : 0
Follow Up messages sent                : 0
Path Delay Request messages sent       : 174
Path Delay Response messages sent      : 0
Path Delay Response FUP messages sent  : 0
Announce messages sent                 : 0

pc side application output
image

Environment (please complete the following information):

  • OS: (e.g. Linux,)
  • Toolchain (e.g Zephyr SDK, ...)
  • Commit SHA or Version used: a8a92ce
@hakehuang
Copy link
Collaborator Author

@hakehuang hakehuang commented Oct 28, 2020

@mmahadevan108
Copy link
Collaborator

@mmahadevan108 mmahadevan108 commented Oct 29, 2020

I see this issue in release 2.3 as well.

@hakehuang
Copy link
Collaborator Author

@hakehuang hakehuang commented Oct 30, 2020

@mmahadevan108 , you can assign to me, as I have better SDK team support.

@github-actions
Copy link

@github-actions github-actions bot commented Jan 3, 2021

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

@github-actions github-actions bot added the Stale label Jan 3, 2021
@MaureenHelm MaureenHelm removed the Stale label Jan 4, 2021
@hakehuang
Copy link
Collaborator Author

@hakehuang hakehuang commented Mar 4, 2021

I find this is not dirver issue, as from wireshark, I can see the ptpv2 package, the problem now is that:

  1. connect board to PC
    PC is running the gptp application, and its in master mode keep sending sync package, but no pdelay followup send. the board is running in DISABLED, with no pdelay follow up resp send, then it keeps resend pdelay package.
  2. connect two frdmk64 board, the two board both switch to master mode, and sending sync package.
  3. connect frdmk64f with mimxtr1060_evk, the behaviour is the same as connect frdmk64 to PC.

so I guess there are some state machine confliction while connection with different accuracy timer instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants