Hi Erez,
You had a good point :-)
I wrote the message as a commit message - ie what will be the case after
applying the patch. I can see now that it was confusing and I should have
provided the info
of the issue first.
Problem description attached in the last mail with the results of the pmc
commands
Greetings
Joanna
From: Geva, Erez <erez.geva....@siemens.com>
Sent: Monday, 8 November 2021 11:10
To: Joanna Yurdal <j...@trackman.com>
Cc: linuxptp-devel@lists.sourceforge.net <linuxptp-devel@lists.sourceforge.net>
Subject: RE: [Linuxptp-devel] [PATCH] Set grandmasterIdentity to
localClockIdentity
Hi,
You wrote "gmPresent" set to false.
In this mail you show that "gmPresent" is true.
I did not check the patch.
Only ask to write a more understandable and comprehensive explanation for the
patch.
Explanation that describe the issue/bug/problem properly, and how is your patch
fix the problem.
This is the first step before we actually read and check the patch itself.
I did not say there is no problem, or that the patch is incorrect.
We simply ask questions politely in the hope you get the hint.
Erez
-----Original Message-----
From: Joanna Yurdal <j...@trackman.com>
Sent: Monday, 8 November 2021 10:44
To: Geva, Erez (ext) (DI PA DCP R&D 3) <erez.geva....@siemens.com>
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Set grandmasterIdentity to
localClockIdentity
Without the proposed patch the result of pmc "get time_status" when lost
synchronization with external GM shows:
pmc -u -b 0 'get time_status' :
c86314.fffe.30006e-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 192
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity ec4670.fffe.00ee5f
while result of the "get port_data_set" is:
c86314.fffe.30006e-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
portIdentity c86314.fffe.30006e-1
portState LISTENING
logMinDelayReqInterval 1
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2
After applying the patch the gmIdentity and gmPresent are the same as when
issued right after ptp4l startup (before any synchronization with external GM) :
c86314.fffe.30006e-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 126
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent false
gmIdentity c86314.fffe.30006e
Actually it may also be relevant to reset master_offset on lost sync. Combined
patch below:
--- a/clock.c 2021-11-08 10:41:45.027820026 +0100
+++ b/clock.c 2021-11-08 10:42:50.656801920 +0100
@@ -1994,6 +1994,7 @@
if (!tmv_is_zero(c->initial_delay))
tsproc_set_delay(c->tsproc, c->initial_delay);
c->ingress_ts = tmv_zero();
+ c->master_offset = tmv_zero();
c->path_delay = c->initial_delay;
c->master_local_rr = 1.0;
c->nrr = 1.0;
@@ -2001,6 +2002,7 @@
if (cid_eq(&best_id, &c->dds.clockIdentity)) {
pr_notice("selected local clock %s as best master",
cid2str(&best_id));
+ c->dad.pds.grandmasterIdentity = c->dds.clockIdentity;
} else {
pr_notice("selected best master clock %s",
cid2str(&best_id));
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
