Re: [Linuxptp-devel] [PATCH v2 1/1] Add scaledLastGmFreqChange computation
eqChange);
> tsn->gmTimeBaseIndicator = ntohs(tsn->gmTimeBaseIndicator);
> scaled_ns_n2h(>lastGmPhaseChange);
> tsn->gmPresent = ntohl(tsn->gmPresent);
> @@ -582,7 +582,7 @@ static void mgt_pre_send(struct management_tlv *m,
> struct tlv_extra *extra)
> tsn->master_offset = host2net64(tsn->master_offset);
> tsn->ingress_time = host2net64(tsn->ingress_time);
> tsn->cumulativeScaledRateOffset =
> htonl(tsn->cumulativeScaledRateOffset);
> - tsn->scaledLastGmPhaseChange =
> htonl(tsn->scaledLastGmPhaseChange);
> + tsn->scaledLastGmFreqChange =
> htonl(tsn->scaledLastGmFreqChange);
> tsn->gmTimeBaseIndicator = htons(tsn->gmTimeBaseIndicator);
> scaled_ns_h2n(>lastGmPhaseChange);
> tsn->gmPresent = htonl(tsn->gmPresent);
> @@ -798,7 +798,7 @@ static int org_post_recv(struct organization_tlv *org)
> f->cumulativeScaledRateOffset =
> ntohl(f->cumulativeScaledRateOffset);
> f->gmTimeBaseIndicator =
> ntohs(f->gmTimeBaseIndicator);
> scaled_ns_n2h(>lastGmPhaseChange);
> - f->scaledLastGmPhaseChange =
> ntohl(f->scaledLastGmPhaseChange);
> + f->scaledLastGmFreqChange =
> ntohl(f->scaledLastGmFreqChange);
> break;
>
> case 2:
> @@ -860,7 +860,7 @@ static void org_pre_send(struct organization_tlv *org)
> f->cumulativeScaledRateOffset =
> htonl(f->cumulativeScaledRateOffset);
> f->gmTimeBaseIndicator =
> htons(f->gmTimeBaseIndicator);
> scaled_ns_h2n(>lastGmPhaseChange);
> - f->scaledLastGmPhaseChange =
> htonl(f->scaledLastGmPhaseChange);
> + f->scaledLastGmFreqChange =
> htonl(f->scaledLastGmFreqChange);
> break;
> }
> } else if (0 == memcmp(org->id, itu_t_id, sizeof(itu_t_id))) {
> diff --git a/tlv.h b/tlv.h
> index 8b51ffd..ce87c72 100644
> --- a/tlv.h
> +++ b/tlv.h
> @@ -331,7 +331,7 @@ struct follow_up_info_tlv {
> Integer32 cumulativeScaledRateOffset;
> UInteger16gmTimeBaseIndicator;
> ScaledNs lastGmPhaseChange;
> - Integer32 scaledLastGmPhaseChange;
> + Integer32 scaledLastGmFreqChange;
> } PACKED;
>
> struct ieee_c37_238_2011_tlv {
> @@ -380,7 +380,7 @@ struct time_status_np {
> int64_t master_offset; /*nanoseconds*/
> int64_t ingress_time; /*nanoseconds*/
> Integer32 cumulativeScaledRateOffset;
> - Integer32 scaledLastGmPhaseChange;
> + Integer32 scaledLastGmFreqChange;
> UInteger16gmTimeBaseIndicator;
> ScaledNs lastGmPhaseChange;
> Integer32 gmPresent;
> --
> 2.42.0
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
--
*Luigi 'Comio' Mantellini*
My Professional Profile <http://www.linkedin.com/in/comio>
*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH 0/1] Support for Port level Perforamnce Monitoring Counters
Thanks for your time. What do you mean with "PUSH" message? I agree with you in order to keep it simple. ciao luigi Il giorno ven 10 nov 2023 alle ore 17:58 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Fri, Nov 10, 2023 at 07:58:14AM +0100, Luigi 'Comio' Mantellini wrote: > > > Using just polling on UDS is a bad idea IMHO because you need to capture > at > > the exact same time point all counters of all ports spending a lot of > > effort and cpu. > > So make it into a PUSH message. > > > It's better to have the gathering > > under the hood and a way to inquiry the system. > > No, I disagree. It should be done externally, because most people > don't want or need this. These statistics are a waste of time, and I > won't make the program more complex just to support silly stuff. > > Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 1/2] msg: Enable changing PTP message header version
LLOW_UP | > > > >> p->transportSpecific; - fup->header.ver= > > PTP_VERSION; > > > >> + fup->header.ver= ptp_hdr_ver; > > > >> fup->header.messageLength = sizeof(struct > > pdelay_resp_fup_msg); > > > >> fup->header.domainNumber = m->header.domainNumber; > > > >> fup->header.correction = m->header.correction; > > > >> @@ -3204,7 +3204,7 @@ port_management_construct(struct PortIdentity pid, > > > >> struct port *ingress, msg->hwts.type = ingress->timestamping; > > > >> > > > >> msg->header.tsmt = MANAGEMENT | > > > >> ingress->transportSpecific; - msg->header.ver= > > > >> PTP_VERSION; > > > >> + msg->header.ver= ptp_hdr_ver; > > > >> msg->header.messageLength = sizeof(struct management_msg); > > > >> msg->header.domainNumber = > > > >> clock_domain_number(ingress->clock); msg->header.sourcePortIdentity = > pid; > > > >> -- > > > >> 2.30.2 > > > >> > > > >> > > > >> > > > >> ___ > > > >> Linuxptp-devel mailing list > > > >> Linuxptp-devel@lists.sourceforge.net > > > >> > > > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sour > > > >> > > ceforge.net > %2Flists%2Flistinfo%2Flinuxptp-devel=05%7C01%7Cluigi.mantell > > > >> > > ini%40sm-optics.com > %7C7209ac53114f49d6817f08dbe1eec643%7C213385be51b14c00838 > > > >> > > > 4b599671fbf95%7C0%7C0%7C638352187880607373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > >> > > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > > > >> ata=FZoMXrd7WE%2BTj4KlbTTGipc8wdP2XrF9x%2BAq8oS0y2Q%3D=0 > > > > > > > > -- > > > > *Luigi Mantellini* > > > > Senior Software Developer > > > > Tel. (+39) 342 182 3893 > > > > luigi.mantell...@sm-optics.com <mailto:luigi.mantell...@sm-optics.com> > > > > > > > > > > > > *SM-Optics s.r.l.* > > > > SIAE Microelettronica Group > > > > Via Michelangelo Buonarroti, 2 > > > > 20093 Cologno Monzese, Milano > > > > ITALY > > > > Tel. (+39) 02 273 251 > > > > Fax (+39) 02 253 > > > > https://www.sm-optics.com <https://www.sm-optics.com> > > > > > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 1/1] Add the PORTS_STATS_2_NP Management message.
I Richard,
Thanks for your feedback.
As already said in the previous email, for PM (Annex j, the final goal)
purposes it's mandatory to capture all counters in order to be coherent. In
order to avoid overloading the existing PORT_STATS_NP message I added the
PORT_STATS_2_NP that carries also the additional information. This is the
only way that I can imagine in order to have the counters snapshot in an
atomic way. We cannot carry two GET queries in the same management message
and we cannot send two separate GET queries (ie, PORT_STATS_NP and
PORT_BAD_MESSAGES_NP) because the answers will be referred to different
time point and it's not correct.
Thanks again,
luigi
Il giorno ven 10 nov 2023 alle ore 06:40 Richard Cochran <
richardcoch...@gmail.com> ha scritto:
> On Wed, Sep 06, 2023 at 09:36:38AM +0200, Luigi Mantellini wrote:
> > The PORTS_STATS_2_NP carries all the PORTS_STATS_NP RX/TX counters
> > adding room for extra counters (up to 16 counters for RX and TX).
> > Not all counters are filled yet.
> >
> > The PORTS_STATS_2_NP TLV has the following definition:
> >
> > struct port_stats_2_np {
> > struct PortIdentity portIdentity; // As PORT_STATS_NP
> > struct PortStats stats; // As PORT_STATS_NP
> > struct PortStats extraStats; // Extra room
> > } PACKED;
> >
> > The proposed implementation adds the following counters:
> >
> > Offset Dir Description
> > 0x00 RX Bad Message
> > 0x01 RX Bad Protocol
> > 0x02 RX Fail on Receive
> > 0x03 RX Missing Timestamp
> > 0x04 RX Announce from Foreign Masters (used by 1588-2019 Annex J)
> > 0x05 RX Announce from current Master
> > 0x02 TX Fail on Transmit
> > 0x03 TX Missing Timestamp
>
> Please don't overload the existing rx/tx message counters in this way.
>
> If you really want to count "Bad Message" etc, please create a new
> data structure with fields like "bad_message" etc.
>
> Thanks,
> Richard
>
--
*Luigi 'Comio' Mantellini*
My Professional Profile <http://www.linkedin.com/in/comio>
*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH 0/1] Support for Port level Perforamnce Monitoring Counters
Sure, the Annex J is silly but the customers ask for it. :( The idea is to keep current and the last snapshot (15m, 1h, 24h) demanding the complete history to the external monitor. Using just polling on UDS is a bad idea IMHO because you need to capture at the exact same time point all counters of all ports spending a lot of effort and cpu. In addition the counters must be gathered in an atomic way in order to be coherent with each other. It's better to have the gathering under the hood and a way to inquiry the system. Furthermore I will start again on this topic next year, and I'm collecting all the feedback to produce an acceptable solution. luigi Il giorno ven 10 nov 2023 alle ore 06:33 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Fri, Aug 18, 2023 at 02:34:54PM +0200, Luigi Mantellini wrote: > > Dear All, > > > > Starting from IEEE 1588-2019 Annex J, I'm trying to introduce a > Performace > > monitoring Counters. > > > > The standard asks to keep up 98 records (96 for 15min records and 2 for > 24h > > records). > > > > I tried to follow a more general approach keeping different circular > buffer > > for 15min and 24h (and adding also 1h for test purpose). > > > > The patch need to be split, of course, but it's a starting point to have > any > > feedbacks. > > My only feedback is: > > - the statistics in Annex J are silly, but > > - if you really want those, please write a stand alone program that > gathers the statistics from data input via the UDS interface > > Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 0/6] Use precise frequency for TX SYNC messages
Hi Miroslav, find my inline answers. Il giorno mer 26 apr 2023 alle ore 11:15 Miroslav Lichvar < mlich...@redhat.com> ha scritto: > On Wed, Apr 26, 2023 at 10:43:52AM +0200, Luigi 'Comio' Mantellini wrote: > > Hi Miroslav, > > > > Sync is already sent using a constant interval as required by Standard > even > > if it is lower than the nominal frequency for the actual implementation > > (stop and rearm). > > It's not constant. It's randomized by the scheduling of the ptp4l > process. If you see two servers sending sync messages at the same > time, you can expect their transmissions to slowly drift away from > each other. > You are right, but I don't understand why there are advantages to having a drift. If you have two servers (on the same CPU) you still haven't any collision on TX syncs because the settimer will be called at a different time on each server (and on each master port). Having servers on different nodes will give a drift because there is not any shared clock in this case. BTW in a scenario you can have just a couple of servers to handle two domains, and collision is improbable and must not be a problem. In addition, using periodic timers will permit you to identify easily missing ticks for scheduling issues. This is very useful during debugging of your node when your CPU is not dedicated. > > > The sync is forged by master as a one-to-many message that does not > > saturate the link, the randomization is required for the messages from > > Clients to Master (Delay-Req) in order to avoid congestion on Master. > > General messages are randomized also. > > The same thing needs to be considered for multiple servers in > different domains on the same communication path. > Considering servers on the same CPU, having periodic timers doesn't imply that TX sync are colliding because each server will arm the timers in a different time (for each port). I still do not understand why you speak about congestion/collision. Messages that can cause CPU or Network overload are already randomized. SYNC doesn't require to be randomized at all. > > Speaking about messages collision in TX path, this is not an issue here > > because your HW timestamp will (should) set the correct TS value at the > end > > of TX queue. On the RX side, the TS is applied just before the RX queue. > > If all NICs and switches/routers had perfect HW timestamping, I might > agree. > > > As reported by Richard, the conformance is not impacted by the proposed > fix. > > You have still not explained what is the issue you are trying to fix. > > Is there some specification that requires the average sync interval to > be within 0.1% of the logSyncInterval? I hope it's not someone > complaining about a test report not having a round number. > During test and qualification the SW implementation has been compared with HW implementations on Telecom grade devices. A warning message has been reported to me from a customer regarding the TX tolerance. You are right saying that 0.1% is not an issue but I proposed my patch in order to improve the precision and also add a debug messages when we lost ticks in transmission (eg. for CPU overload). ciao -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 0/6] Use precise frequency for TX SYNC messages
Hi Miroslav, Sync is already sent using a constant interval as required by Standard even if it is lower than the nominal frequency for the actual implementation (stop and rearm). In other hands, you already have the depicted problems on your HW, if any, but on a different resonance frequency. The sync is forged by master as a one-to-many message that does not saturate the link, the randomization is required for the messages from Clients to Master (Delay-Req) in order to avoid congestion on Master. General messages are randomized also. Speaking about messages collision in TX path, this is not an issue here because your HW timestamp will (should) set the correct TS value at the end of TX queue. On the RX side, the TS is applied just before the RX queue. As reported by Richard, the conformance is not impacted by the proposed fix. ciao luigi Il giorno mer 26 apr 2023 alle ore 10:17 Miroslav Lichvar < mlich...@redhat.com> ha scritto: > On Thu, Mar 30, 2023 at 08:08:12AM +0200, Luigi Mantellini wrote: > > The actual ptp4l implementation rearms timers after the expiration. This > approach doesn't permit to have a precise TX SYNC message scheduling. > > During my test the TX SYNC frequency is slightly lower the expectation > (eg 15.99Hz vs 16Hz). > > Can you please explain advantages of using a constant interval? > > Generally, sending timing sensitive messages over network in a > constant interval sounds like a bad idea to me. If there are multiple > hosts doing that (e.g. PTP servers in different domains) and they > happen to collide in their transmissions times (which requires > queueing and potentially impacts timestamp accuracy), this is more > likely to repeat frequently. If anything, I'd expect more randomness > to be added to the interval. > > -- > Miroslav Lichvar > > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 0/6] Use precise frequency for TX SYNC messages
Announce messages are randomized using the set_tmo_random() call. ciao luigi Il giorno mer 26 apr 2023 alle ore 04:57 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Tue, Apr 25, 2023 at 06:23:53PM +0200, Luigi 'Comio' Mantellini wrote: > > Any review on this patchset? > > I'm working on releasing v4.0. Once that is done, I'll start > reviewing new stuff once again. > > Without having looked at your patch series, I've wanted to convert > from one shot to periodic timers just because it looks better (even > though it doesn't affect conformance or performance). > > But shouldn't Annouce messages be periodic, too? > > Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 0/6] Use precise frequency for TX SYNC messages
Any review on this patchset? Ciao Luigi Il gio 30 mar 2023, 08:08 Luigi Mantellini ha scritto: > The actual ptp4l implementation rearms timers after the expiration. This > approach doesn't permit to have a precise TX SYNC message scheduling. > During my test the TX SYNC frequency is slightly lower the expectation (eg > 15.99Hz vs 16Hz). > > The following patchset uses non blocking timers and only for TX SYNC timer > implements a precise periodic timer. > Before to enable the periodic timer we have to: > - read the timer file descriptors after the expiration in order to have > the expirations counter (useful for debug also); > - avoid to touch timers with a timerfd_settime() before the read() call, > this required to rearrange the fd array and split the announce and rx sync > code; > - remove timerfd_settime() on tx sync expiration. > > History: > v3 Small review > > Luigi Mantellini (6): > Use FD_EVENT and FD_GENERAL instead numeric values. > Rearrange the fdarray in order to serve timers before sockets fds. > Flush timer file descriptors after expiration. > Split announce/sync_rx timer rearm on expiration. > Use Non-blocking timer file descriptors. > Use periodic timer for TX SYNC timeout. > > e2e_tc.c | 28 +++ > fd.h | 4 +-- > p2p_tc.c | 28 +++ > port.c | 105 +++ > port.h | 10 ++ > raw.c| 4 +-- > udp.c| 4 +-- > udp6.c | 4 +-- > 8 files changed, 135 insertions(+), 52 deletions(-) > > -- > 2.40.0 > > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 6/6] Use periodic timer for TX SYNC timeout.
Thanks... i will produce a v3 after some feedback > Sorry I forgot another hint. Please use the 'git format-patch' with the patch > seria iteration flag '-v '. So we can differentiate the mails as newer :-) > This will change the subject to something like "Subject: [PATCH v2 0/6] " ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Use periodic timer for TX SYNC timeout
Hi Erez, sorry, I usually use pull requests. Il giorno mer 29 mar 2023 alle ore 14:29 Erez ha scritto: > > > On Wed, 29 Mar 2023 at 11:28, Luigi Mantellini > wrote: > >> The actual ptp4l implementation rearms timers on timeut. This doesn't >> permit to have a precise TX SYNC > > > Did you misspell "timeout"? > yes > > >> message scheduling. >> The following patchset uses non blocking timers and only for TX SYNC >> timer a periodic timer is used. >> In addition, a periodic timer requires to read (and flush) the file >> descriptor and a new timerfd_flush() function has been introduced for this. >> >> > Cool :-) > This explanation is coherent. > > We usually add a cover letter, using 'git format-patch' with the > '--cover-letter' options. > And please add a short explanation on the issue you solve to each patch > (relevant to each patch). > And if the solution is not trivial, a short explanation on the solution as > well. > > I will provide it soon. Can you give a look at the code also? I tested with a custom ethernet device and I cannot test with common hw (like intel nic). Thanks, luigi Thanks > Erez > > >> e2e_tc.c | 28 +--- >> fd.h | 4 ++-- >> p2p_tc.c | 28 +--- >> port.c | 102 >> -- >> port.h | 10 ++ >> raw.c| 4 ++-- >> udp.c| 4 ++-- >> udp6.c | 4 ++-- >> 8 files changed, 132 insertions(+), 52 deletions(-) >> >> [PATCH 1/6] Use constant FD_EVENT and FD_GENERAL instead numeric >> [PATCH 2/6] Rearrange the fdarray in order to serve timers before >> [PATCH 3/6] Flush timer fd after expiration >> [PATCH 4/6] Split announce/sync_rx timer rearm on expiration fd >> [PATCH 5/6] Use Non-blocking timer file descriptors >> [PATCH 6/6] Use periodic timer for TX SYNC timeout >> >> >> >> ___ >> Linuxptp-devel mailing list >> Linuxptp-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel >> > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] bmca: Correctly handle PortNumber in PortId comparison
s/same/some/g
sorry
Il giorno ven 18 nov 2022 alle ore 08:43 Luigi Mantellini <
luigi.mantell...@gmail.com> ha scritto:
> From: Luigi Mantellini
>
> The PortId is defined as a couple of ClockId (an 8-bytes opaque) and the
> PortNumber (UInterger16).
>
> The current implementation compares the entire PortId, consisting of
> ClockId and PortNumber, using a byte-to-byte comparison (memcmp).
> This way doesn't consider the HOST's endianess on PortId part, giving
> wrong results in same case.
>
> Consider the following setup (assuming the same ClockId)
>
> PortId_a = (ClockId, PortNumber=0x1234)
> PortId_b = (ClockId, PortNumber=0x4512)
>
> On a LittleEndian HOST, we obtain the following memory setup:
>
> PortId_a = ... ClockId ... 0x34 0x12
> PortId_b = ... ClockId ... 0x12 0x45
>
> Using just a memcmp() call we obtain the WRONG result PortId_a > PortId_b,
> because the byte-to-byte comparison will check the PortNumber Lower-Byte
> (0x34 vs 0x12) first.
>
> To fix the BCMA implementation we need to split the PortId comparison in:
>
> - ClockId comparison, still using memcmp() on a opaque byte stream
> - PortNumber, using a natural semantic comparison between integer numbers.
>
> In other hands, following the ITU-T G.8275.2 Figure 4, we need to ensure
> the same ordering criteria on all places:
>
> a Compare portIdentities of receiver of A and sender of A
> b Compare portIdentities of receiver of B and sender of B
> c Compare portIdentities of sender of A and sender of B
> d Compare PortNumbers of receiver of A and receiver B
>
> Signed-off-by: Luigi Mantellini
> Signed-off-by: Luigi Mantellini
> ---
> bmc.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/bmc.c b/bmc.c
> index 6ac7aa0..ebc0789 100644
> --- a/bmc.c
> +++ b/bmc.c
> @@ -21,6 +21,17 @@
> #include "bmc.h"
> #include "ds.h"
>
> +static int portid_cmp(struct PortIdentity *a, struct PortIdentity *b)
> +{
> + int diff = memcmp(>clockIdentity, >clockIdentity,
> sizeof(a->clockIdentity));
> +
> + if (diff == 0) {
> + diff = a->portNumber - b->portNumber;
> + }
> +
> + return diff;
> +}
> +
> int dscmp2(struct dataset *a, struct dataset *b)
> {
> int diff;
> @@ -35,7 +46,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> * standard, since there is nothing we can do about it anyway.
> */
> if (A < B) {
> - diff = memcmp(>receiver, >sender,
> sizeof(b->receiver));
> + diff = portid_cmp(>receiver, >sender);
> if (diff < 0)
> return A_BETTER;
> if (diff > 0)
> @@ -44,7 +55,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> return 0;
> }
> if (A > B) {
> - diff = memcmp(>receiver, >sender,
> sizeof(a->receiver));
> + diff = portid_cmp(>receiver, >sender);
> if (diff < 0)
> return B_BETTER;
> if (diff > 0)
> @@ -53,7 +64,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> return 0;
> }
>
> - diff = memcmp(>sender, >sender, sizeof(a->sender));
> + diff = portid_cmp(>sender, >sender);
> if (diff < 0)
> return A_BETTER_TOPO;
> if (diff > 0)
> --
> 2.38.1
>
>
--
*Luigi 'Comio' Mantellini*
My Professional Profile <http://www.linkedin.com/in/comio>
*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] bmc: Fix PortId comparison
The struct is not in network order because it is already converted to
cpu's endianess before to call the bmca.
The patch works in my setup.
Ciao
Luigi
Il gio 17 nov 2022, 19:04 Geva, Erez ha scritto:
> On Mon, 2022-11-14 at 14:25 +0100, Luigi Mantellini wrote:
> > The PortId is defined as a couple of ClockId (an 8-bytes opaque) and
> > the PortNumber (UInterger16).
> > In order to correctly handle the PortId endianess, the comparison has
> > been split in the ClockIds comparison (using memcmp) and PortNumber
> > comparison.
>
> You code do not solve any endianess issue.
> The clock ID is byte stream.
> And port number is 16 bits, it require converting from network order to
> host order, which you do not need here. Becuase port ID are already in
> the same endian here.
>
> As struct PortIdentity is defined as "PACKED", it should not have any
> pad that may cause the memory compare to fail. Of having different
> values in the pad.
>
>
> So memcmp and your "portid_cmp" should give the same result.
>
> I would suggest to replace the memcmp and "portid_cmp" with existing
> pid_eq(const struct PortIdentity *a, const struct PortIdentity *b)
>
>
> And debug and find the real reason you have the bug.
> And than send a real bug fix :-)
>
>
> Erez
>
>
>
>
> > ---
> > bmc.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/bmc.c b/bmc.c
> > index 6ac7aa0..ebc0789 100644
> > --- a/bmc.c
> > +++ b/bmc.c
> > @@ -21,6 +21,17 @@
> > #include "bmc.h"
> > #include "ds.h"
> >
> > +static int portid_cmp(struct PortIdentity *a, struct PortIdentity
> > *b)
> > +{
> > + int diff = memcmp(>clockIdentity, >clockIdentity,
> > sizeof(a->clockIdentity));
> > +
> > + if (diff == 0) {
> > + diff = a->portNumber - b->portNumber;
> > + }
> > +
> > + return diff;
> > +}
> > +
> > int dscmp2(struct dataset *a, struct dataset *b)
> > {
> > int diff;
> > @@ -35,7 +46,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> > * standard, since there is nothing we can do about it
> > anyway.
> > */
> > if (A < B) {
> > - diff = memcmp(>receiver, >sender, sizeof(b-
> > >receiver));
> > + diff = portid_cmp(>receiver, >sender);
> > if (diff < 0)
> > return A_BETTER;
> > if (diff > 0)
> > @@ -44,7 +55,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> > return 0;
> > }
> > if (A > B) {
> > - diff = memcmp(>receiver, >sender, sizeof(a-
> > >receiver));
> > + diff = portid_cmp(>receiver, >sender);
> > if (diff < 0)
> > return B_BETTER;
> > if (diff > 0)
> > @@ -53,7 +64,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> > return 0;
> > }
> >
> > - diff = memcmp(>sender, >sender, sizeof(a->sender));
> > + diff = portid_cmp(>sender, >sender);
> > if (diff < 0)
> > return A_BETTER_TOPO;
> > if (diff > 0)
>
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Introducing SyncESMC (ESMC client) from SyncMonk
Very interesting. Thanks for your effort. Luigi Il gio 20 ott 2022, 07:42 Devasish Dey ha scritto: > Hi All, > > SyncMonk is excited to introduce *SyncESMC*, an implementation for > Ethernet Synchronous Message Channel based on ITU-T G.8264 (03/2018) and > ITU-T G.781(04/2020) standards as a precision timing solution. > > SyncESMC is ITU-T standards compliant, hardware agnostic, easy to > troubleshoot, comes with monitoring and provides complete visibility of the > sync Network. > > Attaching herewith SyncESMC architecture, to have a better understanding > of what makes SyncESMC a standout product in the market. > > Few advantages of design: > >- Single-threaded architecture. >- Hardware agnostic >- Dynamic configuration supported with Sync-Yang, Netconf and SyncCLI. >- Monitoring and visibilities. >- Integrated with Enterprise Linux PTP >- API interface for custom PTP stacks. > > We have also prepared a Docker image for trial and testing to have inputs > for improvement and make it better. > > Docker Hub link: > https://hub.docker.com/repository/docker/syncmonk/syncesmc > Design document: > https://www.linkedin.com/feed/update/urn:li:activity:6988483738686943232 > > Thanks, > Devasish Dey > > Vice President > > Engineering Product Development | SyncMonk Technologies Pvt Limited > +91-783-8079202 > devasish@syncmonk.net > www.syncmonk.net > > [image: 4.png] > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp result doesn't match 1PPS measurement
Dear All, Before creating confusion, I propose the following workflow. - Be confident about your test bench [ ] If you are using an external clock source (provided to Calnex), check the rising-edge of 1PPS signal between your clock source and the Calnex using an oscilloscope. Is it aligned? If not, you cannot be confident regarding Calnex or the oscilloscope. [ ] Still using the oscilloscope, compare the Calnex 1PPS monitor with your DUT (Device Under Test) 1PPS output. If OK, probability you write a wrong Cable Delay in Calnex setup. [ ] Measure the cable delay using an oscilloscope with two probes and a square generator with two identical outputs. - DUT [ ] Validate PPPoETH performance. You should evaluate the timestamps on RX/TX directions to be sure that asymmetries are close 0ns. Calnex offers the two way graphs to accomplish this task. [ ] Validate 1PPS performance. Check again the Cable Delay. [ ] If you have a (huge) delay, your 1PPS output is inserting propagation delay => You need to reclock 1PPS and compensate the output adding a negative offset [ ] If your signal anticipate the calnex (negative offset), your 1PPS output is already reclocked an you need to better estimate the compensation value to put into the registers. This is my workflow... I hope to be useful to you. ciao luigi Il giorno ven 9 set 2022 alle ore 04:53 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Fri, Sep 09, 2022 at 08:45:19AM +0800, Hamilton Alex wrote: > > Hi, Richard: > > I am not quite understand. I am using Calnex master-->board slave, if > the > > linuxptp print out is correct, that means local clock > > has the same frequency and phase as master clock, then the 1PPS out > should > > near the reference 1PPS. > > > > why path asymmetry would affect the 1PPS out? > > You reported a 40 nanosecond phase offset. > > One possible cause is path asymmetry. The PTP assumes the Tx and Rx > transmission delays are exactly equal. However, this is almost never > true. > > Any real asymmetry results in a phase offset that is uncorrectable by > the PTP. > > Because your 40 ns phase offset is very small, you might very well > have path asymmetry somewhere in your system. For example, your PHY > might delay frames longer on Tx than on Rx. > > HTH, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp result doesn't match 1PPS measurement
A delay ~9ms is typical Calnex X behavior. Il giorno gio 8 set 2022 alle ore 15:29 Miroslav Lichvar ha scritto: > > On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > > ptp4l[130171.662]: rms1 max2 freq-49 +/- 3 delay 9058 +/- 0 > > > my board has 1PPS output, I connect it to the master and compared with > > reference PPS. > > however, the 1pps time error is around 40 NS, which means my board is > > ahead of the reference for about 40NS, which doesn't match the result > > dumped by ptp4l. > > ptp4l is just printing the measured offset. It doesn't know the actual error. > > A measured delay of 9 microseconds is huge. That's few kilometers of > cable. What hardware do you use? Does it have PHY or MAC timestamping, > and are those errors compensated? > > -- > Miroslav Lichvar > > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel -- Luigi 'Comio' Mantellini My Professional Profile "UNIX is very simple, it just needs a genius to understand its simplicity." [cit.] ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp result doesn't match 1PPS measurement
s/guile/guide/g Sorry... ciao luigi Il giorno gio 8 set 2022 alle ore 13:56 Luigi 'Comio' Mantellini < luigi.mantell...@gmail.com> ha scritto: > Hi Alex, > > some guile line that I follow during my debug sessions: > > - Are you using a good cable-delay estimation for your cable? (Consider > ~5ns/m for classical eth cables) I suggest you to physically measure the > delay and place it as Dcable cell in Calnex configuration. > - Have you checked about any asymmetry between RX and TX paths? Can you > short-circuit your timestamper to check? You need to ask your FPGA and HW > experts. > - How is the 1PPS driven? Is there any reclocking logic? You need to ask > your FPGA-experts. > > > ciao > > luigi > > > Il giorno gio 8 set 2022 alle ore 13:44 Hamilton Alex < > alexzanda...@gmail.com> ha scritto: > >> Hi: >> I got an issue that linuxptp result doesn't match 1PPS measurement. >> my board is acting as a slave, the calnex is acting as a master with >> reference clock. >> after ptp4l runs, result is below, looks pretty good: >> >> ptp4l[130166.661]: rms1 max2 freq-50 +/- 4 delay 9059 +/- >> 0 >> ptp4l[130167.661]: rms1 max1 freq-50 +/- 2 delay 9058 +/- >> 0 >> ptp4l[130168.662]: rms1 max2 freq-52 +/- 3 delay 9058 +/- >> 1 >> ptp4l[130169.661]: rms1 max3 freq-49 +/- 4 delay 9058 +/- >> 0 >> ptp4l[130170.661]: rms1 max2 freq-50 +/- 4 delay 9059 +/- >> 0 >> ptp4l[130171.662]: rms1 max2 freq-49 +/- 3 delay 9058 +/- >> 0 >> >> my board has 1PPS output, I connect it to the master and compared with >> reference PPS. >> however, the 1pps time error is around 40 NS, which means my board is >> ahead of the reference for about 40NS, which doesn't match the result >> dumped by ptp4l. >> >> anyone has met similar issue before? how to debug such issue? >> >>- >> >>1ppsTE = (T1ppsMeasIngress – Dcable) - TRef >> >> >> https://calnexsolutions.atlassian.net/wiki/spaces/KB/pages/71991334/T-BC+Time+Error+Metrics >> >> Thanks >> Alex >> >> ___ >> Linuxptp-devel mailing list >> Linuxptp-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel >> > > > -- > *Luigi 'Comio' Mantellini* > My Professional Profile <http://www.linkedin.com/in/comio> > > *"UNIX is very simple, it just needs a genius to understand its > simplicity." [cit.]* > > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp result doesn't match 1PPS measurement
Hi Alex, some guile line that I follow during my debug sessions: - Are you using a good cable-delay estimation for your cable? (Consider ~5ns/m for classical eth cables) I suggest you to physically measure the delay and place it as Dcable cell in Calnex configuration. - Have you checked about any asymmetry between RX and TX paths? Can you short-circuit your timestamper to check? You need to ask your FPGA and HW experts. - How is the 1PPS driven? Is there any reclocking logic? You need to ask your FPGA-experts. ciao luigi Il giorno gio 8 set 2022 alle ore 13:44 Hamilton Alex < alexzanda...@gmail.com> ha scritto: > Hi: > I got an issue that linuxptp result doesn't match 1PPS measurement. > my board is acting as a slave, the calnex is acting as a master with > reference clock. > after ptp4l runs, result is below, looks pretty good: > > ptp4l[130166.661]: rms1 max2 freq-50 +/- 4 delay 9059 +/- > 0 > ptp4l[130167.661]: rms1 max1 freq-50 +/- 2 delay 9058 +/- > 0 > ptp4l[130168.662]: rms1 max2 freq-52 +/- 3 delay 9058 +/- > 1 > ptp4l[130169.661]: rms1 max3 freq-49 +/- 4 delay 9058 +/- > 0 > ptp4l[130170.661]: rms1 max2 freq-50 +/- 4 delay 9059 +/- > 0 > ptp4l[130171.662]: rms1 max2 freq-49 +/- 3 delay 9058 +/- > 0 > > my board has 1PPS output, I connect it to the master and compared with > reference PPS. > however, the 1pps time error is around 40 NS, which means my board is > ahead of the reference for about 40NS, which doesn't match the result > dumped by ptp4l. > > anyone has met similar issue before? how to debug such issue? > >- > >1ppsTE = (T1ppsMeasIngress – Dcable) - TRef > > > https://calnexsolutions.atlassian.net/wiki/spaces/KB/pages/71991334/T-BC+Time+Error+Metrics > > Thanks > Alex > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] servo: allows servo state transition back from S3 to S2
Dear All, I would like to advise that a transition from S3 (stable_lock) -> S2 (lock) can create issues with Transient Noise or Transfer Noise behaviours when write phase mode is also used. I tried to introduce this transition in the past, but I was unable to choose the best threshold. In my opinion, any patch should be tested wrt ITU-T G8273.2. ciao luigi Il giorno gio 17 feb 2022 alle ore 03:08 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Mon, Jan 10, 2022 at 01:15:21PM +, Modrzejewski, Pawel via > Linuxptp-devel wrote: > > Currently servo state stays in S3 (SERVO_LOCKED_STABLE) even though > > clock offset increases above servo_offset_threshold value (but is still > > below step_threshold value). > > That is on purpose. By design this state variable tracks the initial > convergence, nothing more. The use case is the automotive profile > which has an idea of "fast" start. > > > It will still switch to S0 (SERVO_UNLOCKED) when clock offset is bigger > than > > step_threshold. It allows one to check only servo state and potentially > simplifies > > synchronization status monitoring. > > Simplifies? how? > > There is no monitoring of the servo state. This is a purely internal > state variable. > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Need suggestion on step_threshold
(my message was rejected... why?) Hi ramesh, I don't know your system's precision. I tuned the step_threshold and first_step_threshold values following this criteria: Given my system's precision ( ha scritto: > > hi, > > Rms value of PTP slave/support is taking longer duration (1-2 hours) to come > back to single/two digit value. > > Oct 29 01:21:37 ptp4l_slave: [2115639.889] handle_state_decision_event > PS_LISTENING > Oct 29 01:21:37 ptp4l_slave: [2115640.178] selected best master clock > 28affd.fffe.e5de3f > Oct 29 01:21:37 ptp4l_slave: [2115640.178] handle_state_decision_event > PS_SLAVE > Oct 29 01:21:37 ptp4l_slave: [2115640.178] port 1: LISTENING to UNCALIBRATED > on RS_SLAVE > Oct 29 01:21:37 ptp4l_slave: [2115640.178] PS_SLAVE: port_e2e_transition > Oct 29 01:21:37 ptp4l_slave: [2115640.242] port 1: UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > Oct 29 01:21:37 ptp4l_slave: [2115640.242] PS_SLAVE: port_e2e_transition > Oct 29 01:21:38 ptp4l_slave: [2115640.370] rms 10301244690663 max > 15341881743901 freq -9 +/- 0 delay -16376519 +/- 2081539 > Oct 29 01:21:39 ptp4l_slave: [2115641.370] rms 8782943571542 max > 8783365601487 freq -9 +/- 0 delay -13254922 +/- 1790307 > Oct 29 01:21:39 ptp4l_slave: [2115641.434] selected best master clock > 28affd.fffe.e5de3f > Oct 29 01:21:39 ptp4l_slave: [2115641.435] handle_state_decision_event > PS_SLAVE > Oct 29 01:21:40 ptp4l_slave: [2115642.374] rms 8782045654609 max > 8782467416190 freq -9 +/- 0 delay -10871120 +/- 1851783 > > Oct 29 03:25:03 ptp4l_slave: [2123045.451] rms 2119240296684 max > 2119664072935 freq -9 +/- 0 delay -11533365 +/- 1437648 > > We are using below values in the ptp config file. > step_threshold 0.0 > first_step_threshold0.2 > max_frequency 9 > clock_servo pi > sanity_freq_limit 2 > > Can you please suggest what should be proper configuration? > > regards, > Ramesh > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel -- Luigi 'Comio' Mantellini My Professional Profile "UNIX is very simple, it just needs a genius to understand its simplicity." [cit.] ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Need suggestion on step_threshold
Hi ramesh, I don't know your system's precision. I tuned the step_threshold and first_step_threshold values following this criteria: Given my system's precision ( ha scritto: > hi, > > Rms value of PTP slave/support is taking longer duration (1-2 hours) to > come back to single/two digit value. > > Oct 29 01:21:37 ptp4l_slave: [2115639.889] handle_state_decision_event > PS_LISTENING > Oct 29 01:21:37 ptp4l_slave: [2115640.178] selected best master clock > 28affd.fffe.e5de3f > Oct 29 01:21:37 ptp4l_slave: [2115640.178] handle_state_decision_event > PS_SLAVE > Oct 29 01:21:37 ptp4l_slave: [2115640.178] port 1: LISTENING to > UNCALIBRATED on RS_SLAVE > Oct 29 01:21:37 ptp4l_slave: [2115640.178] PS_SLAVE: port_e2e_transition > Oct 29 01:21:37 ptp4l_slave: [2115640.242] port 1: UNCALIBRATED to SLAVE > on MASTER_CLOCK_SELECTED > Oct 29 01:21:37 ptp4l_slave: [2115640.242] PS_SLAVE: port_e2e_transition > Oct 29 01:21:38 ptp4l_slave: [2115640.370] rms 10301244690663 max > 15341881743901 freq -9 +/- 0 delay -16376519 +/- 2081539 > Oct 29 01:21:39 ptp4l_slave: [2115641.370] rms 8782943571542 max > 8783365601487 freq -9 +/- 0 delay -13254922 +/- 1790307 > Oct 29 01:21:39 ptp4l_slave: [2115641.434] selected best master clock > 28affd.fffe.e5de3f > Oct 29 01:21:39 ptp4l_slave: [2115641.435] handle_state_decision_event > PS_SLAVE > Oct 29 01:21:40 ptp4l_slave: [2115642.374] rms 8782045654609 max > 8782467416190 freq -9 +/- 0 delay -10871120 +/- 1851783 > > Oct 29 03:25:03 ptp4l_slave: [2123045.451] rms 2119240296684 max > 2119664072935 freq -9 +/- 0 delay -11533365 +/- 1437648 > > We are using below values in the ptp config file. > step_threshold 0.0 > first_step_threshold0.2 > max_frequency 9 > clock_servo pi > sanity_freq_limit 2 > > Can you please suggest what should be proper configuration? > > regards, > Ramesh > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Porting ptp4l for custom timestamp hardware
...or try to hack the raw transport (raw.c/raw.h) good lock again, ciao lugi Il giorno ven 1 ott 2021 alle ore 15:44 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Fri, Oct 01, 2021 at 06:49:05PM +0530, Mohan K wrote: > > > The driver for FPGA is in user-space and it is a memory mapped device. > > > > Kindly throw some high-level inputs on how this porting can be achieved. > > > Write a proper kernel device driver. > > > Good luck, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Announce message generates SDE on MasterOnly port
Just like other process_*() that quickly return when the port state doesn't require to process the incoming message, we can add a test into process_announce() in order to avoid wasting the cpu. This is not a special case, the announce messages should be ignored on Master-only ports and the ports state cannot change. As side note, In my testing scenario the master-only ports receive announce messages and when the slave port loses the signal the node evolves in grand-master flooding the log with "assuming the grand master role" message. Not a critical issue, of course... but in this case we lost time with logging and blocking the main loop. My 2Eurocents. ciao luigi Il giorno mar 4 mag 2021 alle ore 14:02 Richard Cochran ha scritto: > > On Mon, May 03, 2021 at 06:52:02PM +0200, Luigi 'Comio' Mantellini wrote: > > I noticed that the Announce messages received on MasterOnly ports > > generate a SDE condition in bc_event(). > > and so what? What is the problem? > > > I think that we can return > > EV_NONE when the port is a master_only (or we can skip the > > process_annonce() at all). Is it correct? > > No thanks, I don't want special cases sprinkled all over. > > Thanks, > Richard -- Luigi 'Comio' Mantellini My Professional Profile "UNIX is very simple, it just needs a genius to understand its simplicity." [cit.] ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Port down and sde
Hi Richard,
not a problem, of course. I'm just speaking about code cleanup.
luigi
Il giorno mar 4 mag 2021 alle ore 14:00 Richard Cochran <
richardcoch...@gmail.com> ha scritto:
> On Mon, May 03, 2021 at 06:45:56PM +0200, Luigi 'Comio' Mantellini wrote:
> > /*
> > * A port going down can affect the BMCA result.
> > * Force a state decision event.
> > */
> > if (p->link_status & LINK_DOWN)
> > clock_set_sde(p->clock, 1);
> >
> > I think that should be removed
>
> Why? What problem does it cause?
>
> > because the calling code look like this:
> >
> > case FD_RTNL:
> > pr_debug("port %hu: received link status notification",
> portnum(p));
> > transport_rtnl_link_status(p->trp, fd, p->name,
> port_link_status, p);
> > if (p->link_status == (LINK_UP | LINK_STATE_CHANGED))
> > return EV_FAULT_CLEARED;
> > else if ((p->link_status == (LINK_DOWN | LINK_STATE_CHANGED)) ||
> > (p->link_status & TS_LABEL_CHANGED))
> > return EV_FAULT_DETECTED;
> > else
> > return EV_NONE;
> >
> > raising a EV_FAULT_DETECT on LINK_DOWN
>
> So the SDE gets triggered twice? Not really a problem.
>
> Thanks,
> Richard
>
--
*Luigi 'Comio' Mantellini*
My Professional Profile <http://www.linkedin.com/in/comio>
*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] Announce message generates SDE on MasterOnly port
Hi Richard,
Hi All,
(I'm investigating the SDE behavior...)
In my setup I have a couple of MasterOnly ports and we tries to kill
(and recover) the SLAVE port's link in order to measure the
performance.
I noticed that the Announce messages received on MasterOnly ports
generate a SDE condition in bc_event(). I think that we can return
EV_NONE when the port is a master_only (or we can skip the
process_annonce() at all). Is it correct?
bc_event() should look like:
case ANNOUNCE:
if (process_announce(p, msg)) {
event = p->master_only ? EV_NONE : EV_STATE_DECISION_EVENT;
}
break;
(or...
case ANNOUNCE:
if (!p->master_only && process_announce(p, msg))
event = EV_STATE_DECISION_EVENT;
break;
)
Thanks for your opinion,
ciao
luigi
--
Luigi 'Comio' Mantellini
My Professional Profile
"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] Port down and sde
Hi Richard,
Hi All,
I noticed the following code inside port_link_status():
/*
* A port going down can affect the BMCA result.
* Force a state decision event.
*/
if (p->link_status & LINK_DOWN)
clock_set_sde(p->clock, 1);
I think that should be removed because the calling code look like this:
case FD_RTNL:
pr_debug("port %hu: received link status notification", portnum(p));
transport_rtnl_link_status(p->trp, fd, p->name, port_link_status, p);
if (p->link_status == (LINK_UP | LINK_STATE_CHANGED))
return EV_FAULT_CLEARED;
else if ((p->link_status == (LINK_DOWN | LINK_STATE_CHANGED)) ||
(p->link_status & TS_LABEL_CHANGED))
return EV_FAULT_DETECTED;
else
return EV_NONE;
raising a EV_FAULT_DETECT on LINK_DOWN
Is my observation correct?
Thanks in advance.
luigi
--
Luigi 'Comio' Mantellini
My Professional Profile
"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 2/2i v2] Add dynamic portDS.portEnable change.
This patch introduces
- "enable" configuration flag at port level
- support for ENABLE_PORT and DISABLE_PORT TLV commands
---
clock.c | 6 +++-
config.c | 1 +
designated_fsm.c | 36 ---
e2e_tc.c | 11 +++
fd.h | 1 +
p2p_tc.c | 11 +++
pmc_common.c | 9 +++---
port.c | 74 ++--
port.h | 19 +
port_private.h | 4 ++-
ptp4l.8 | 3 ++
11 files changed, 161 insertions(+), 14 deletions(-)
diff --git a/clock.c b/clock.c
index e545a9b..d1ab880 100644
--- a/clock.c
+++ b/clock.c
@@ -1250,7 +1250,11 @@ struct clock *clock_create(enum clock_type type, struct
config *config,
c->dds.numberPorts = c->nports;
LIST_FOREACH(p, >ports, list) {
- port_dispatch(p, EV_INITIALIZE, 0);
+ if (port_enable(p)) {
+ port_dispatch(p, EV_INITIALIZE, 0);
+ } else {
+ port_dispatch(p, EV_DESIGNATED_DISABLED, 0);
+ }
}
port_dispatch(c->uds_rw_port, EV_INITIALIZE, 0);
port_dispatch(c->uds_ro_port, EV_INITIALIZE, 0);
diff --git a/config.c b/config.c
index 4472d3d..b32e0a3 100644
--- a/config.c
+++ b/config.c
@@ -242,6 +242,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_INT("dscp_event", 0, 0, 63),
GLOB_ITEM_INT("dscp_general", 0, 0, 63),
GLOB_ITEM_INT("domainNumber", 0, 0, 127),
+ PORT_ITEM_INT("enable", 1, 0, 1),
PORT_ITEM_INT("egressLatency", 0, INT_MIN, INT_MAX),
PORT_ITEM_INT("fault_badpeernet_interval", 16, INT32_MIN, INT32_MAX),
PORT_ITEM_INT("fault_reset_interval", 4, INT8_MIN, INT8_MAX),
diff --git a/designated_fsm.c b/designated_fsm.c
index d19158b..c6bb692 100644
--- a/designated_fsm.c
+++ b/designated_fsm.c
@@ -44,16 +44,34 @@ enum port_state designated_master_fsm(enum port_state state,
break;
case PS_FAULTY:
- if (event == EV_FAULT_CLEARED) {
+ switch (event) {
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
+ case EV_FAULT_CLEARED:
next = PS_INITIALIZING;
+ break;
+ default:
+ break;
}
break;
+ case PS_DISABLED:
+ if (EV_DESIGNATED_ENABLED == event)
+ next = PS_INITIALIZING;
+ break;
+
case PS_MASTER:
- if (event == EV_FAULT_DETECTED) {
+ switch (event) {
+ case EV_FAULT_DETECTED:
next = PS_FAULTY;
+ break;
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
+ default:
+ break;
}
- break;
default:
break;
@@ -85,13 +103,23 @@ enum port_state designated_slave_fsm(enum port_state state,
break;
case PS_FAULTY:
- if (event == EV_FAULT_CLEARED) {
+ switch (event) {
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
+ case EV_FAULT_CLEARED:
next = PS_INITIALIZING;
+ break;
+ default:
+ break;
}
break;
case PS_SLAVE:
switch (event) {
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
case EV_FAULT_DETECTED:
next = PS_FAULTY;
break;
diff --git a/e2e_tc.c b/e2e_tc.c
index 2f8e821..dea482f 100644
--- a/e2e_tc.c
+++ b/e2e_tc.c
@@ -124,6 +124,8 @@ enum fsm_event e2e_event(struct port *p, int fd_index)
case FD_RTNL:
pr_debug("%s: received link status notification", p->log_name);
rtnl_link_status(fd, p->name, port_link_status, p);
+ if (!p->enable)
+ return EV_NONE;
if (p->link_status == (LINK_UP|LINK_STATE_CHANGED)) {
return EV_FAULT_CLEARED;
} else if ((p->link_status == (LINK_DOWN|LINK_STATE_CHANGED)) ||
@@ -132,6 +134,15 @@ enum fsm_event e2e_event(struct port *p, int fd_index)
} else {
return EV_NONE;
}
+
+ case FD_PORT_ENABLE:
+ pr_debug("%s: received port enable/disable notification",
p->log_name);
+ if (!port_enable_changed(fd, p))
+ return EV_NONE;
+ else if (p->enable)
+ return EV_DESIGNATED_ENABLED;
+ else
+
[Linuxptp-devel] [PATCH 1/2 v2] Add support for commands TLV
---
pmc_common.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/pmc_common.c b/pmc_common.c
index c5cd992..c7d8bed 100644
--- a/pmc_common.c
+++ b/pmc_common.c
@@ -57,6 +57,7 @@
static void do_get_action(struct pmc *pmc, int action, int index, char *str);
static void do_set_action(struct pmc *pmc, int action, int index, char *str);
+static void do_cmd_action(struct pmc *pmc, int action, int index, char *str);
static void not_supported(struct pmc *pmc, int action, int index, char *str);
static void null_management(struct pmc *pmc, int action, int index, char *str);
@@ -280,6 +281,31 @@ static void do_set_action(struct pmc *pmc, int action, int
index, char *str)
}
}
+static void do_cmd_action(struct pmc *pmc, int action, int index, char *str)
+{
+ int code = idtab[index].code;
+
+ switch (action) {
+ case COMMAND:
+ break;
+ case GET:
+ case SET:
+ case RESPONSE:
+ case ACKNOWLEDGE:
+ default:
+ fprintf(stderr, "%s only allows COMMAND\n",
+ idtab[index].name);
+ return;
+ }
+/*
+ switch (code) {
+ case TLV_:
+ pmc_send_cmd_action(pmc, code);
+ break;
+ }
+*/
+}
+
static void not_supported(struct pmc *pmc, int action, int index, char *str)
{
fprintf(stdout, "sorry, %s not supported yet\n", idtab[index].name);
@@ -622,6 +648,31 @@ int pmc_send_set_action(struct pmc *pmc, int id, void
*data, int datasize)
return 0;
}
+int pmc_send_cmd_action(struct pmc *pmc, int id)
+{
+ struct management_tlv *mgt;
+ struct ptp_message *msg;
+ struct tlv_extra *extra;
+
+ msg = pmc_message(pmc, COMMAND);
+ if (!msg) {
+ return -1;
+ }
+ extra = msg_tlv_append(msg, sizeof(*mgt));
+ if (!extra) {
+ msg_put(msg);
+ return -ENOMEM;
+ }
+ mgt = (struct management_tlv *) extra->tlv;
+ mgt->type = TLV_MANAGEMENT;
+ mgt->length = 2;
+ mgt->id = id;
+ pmc_send(pmc, msg);
+ msg_put(msg);
+
+ return 0;
+}
+
struct ptp_message *pmc_recv(struct pmc *pmc)
{
struct ptp_message *msg;
--
2.31.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 2/2] Add dynamic portDS.portEnable change.
This patch introduces
- "enable" configuration flag at port level
- support for ENABLE_PORT and DISABLE_PORT TLV commands
---
clock.c | 8 +-
config.c | 1 +
designated_fsm.c | 36 ---
e2e_tc.c | 11 +++
fd.h | 1 +
p2p_tc.c | 11 +++
pmc_common.c | 9 +++---
port.c | 74 ++--
port.h | 19 +
port_private.h | 4 ++-
ptp4l.8 | 3 ++
11 files changed, 163 insertions(+), 14 deletions(-)
diff --git a/clock.c b/clock.c
index e545a9b..b5e24ad 100644
--- a/clock.c
+++ b/clock.c
@@ -1009,12 +1009,14 @@ struct clock *clock_create(enum clock_type type, struct
config *config,
interface_set_label(iface, ts_label);
interface_ensure_tslabel(iface);
interface_get_tsinfo(iface);
+#if 0
if (interface_tsinfo_valid(iface) &&
!interface_tsmodes_supported(iface, required_modes)) {
pr_err("interface '%s' does not support requested
timestamping mode",
interface_name(iface));
return NULL;
}
+#endif
}
iface = STAILQ_FIRST(>interfaces);
@@ -1250,7 +1252,11 @@ struct clock *clock_create(enum clock_type type, struct
config *config,
c->dds.numberPorts = c->nports;
LIST_FOREACH(p, >ports, list) {
- port_dispatch(p, EV_INITIALIZE, 0);
+ if (port_enable(p)) {
+ port_dispatch(p, EV_INITIALIZE, 0);
+ } else {
+ port_dispatch(p, EV_DESIGNATED_DISABLED, 0);
+ }
}
port_dispatch(c->uds_rw_port, EV_INITIALIZE, 0);
port_dispatch(c->uds_ro_port, EV_INITIALIZE, 0);
diff --git a/config.c b/config.c
index 4472d3d..b32e0a3 100644
--- a/config.c
+++ b/config.c
@@ -242,6 +242,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_INT("dscp_event", 0, 0, 63),
GLOB_ITEM_INT("dscp_general", 0, 0, 63),
GLOB_ITEM_INT("domainNumber", 0, 0, 127),
+ PORT_ITEM_INT("enable", 1, 0, 1),
PORT_ITEM_INT("egressLatency", 0, INT_MIN, INT_MAX),
PORT_ITEM_INT("fault_badpeernet_interval", 16, INT32_MIN, INT32_MAX),
PORT_ITEM_INT("fault_reset_interval", 4, INT8_MIN, INT8_MAX),
diff --git a/designated_fsm.c b/designated_fsm.c
index d19158b..c6bb692 100644
--- a/designated_fsm.c
+++ b/designated_fsm.c
@@ -44,16 +44,34 @@ enum port_state designated_master_fsm(enum port_state state,
break;
case PS_FAULTY:
- if (event == EV_FAULT_CLEARED) {
+ switch (event) {
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
+ case EV_FAULT_CLEARED:
next = PS_INITIALIZING;
+ break;
+ default:
+ break;
}
break;
+ case PS_DISABLED:
+ if (EV_DESIGNATED_ENABLED == event)
+ next = PS_INITIALIZING;
+ break;
+
case PS_MASTER:
- if (event == EV_FAULT_DETECTED) {
+ switch (event) {
+ case EV_FAULT_DETECTED:
next = PS_FAULTY;
+ break;
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
+ default:
+ break;
}
- break;
default:
break;
@@ -85,13 +103,23 @@ enum port_state designated_slave_fsm(enum port_state state,
break;
case PS_FAULTY:
- if (event == EV_FAULT_CLEARED) {
+ switch (event) {
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
+ case EV_FAULT_CLEARED:
next = PS_INITIALIZING;
+ break;
+ default:
+ break;
}
break;
case PS_SLAVE:
switch (event) {
+ case EV_DESIGNATED_DISABLED:
+ next = PS_DISABLED;
+ break;
case EV_FAULT_DETECTED:
next = PS_FAULTY;
break;
diff --git a/e2e_tc.c b/e2e_tc.c
index 2f8e821..dea482f 100644
--- a/e2e_tc.c
+++ b/e2e_tc.c
@@ -124,6 +124,8 @@ enum fsm_event e2e_event(struct port *p, int fd_index)
case FD_RTNL:
pr_debug("%s: received link status notification", p->log_name);
rtnl_link_status(fd, p->name, port_link_status, p);
+ if (!p->enable)
+ return EV_NONE;
if (p->link_status
[Linuxptp-devel] [PATCH 1/2] Add support for commands TLV
---
pmc_common.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/pmc_common.c b/pmc_common.c
index c5cd992..c7d8bed 100644
--- a/pmc_common.c
+++ b/pmc_common.c
@@ -57,6 +57,7 @@
static void do_get_action(struct pmc *pmc, int action, int index, char *str);
static void do_set_action(struct pmc *pmc, int action, int index, char *str);
+static void do_cmd_action(struct pmc *pmc, int action, int index, char *str);
static void not_supported(struct pmc *pmc, int action, int index, char *str);
static void null_management(struct pmc *pmc, int action, int index, char *str);
@@ -280,6 +281,31 @@ static void do_set_action(struct pmc *pmc, int action, int
index, char *str)
}
}
+static void do_cmd_action(struct pmc *pmc, int action, int index, char *str)
+{
+ int code = idtab[index].code;
+
+ switch (action) {
+ case COMMAND:
+ break;
+ case GET:
+ case SET:
+ case RESPONSE:
+ case ACKNOWLEDGE:
+ default:
+ fprintf(stderr, "%s only allows COMMAND\n",
+ idtab[index].name);
+ return;
+ }
+/*
+ switch (code) {
+ case TLV_:
+ pmc_send_cmd_action(pmc, code);
+ break;
+ }
+*/
+}
+
static void not_supported(struct pmc *pmc, int action, int index, char *str)
{
fprintf(stdout, "sorry, %s not supported yet\n", idtab[index].name);
@@ -622,6 +648,31 @@ int pmc_send_set_action(struct pmc *pmc, int id, void
*data, int datasize)
return 0;
}
+int pmc_send_cmd_action(struct pmc *pmc, int id)
+{
+ struct management_tlv *mgt;
+ struct ptp_message *msg;
+ struct tlv_extra *extra;
+
+ msg = pmc_message(pmc, COMMAND);
+ if (!msg) {
+ return -1;
+ }
+ extra = msg_tlv_append(msg, sizeof(*mgt));
+ if (!extra) {
+ msg_put(msg);
+ return -ENOMEM;
+ }
+ mgt = (struct management_tlv *) extra->tlv;
+ mgt->type = TLV_MANAGEMENT;
+ mgt->length = 2;
+ mgt->id = id;
+ pmc_send(pmc, msg);
+ msg_put(msg);
+
+ return 0;
+}
+
struct ptp_message *pmc_recv(struct pmc *pmc)
{
struct ptp_message *msg;
--
2.31.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 0/1] Add master only management TLV
Hi Jacob, You are right, architecture changes of a project that already rocks solid it's not easy. Furthermore I shared my wishes and my long term architectural view. I spent the last months trying to understand the code, and just now I'm proposing my (small) changes. ciao luigi Il giorno gio 22 apr 2021 alle ore 18:43 Jacob Keller < jacob.e.kel...@intel.com> ha scritto: > > > On 4/22/2021 8:46 AM, Luigi 'Comio' Mantellini wrote: > > Generally speaking and in my opinion should be interesting to have the > > following features: > > - asynchronous clock adjust: I2c is a slow bus with unpredictable > > access time, especially when you have a lot of devices. this is a true > > story. > > - a thread for each port that handles the ptp protocol and the > > timeouts: this will make more robust the stack on issues depending on TX > > timestamping. > > - a capability to use transport/interfaces different from linux > > interfaces, loading a custom .so file. i.e. timestamper send back the > > TS using in band communication. > > - ability to add/remove ports on the fly without traffic hit. > > - ability to change all port configurable parameters on the fly. > > > > My wishlist is from customer requirements, of course. > > > Most of these do sound like great features to have, but many would > require significant architecture changes. As LinuxPTP is an open source > project, you (or your customers) are free to work on such improvements > and contribute them back. > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 0/1] Add master only management TLV
Hi Richard, Hi Geva, I already tried "set MasteOnly" patch, except the slaveOnly missing check, and it seems to work. Generally speaking and in my opinion should be interesting to have the following features: - asynchronous clock adjust: I2c is a slow bus with unpredictable access time, especially when you have a lot of devices. this is a true story. - a thread for each port that handles the ptp protocol and the timeouts: this will make more robust the stack on issues depending on TX timestamping. - a capability to use transport/interfaces different from linux interfaces, loading a custom .so file. i.e. timestamper send back the TS using in band communication. - ability to add/remove ports on the fly without traffic hit. - ability to change all port configurable parameters on the fly. My wishlist is from customer requirements, of course. I think that for longtime development should consider these improvements. ciao luigi Il giorno gio 22 apr 2021 alle ore 17:00 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Thu, Apr 22, 2021 at 01:35:11PM +, Geva, Erez wrote: > > You need to verify the ptp4l can dynamically change the master only flag. > > +1 > > > As the 'slave only' flag does not allow set, I skip it for now. > > Right, and it wouldn't work if added naively. > > > Only priorities 1 and 2 can be changed at the moment. > > They do work dynamically. > > > However as the 'master only' is a port action and not clock action as > 'slave only', it might be easier to implement and verify. > > Right, many of the SET actions would require re-initializing the > stack, but this isn't trivial to implement. I tried adding more SET > actions some time ago, but I soon ran into corner cases in the code > that spoiled everything. It is one of the weaknesses of linuxptp. > > As practical matter, in my own projects I simply re-start the start > when the configuration changes. Although not ideal, that is easier > than re-working linuxptp to properly handle each dynamic variable. > > Sorry, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 0/1] Add master only management TLV
Why do you also introduce the set action?
This is a snip from port_management_set:
static int port_management_set(struct port *target,
struct port *ingress, int id,
struct ptp_message *req)
{
...
switch (id) {
case TLV_MASTERONLY:
mtd = (struct management_tlv_datum *) tlv->data;
master_only = !!mtd->val;
respond = 1;
if (!!target->master_only != master_only) {
if (target->bmca == BMCA_NOOP && target->transport != TRANS_UDS) {
if (master_only) {
target->state_machine = designated_master_fsm;
} else if (clock_slave_only(target->clock)) {
target->state_machine = designated_slave_fsm;
} else {
pr_err("Please enable at least one of masterOnly
or slaveOnly when BMCA == noop.\n");
respond = 0;
}
} else {
target->state_machine =
clock_slave_only(target->clock) ? ptp_slave_fsm : ptp_fsm;
}
if (respond) {
target->master_only = master_only;
port_dispatch(target, EV_INITIALIZE, 0);
}
}
break;
...
}
ciao
luigi
Il giorno gio 22 apr 2021 alle ore 15:06 Erez Geva
ha scritto:
>
> As we support the new master only flag.
> Add the master only TLV to pmc tool.
>
> Erez Geva (1):
> Add master only management TLV
>
> pmc.c| 5 +
> pmc_common.c | 2 ++
> port.c | 6 ++
> tlv.h| 1 +
> 4 files changed, 14 insertions(+)
>
> --
> 2.20.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
--
Luigi 'Comio' Mantellini
My Professional Profile
"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] pmc is not giving any output without using -d option
[edited] pmc uses the domainNumber = 0 as default and you needn't "-d 0". If you omit the option, the default will be used instead. To use a different domainNumber you have two options: 1) use -d XX 2) specify domainNumber into a configuration file in [global] section. You can use the ptp4l configuration file. pmc.conf: [global] ... domainNumber 44 # pmc -u -f pmc.conf "GET DOMAIN" ciao luigi ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] pmc is not giving any output without using -d option
pmc use as default the domainNumber = 0, and you needn't "-d 0". If you omit the option, the default will be used istead. To use a different domainNumber you have two options: use -d XX or specify domainNumber into a configuration file. pmc.conf: [global] ... domainNumber 44 # mpc -u -f pmc.conf "GET DOMAIN" cheers. luigi Il giorno gio 22 apr 2021 alle ore 13:44 Ruby Bhati ha scritto: > Hi > > I am running ptp4l with G.8275.2 profile. > But when i am running pmc without -d option its not showing any output > ]# pmc -u -d 0 'GET DOMAIN' > sending: GET DOMAIN > > Its working only when I am running with -d option as > # pmc -u -d 0 -d 44 'GET DOMAIN' > sending: GET DOMAIN > a0369f.fffe.874100-0 seq 0 RESPONSE MANAGEMENT DOMAIN > domainNumber 44 > > I want to run pmc without -d option. Is there any way to run without > giving -d option? > > Thanks, > Ruby Bhati > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH v4] Rework twoStepFlag in order to handle one step on port basis.
With this patch we introduce the twoStepFlag evaluation at port level.
---
config.c | 2 +-
port.c | 35 ++-
ptp4l.8 | 9 -
3 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/config.c b/config.c
index 4472d3d..f0e1e07 100644
--- a/config.c
+++ b/config.c
@@ -322,7 +322,7 @@ struct config_item config_tab[] = {
PORT_ITEM_INT("ts2phc.pin_index", 0, 0, INT_MAX),
GLOB_ITEM_INT("ts2phc.pulsewidth", 5, 100, 99900),
PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu),
- GLOB_ITEM_INT("twoStepFlag", 1, 0, 1),
+ PORT_ITEM_INT("twoStepFlag", 1, 0, 1),
GLOB_ITEM_INT("tx_timestamp_timeout", 1, 1, INT_MAX),
PORT_ITEM_INT("udp_ttl", 1, 1, 255),
PORT_ITEM_INT("udp6_scope", 0x0E, 0x00, 0x0F),
diff --git a/port.c b/port.c
index 10bb9e1..b700ff3 100644
--- a/port.c
+++ b/port.c
@@ -3028,6 +3028,37 @@ err:
msg_put(msg);
}
+static enum timestamp_type port_harmonize_onestep(struct port *p, enum
timestamp_type timestamping, int twoStepFlag)
+{
+ switch (timestamping) {
+ case TS_SOFTWARE:
+ case TS_LEGACY_HW:
+ if (!twoStepFlag) {
+ pr_err("%s: one step is only possible "
+ "with hardware time stamping", p->log_name);
+ return timestamping;
+ }
+ break;
+ case TS_HARDWARE:
+ if (!twoStepFlag) {
+ pr_debug("%s: upgrading to one step time stamping "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_ONESTEP;
+ }
+ break;
+ case TS_ONESTEP:
+ case TS_P2P1STEP:
+ if (twoStepFlag) {
+ pr_debug("%s: degrading to two step time stamping, "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_HARDWARE;
+ }
+ break;
+ }
+
+ return timestamping;
+}
+
struct port *port_open(const char *phc_device,
int phc_index,
enum timestamp_type timestamping,
@@ -3039,6 +3070,7 @@ struct port *port_open(const char *phc_device,
struct config *cfg = clock_config(clock);
struct port *p = malloc(sizeof(*p));
int i;
+ int twoStepFlag;
if (!p) {
return NULL;
@@ -3134,7 +3166,8 @@ struct port *port_open(const char *phc_device,
p->tx_timestamp_offset <<= 16;
p->link_status = LINK_UP;
p->clock = clock;
- p->timestamping = timestamping;
+ twoStepFlag = config_get_int(cfg, p->name, "twoStepFlag");
+ p->timestamping = port_harmonize_onestep(p, timestamping, twoStepFlag);
p->portIdentity.clockIdentity = clock_identity(clock);
p->portIdentity.portNumber = number;
p->state = PS_INITIALIZING;
diff --git a/ptp4l.8 b/ptp4l.8
index fe9e150..bea4dae 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -143,6 +143,10 @@ See UNICAST DISCOVERY OPTIONS, below.
.SH PORT OPTIONS
.TP
+.B twoStepFlag
+Enable two-step mode for sync messages. One-step mode can be used only with
+hardware time stamping.
+The default is 1 (enabled).
.B delayAsymmetry
The time difference in nanoseconds of the transmit and receive
paths. This value should be positive when the server-to-client
@@ -378,11 +382,6 @@ to the same subnet.
.SH PROGRAM AND CLOCK OPTIONS
-.TP
-.B twoStepFlag
-Enable two-step mode for sync messages. One-step mode can be used only with
-hardware time stamping.
-The default is 1 (enabled).
.TP
.B clientOnly
The local clock is a client-only clock if enabled. The default is 0 (disabled).
--
2.31.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH v3] RFC: Rework twoStepFlag in order to handle one step on port basis.
---
config.c | 2 +-
port.c | 40 +++-
ptp4l.8 | 9 -
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/config.c b/config.c
index 4472d3d..f0e1e07 100644
--- a/config.c
+++ b/config.c
@@ -322,7 +322,7 @@ struct config_item config_tab[] = {
PORT_ITEM_INT("ts2phc.pin_index", 0, 0, INT_MAX),
GLOB_ITEM_INT("ts2phc.pulsewidth", 5, 100, 99900),
PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu),
- GLOB_ITEM_INT("twoStepFlag", 1, 0, 1),
+ PORT_ITEM_INT("twoStepFlag", 1, 0, 1),
GLOB_ITEM_INT("tx_timestamp_timeout", 1, 1, INT_MAX),
PORT_ITEM_INT("udp_ttl", 1, 1, 255),
PORT_ITEM_INT("udp6_scope", 0x0E, 0x00, 0x0F),
diff --git a/port.c b/port.c
index 10bb9e1..1d7059d 100644
--- a/port.c
+++ b/port.c
@@ -3028,6 +3028,42 @@ err:
msg_put(msg);
}
+static enum timestamp_type port_harmonize_onestep(struct port *p, enum
timestamp_type timestamping, int twoStepFlag)
+{
+ if (twoStepFlag < 0) {
+ // As global
+ return timestamping;
+ }
+
+ switch (timestamping) {
+ case TS_SOFTWARE:
+ case TS_LEGACY_HW:
+ if (!twoStepFlag) {
+ pr_err("%s: one step is only possible "
+ "with hardware time stamping", p->log_name);
+ return timestamping;
+ }
+ break;
+ case TS_HARDWARE:
+ if (!twoStepFlag) {
+ pr_debug("%s: upgrading to one step time stamping "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_ONESTEP;
+ }
+ break;
+ case TS_ONESTEP:
+ case TS_P2P1STEP:
+ if (twoStepFlag) {
+ pr_debug("%s: degrading to two step time stamping, "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_HARDWARE;
+ }
+ break;
+ }
+
+ return timestamping;
+}
+
struct port *port_open(const char *phc_device,
int phc_index,
enum timestamp_type timestamping,
@@ -3039,6 +3075,7 @@ struct port *port_open(const char *phc_device,
struct config *cfg = clock_config(clock);
struct port *p = malloc(sizeof(*p));
int i;
+ int twoStepFlag;
if (!p) {
return NULL;
@@ -3134,7 +3171,8 @@ struct port *port_open(const char *phc_device,
p->tx_timestamp_offset <<= 16;
p->link_status = LINK_UP;
p->clock = clock;
- p->timestamping = timestamping;
+ twoStepFlag = config_get_int(cfg, p->name, "twoStepFlag");
+ p->timestamping = port_harmonize_onestep(p, timestamping, twoStepFlag);
p->portIdentity.clockIdentity = clock_identity(clock);
p->portIdentity.portNumber = number;
p->state = PS_INITIALIZING;
diff --git a/ptp4l.8 b/ptp4l.8
index fe9e150..bea4dae 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -143,6 +143,10 @@ See UNICAST DISCOVERY OPTIONS, below.
.SH PORT OPTIONS
.TP
+.B twoStepFlag
+Enable two-step mode for sync messages. One-step mode can be used only with
+hardware time stamping.
+The default is 1 (enabled).
.B delayAsymmetry
The time difference in nanoseconds of the transmit and receive
paths. This value should be positive when the server-to-client
@@ -378,11 +382,6 @@ to the same subnet.
.SH PROGRAM AND CLOCK OPTIONS
-.TP
-.B twoStepFlag
-Enable two-step mode for sync messages. One-step mode can be used only with
-hardware time stamping.
-The default is 1 (enabled).
.TP
.B clientOnly
The local clock is a client-only clock if enabled. The default is 0 (disabled).
--
2.31.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH v2] RFC: Rework twoStepFlag in order to handle one step on port basis.
---
config.c | 2 +-
port.c | 40 +++-
ptp4l.8 | 9 -
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/config.c b/config.c
index 4472d3d..f0e1e07 100644
--- a/config.c
+++ b/config.c
@@ -322,7 +322,7 @@ struct config_item config_tab[] = {
PORT_ITEM_INT("ts2phc.pin_index", 0, 0, INT_MAX),
GLOB_ITEM_INT("ts2phc.pulsewidth", 5, 100, 99900),
PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu),
- GLOB_ITEM_INT("twoStepFlag", 1, 0, 1),
+ PORT_ITEM_INT("twoStepFlag", 1, 0, 1),
GLOB_ITEM_INT("tx_timestamp_timeout", 1, 1, INT_MAX),
PORT_ITEM_INT("udp_ttl", 1, 1, 255),
PORT_ITEM_INT("udp6_scope", 0x0E, 0x00, 0x0F),
diff --git a/port.c b/port.c
index 10bb9e1..1d7059d 100644
--- a/port.c
+++ b/port.c
@@ -3028,6 +3028,42 @@ err:
msg_put(msg);
}
+static enum timestamp_type port_harmonize_onestep(struct port *p, enum
timestamp_type timestamping, int twoStepFlag)
+{
+ if (twoStepFlag < 0) {
+ // As global
+ return timestamping;
+ }
+
+ switch (timestamping) {
+ case TS_SOFTWARE:
+ case TS_LEGACY_HW:
+ if (!twoStepFlag) {
+ pr_err("%s: one step is only possible "
+ "with hardware time stamping", p->log_name);
+ return timestamping;
+ }
+ break;
+ case TS_HARDWARE:
+ if (!twoStepFlag) {
+ pr_debug("%s: upgrading to one step time stamping "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_ONESTEP;
+ }
+ break;
+ case TS_ONESTEP:
+ case TS_P2P1STEP:
+ if (twoStepFlag) {
+ pr_debug("%s: degrading to two step time stamping, "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_HARDWARE;
+ }
+ break;
+ }
+
+ return timestamping;
+}
+
struct port *port_open(const char *phc_device,
int phc_index,
enum timestamp_type timestamping,
@@ -3039,6 +3075,7 @@ struct port *port_open(const char *phc_device,
struct config *cfg = clock_config(clock);
struct port *p = malloc(sizeof(*p));
int i;
+ int twoStepFlag;
if (!p) {
return NULL;
@@ -3134,7 +3171,8 @@ struct port *port_open(const char *phc_device,
p->tx_timestamp_offset <<= 16;
p->link_status = LINK_UP;
p->clock = clock;
- p->timestamping = timestamping;
+ twoStepFlag = config_get_int(cfg, p->name, "twoStepFlag");
+ p->timestamping = port_harmonize_onestep(p, timestamping, twoStepFlag);
p->portIdentity.clockIdentity = clock_identity(clock);
p->portIdentity.portNumber = number;
p->state = PS_INITIALIZING;
diff --git a/ptp4l.8 b/ptp4l.8
index fe9e150..bea4dae 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -143,6 +143,10 @@ See UNICAST DISCOVERY OPTIONS, below.
.SH PORT OPTIONS
.TP
+.B twoStepFlag
+Enable two-step mode for sync messages. One-step mode can be used only with
+hardware time stamping.
+The default is 1 (enabled).
.B delayAsymmetry
The time difference in nanoseconds of the transmit and receive
paths. This value should be positive when the server-to-client
@@ -378,11 +382,6 @@ to the same subnet.
.SH PROGRAM AND CLOCK OPTIONS
-.TP
-.B twoStepFlag
-Enable two-step mode for sync messages. One-step mode can be used only with
-hardware time stamping.
-The default is 1 (enabled).
.TP
.B clientOnly
The local clock is a client-only clock if enabled. The default is 0 (disabled).
--
2.31.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Propagate management messages from UNIX layer to PTP network
You should specify 0 (ZERO) boundary hops: pmc -b 0 -u -f /blabla/ptp4l.conf "GET CURRENT_DATA_SET" caio luigi Il giorno mer 21 apr 2021 alle ore 17:37 Geva, Erez < erez.geva@siemens.com> ha scritto: > Hi, > > > > We notice that when sending Management messages using UNIX socket (‘pmc > -u’). > > ptp4l propagate the message to the PTP domain network. > > > > We try to set the target using local clock ID. > > # pmc -u -f /etc/linuxptp/ptp4l.conf 'target xx.fffe.xx-1' 'get > CLOCK_DESCRIPTION' > > > > Now, we get reply to the lock clock only. > > But yet we see a GET request message on the PTP domain network. > > Why does the ptp4l propagate the message? > > > > Same with CURRENT_DATA_SET. > > Management IDs for PTP port or PTP instance (clock) seems to behave the > same in this respect. > > > > > > With best regards, > Erez Geva > > AURELLY TECHNOLOGIES GmbH > External service provider at Siemens AG > Digital Industries > Process Automation > Software House Nbg > DI PA DCP R 3 > Gleiwitzer Str. 555 > 90475 Nuremberg, Germany > mailto:erez.geva@siemens.com > > > www.aurelly.com > CEO: Jens Stötzner, company's place of business: Nürnberg, > VAT identification: DE 255071685, Commercial register No.: HRB: 15550 > Please consider the environment before printing this email > Important notice: This e-mail and any attachment thereof contain corporate > proprietary information. If you have received it by mistake, please notify > us immediately by reply e-mail and delete this e-mail and its attachments > from your system. Thank you. > > > _______ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] [RFC] Add CMake support
Hi Michael, Hi All, My environment is already cmake based and I preferred to handle via cmake. The most important part is into check_features.cmake, where I check the kernel features using small pieces of code instead of "grep" on sources. I marked it as "RFC" because this patch doesn't add anything and doesn't resolve any bugs. It is just a product of my work that I prefer to share with all. luigi Il giorno mer 21 apr 2021 alle ore 15:41 Michael Walle ha scritto: > Hi Luigi, > > there is no reasoning, why you need cmake in this RFC, just the > diffs. Therefore, what is the additional value here compared to > standard make. > > -michael > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH] [RFC] Add CMake support
---
CMakeLists.txt| 189 ++
CMakeModules/CompilerFlags.cmake | 25
CMakeModules/check_features.cmake | 96 +++
CMakeModules/version.cmake| 39 ++
version.c | 4 +
5 files changed, 353 insertions(+)
create mode 100644 CMakeLists.txt
create mode 100644 CMakeModules/CompilerFlags.cmake
create mode 100644 CMakeModules/check_features.cmake
create mode 100644 CMakeModules/version.cmake
diff --git a/CMakeLists.txt b/CMakeLists.txt
new file mode 100644
index 000..f05b1e6
--- /dev/null
+++ b/CMakeLists.txt
@@ -0,0 +1,189 @@
+#
+# Copyright (C) 2021 Luigi Mantellini
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+
+cmake_minimum_required(VERSION 3.10)
+
+project(linuxptp)
+
+set(CMAKE_INCLUDE_CURRENT_DIR ON)
+set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
"${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/")
+
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/bin")
+
+include(GNUInstallDirs)
+include(CompilerFlags)
+include(check_features)
+
+set(FILTERS_SRC filter.c mave.c mmedian.c)
+set(SERVOS_SRC linreg.c ntpshm.c nullf.c pi.c servo.c)
+set(TRANSP_SRC raw.c transport.c udp.c udp6.c uds.c)
+
+set(PTP4L_SRC bmc.c clock.c clockadj.c clockcheck.c config.c designated_fsm.c
+ e2e_tc.c fault.c fsm.c hash.c interface.c monitor.c msg.c phc.c
+ port.c port_signaling.c pqueue.c print.c ptp4l.c p2p_tc.c rtnl.c
+ sk.c stats.c tc.c telecom.c tlv.c tsproc.c unicast_client.c
+ unicast_fsm.c unicast_service.c util.c version.c)
+
+set(NSM_SRC config.c hash.c interface.c msg.c nsm.c phc.c print.c
+rtnl.c sk.c tlv.c tsproc.c util.c version.c)
+
+set(PMC_SRC config.c hash.c interface.c msg.c phc.c pmc.c pmc_common.c print.c
sk.c
+tlv.c util.c version.c)
+
+set(PHC2SYS_SRC clockadj.c clockcheck.c config.c hash.c interface.c msg.c
+phc.c phc2sys.c pmc_agent.c pmc_common.c print.c sk.c stats.c
+sysoff.c tlv.c util.c version.c)
+
+set(HWSTAMP_CTL_SRC hwstamp_ctl.c version.c)
+
+set(PHC_CTL_SRC phc_ctl.c phc.c sk.c util.c clockadj.c sysoff.c print.c
version.c)
+
+set(TIMEMASTER_SRC phc.c print.c rtnl.c sk.c timemaster.c util.c version.c)
+
+set(TS2PHC_SRC config.c clockadj.c hash.c interface.c phc.c print.c sk.c
+ ts2phc.c lstab.c nmea.c serial.c sock.c ts2phc_generic_master.c
+ ts2phc_master.c ts2phc_phc_master.c ts2phc_nmea_master.c
ts2phc_slave.c util.c
+ version.c)
+
+# Generate .version file
+add_custom_command(
+OUTPUT always_rebuild
+COMMAND true
+COMMENT "")
+add_custom_command(
+OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/.version.h"
+BYPRODUCTS "${CMAKE_CURRENT_BINARY_DIR}/.version.h"
+COMMAND ${CMAKE_COMMAND} -P
${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/version.cmake
+COMMENT "Generate .version.h"
+DEPENDS
+always_rebuild)
+add_custom_target(version
+ALL
+DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/.version.h")
+
+add_library(filters STATIC ${FILTERS_SRC})
+add_library(servos STATIC ${SERVOS_SRC})
+add_library(transp STATIC ${TRANSP_SRC})
+
+add_executable(ptp4l
+${PTP4L_SRC})
+add_dependencies(ptp4l
+version
+filters
+servos
+transp)
+target_include_directories(ptp4l
+PUBLIC
+-I${CMAKE_CURRENT_SOURCE_DIR})
+target_link_libraries(ptp4l
+PRIVATE
+filters
+servos
+transp
+${LIB_M})
+
+add_executable(nsm
+${NSM_SRC})
+add_dependencies(nsm
+version
+filters
+transp)
+target_include_directories(nsm
+PUBLIC
+-I${CMAKE_CURRENT_SOURCE_DIR})
+target_link_libraries(nsm
+PRIVATE
+filters
+transp)
+
+add_executable(pmc
+${PMC_SRC})
+add_dependencies(pmc
+version
+transp)
+target_include_directories(pmc
+PUBLIC
+-I${CMAKE_CURRENT_SOURCE_DIR})
+target_link_libraries(pmc
+PRIVATE
+transp)
+
+add_executable(phc2sys
+${PHC2SYS_SRC})
+add_dependencies(phc2sys
+version
+transp)
+target_include_directories(phc2sys
+PUBLIC
+-I${CMAKE_CURRENT_SOURCE_DIR})
+target_link_libraries(phc2sys
+PRIVATE
+servos
+transp
+${LIB_M})
+
+add_executable(hwstamp_ctl
+${HWSTAMP_CTL_SRC})
+add_dependencies(hwstamp_ctl
+version)
[Linuxptp-devel] [PATCH] RFC: add port.twoStepFlag option in order to handle one step on port basis.
port.twoStepFlag.
When -1, inherit the global twoStepFlag value, otherwise enable two-step mode
for sync messages on port basis. One-step mode can be used only with hardware
time stamping. The default is -1 (as global twoStepFlag value).
---
config.c | 1 +
port.c | 40 +++-
ptp4l.8 | 4
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 4472d3d..13dcea8 100644
--- a/config.c
+++ b/config.c
@@ -291,6 +291,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_DBL("pi_proportional_exponent", -0.3, -DBL_MAX, DBL_MAX),
GLOB_ITEM_DBL("pi_proportional_norm_max", 0.7, DBL_MIN, 1.0),
GLOB_ITEM_DBL("pi_proportional_scale", 0.0, 0.0, DBL_MAX),
+ PORT_ITEM_INT("port.twoStepFlag", -1, -1, 1),
GLOB_ITEM_INT("priority1", 128, 0, UINT8_MAX),
GLOB_ITEM_INT("priority2", 128, 0, UINT8_MAX),
GLOB_ITEM_STR("productDescription", ";;"),
diff --git a/port.c b/port.c
index 10bb9e1..95ce77a 100644
--- a/port.c
+++ b/port.c
@@ -3028,6 +3028,42 @@ err:
msg_put(msg);
}
+static enum timestamp_type port_harmonize_onestep(struct port *p, enum
timestamp_type timestamping, int portTwoStepFlag)
+{
+ if (portTwoStepFlag < 0) {
+ // As global
+ return timestamping;
+ }
+
+ switch (timestamping) {
+ case TS_SOFTWARE:
+ case TS_LEGACY_HW:
+ if (!portTwoStepFlag) {
+ pr_err("%s: one step is only possible "
+ "with hardware time stamping", p->log_name);
+ return timestamping;
+ }
+ break;
+ case TS_HARDWARE:
+ if (!portTwoStepFlag) {
+ pr_debug("%s: upgrading to one step time stamping "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_ONESTEP;
+ }
+ break;
+ case TS_ONESTEP:
+ case TS_P2P1STEP:
+ if (portTwoStepFlag) {
+ pr_debug("%s: degrading to two step time stamping, "
+"in order to match the port.twoStepFlag",
p->log_name);
+ return TS_HARDWARE;
+ }
+ break;
+ }
+
+ return timestamping;
+}
+
struct port *port_open(const char *phc_device,
int phc_index,
enum timestamp_type timestamping,
@@ -3039,6 +3075,7 @@ struct port *port_open(const char *phc_device,
struct config *cfg = clock_config(clock);
struct port *p = malloc(sizeof(*p));
int i;
+ int portTwoStepFlag;
if (!p) {
return NULL;
@@ -3134,7 +3171,8 @@ struct port *port_open(const char *phc_device,
p->tx_timestamp_offset <<= 16;
p->link_status = LINK_UP;
p->clock = clock;
- p->timestamping = timestamping;
+ portTwoStepFlag = config_get_int(cfg, p->name, "port.twoStepFlag");
+ p->timestamping = port_harmonize_onestep(p, timestamping,
portTwoStepFlag);
p->portIdentity.clockIdentity = clock_identity(clock);
p->portIdentity.portNumber = number;
p->state = PS_INITIALIZING;
diff --git a/ptp4l.8 b/ptp4l.8
index fe9e150..65edf54 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -143,6 +143,10 @@ See UNICAST DISCOVERY OPTIONS, below.
.SH PORT OPTIONS
.TP
+.B port.twoStepFlag
+When -1, inherit the global twoStepFlag value, otherwise enable two-step mode
+for sync messages on port basis. One-step mode can be used only with hardware
+time stamping. The default is -1 (as global twoStepFlag value).
.B delayAsymmetry
The time difference in nanoseconds of the transmit and receive
paths. This value should be positive when the server-to-client
--
2.31.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH] Handle step_window at port level.
From: Luigi Mantellini
The step_window functionality should be defined at the port level because
we cannot assume that different ports have the same sync message rate.
---
clock.c| 13 +
clock.h| 5 +++--
config.c | 2 +-
port.c | 18 +-
port.h | 7 +++
port_private.h | 1 +
6 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/clock.c b/clock.c
index e545a9b..6072ea0 100644
--- a/clock.c
+++ b/clock.c
@@ -710,6 +710,9 @@ static void clock_update_slave(struct clock *c)
pr_info("updating UTC offset to %d", c->tds.currentUtcOffset);
c->utc_offset = c->tds.currentUtcOffset;
}
+
+ // Port changed
+ c->step_window_counter = 0;
}
static int clock_utc_correct(struct clock *c, tmv_t ingress)
@@ -1103,7 +1106,8 @@ struct clock *clock_create(enum clock_type type, struct
config *config,
c->kernel_leap = config_get_int(config, NULL, "kernel_leap");
c->utc_offset = config_get_int(config, NULL, "utc_offset");
c->time_source = config_get_int(config, NULL, "timeSource");
- c->step_window = config_get_int(config, NULL, "step_window");
+ c->step_window = 0;
+ c->step_window_counter = 0;
if (c->free_running) {
c->clkid = CLOCK_INVALID;
@@ -1764,8 +1768,9 @@ int clock_switch_phc(struct clock *c, int phc_index)
return 0;
}
-static void clock_step_window(struct clock *c)
+static void clock_step_window(struct clock *c, struct port *p)
{
+ c->step_window = port_step_window(p);
if (!c->step_window) {
return;
}
@@ -1783,7 +1788,7 @@ static void clock_synchronize_locked(struct clock *c,
double adj)
}
}
-enum servo_state clock_synchronize(struct clock *c, tmv_t ingress, tmv_t
origin)
+enum servo_state clock_synchronize(struct clock *c, struct port *p, tmv_t
ingress, tmv_t origin)
{
enum servo_state state = SERVO_UNLOCKED;
double adj, weight;
@@ -1841,7 +1846,7 @@ enum servo_state clock_synchronize(struct clock *c, tmv_t
ingress, tmv_t origin)
-tmv_to_nanoseconds(c->master_offset));
}
tsproc_reset(c->tsproc, 0);
- clock_step_window(c);
+ clock_step_window(c, p);
break;
case SERVO_LOCKED:
clock_synchronize_locked(c, adj);
diff --git a/clock.h b/clock.h
index 845d54f..0a3b09d 100644
--- a/clock.h
+++ b/clock.h
@@ -314,6 +314,7 @@ int clock_switch_phc(struct clock *c, int phc_index);
/**
* Provide a data point to synchronize the clock.
* @param cThe clock instance to synchronize.
+ * @param pThe port on which the message arrived.
* @param ingress The ingress time stamp on the sync message.
* @param origin The reported transmission time of the sync message,
including any corrections.
@@ -322,8 +323,8 @@ int clock_switch_phc(struct clock *c, int phc_index);
* Pass zero in the case of one step operation.
* @return The state of the clock's servo.
*/
-enum servo_state clock_synchronize(struct clock *c, tmv_t ingress,
- tmv_t origin);
+enum servo_state clock_synchronize(struct clock *c, struct port *p,
+ tmv_t ingress, tmv_t origin);
/**
* Inform a slaved clock about the master's sync interval.
diff --git a/config.c b/config.c
index 4472d3d..4e964d1 100644
--- a/config.c
+++ b/config.c
@@ -305,7 +305,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_INT("slaveOnly", 0, 0, 1), /*deprecated*/
GLOB_ITEM_INT("socket_priority", 0, 0, 15),
GLOB_ITEM_DBL("step_threshold", 0.0, 0.0, DBL_MAX),
- GLOB_ITEM_INT("step_window", 0, 0, INT_MAX),
+ PORT_ITEM_INT("step_window", 0, 0, INT_MAX),
GLOB_ITEM_INT("summary_interval", 0, INT_MIN, INT_MAX),
PORT_ITEM_INT("syncReceiptTimeout", 0, 0, UINT8_MAX),
GLOB_ITEM_INT("tc_spanning_tree", 0, 0, 1),
diff --git a/port.c b/port.c
index 10bb9e1..d1ead80 100644
--- a/port.c
+++ b/port.c
@@ -189,6 +189,21 @@ int port_fault_fd(struct port *port)
return port->fault_fd;
}
+int port_step_window(struct port *p)
+{
+ int step_window;
+
+ if ((p->initialLogSyncInterval - p->log_sync_interval) > 0)
+ step_window = (p->step_window << (p->initialLogSyncInterval -
p->log_sync_interval));
+ else
+ step_window = (p->step_window >> (p->log_sync_interval -
p->initialLogSyncInterval));
+
+ if (!step_window && p->step_window)
+ step_window = 1;
+
+ return step_window;
+}
+
struct fdarray *port_fda(struct port *port)
{
return >fda;
@@ -1194,7 +1209,7 @@ static void port_synchronize(struct port *p,
}
last_state = clock_servo_state(p->clock);
- state =
Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition
Yes, it works for me. thanks luigi Il giorno mar 23 mar 2021 alle ore 15:06 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Mon, Mar 15, 2021 at 12:38:58PM +0100, Luigi 'Comio' Mantellini wrote: > > Inside port_synchronize() I noticed this: > > > > case SERVO_LOCKED: > > port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0); > > break; > > case SERVO_LOCKED_STABLE: > > message_interval_request(p, last_state, sync_interval); > > break; > > > > Supposing to have the port X as SLAVE with "SERVO_LOCKED_STABLE" state, > > after a while I disable the ingoing traffic (SYNC/ANNUNCE) to the port X, > > switching to another port Y still keeping the SERVO_LOCKED_STABLE > > condition. The check_offset_threshold(), called by sample_sample(), > should > > always return "1' (true) because the s->curr_offset_values == 0 (and it > is > > fixed to servo_num_offset_values only in SERV_UNLOCKED and SERVO_JUMP > > conditions). > > > > In these conditions the SERVO_LOCKED will not happen and the > > port_dispatach(p, EV_MASTER_CLOCK_SELECTED, 0) should never be called, > > resulting in a forever "UNCALIBRATED" condition. > > Does changing port_synchronize() to this fix the issue for you? > > case SERVO_LOCKED_STABLE: > message_interval_request(p, last_state, sync_interval); > + port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0); > break; > > Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition
continuing: In your opinion, can a servo->curr_offset_values = servo->num_offset_values call inside clock_udpdate_slave() help? ciao luigi Il giorno lun 15 mar 2021 alle ore 12:38 Luigi 'Comio' Mantellini ha scritto: > > Hi Richard, > > sorry again to continue this thread. > > Inside port_synchronize() I noticed this: > > case SERVO_LOCKED: > port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0); > break; > case SERVO_LOCKED_STABLE: > message_interval_request(p, last_state, sync_interval); > break; > > Supposing to have the port X as SLAVE with "SERVO_LOCKED_STABLE" state, after > a while I disable the ingoing traffic (SYNC/ANNUNCE) to the port X, switching > to another port Y still keeping the SERVO_LOCKED_STABLE condition. The > check_offset_threshold(), called by sample_sample(), should always return "1' > (true) because the s->curr_offset_values == 0 (and it is fixed to > servo_num_offset_values only in SERV_UNLOCKED and SERVO_JUMP conditions). > > In these conditions the SERVO_LOCKED will not happen and the > port_dispatach(p, EV_MASTER_CLOCK_SELECTED, 0) should never be called, > resulting in a forever "UNCALIBRATED" condition. > > Are my deductions right? > > Thanks again for your support, > > luigi > > > [global] > ... > servo_offset_threshold 100 > servo_num_offset_values 64 > ... > > Il giorno dom 14 mar 2021 alle ore 19:37 Luigi 'Comio' Mantellini > ha scritto: >> >> >> >> Il giorno dom 14 mar 2021 alle ore 16:58 Richard Cochran >> ha scritto: >>> >>> On Sun, Mar 14, 2021 at 10:30:31AM +0100, Luigi 'Comio' Mantellini wrote: >>> > The failures are part of the test and after the HW restoring I'm pretty >>> > sure that the protocol waltzer is running fine. I noticed that the ptp4l >>> > shows master offset and delay summaries. In order to have offset and delay >>> > values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I >>> > right? >>> >>> Right. >>> >> >>> >>> > Another observation is that Killing and restarting again the ptp4l I reach >>> > the SLAVE state without servo jump. >>> >>> Probably because the offset is below the threshold. >>> >> I knew, I remarked this only to say that the clock was attached. >> >>> > Just now I placed the servo_reset() inside handle_state_decision_event() >>> > when we have a fresh new best master, after the clock_freq_est_reset() >>> > method. >>> >>> Don't do that. That spoils your synchronization for nothing. >>> >> I will better investigate. >> >> Thanks again >> >> luigi >> >>> Thanks, >>> Richard >> >> >> >> -- >> Luigi 'Comio' Mantellini >> My Professional Profile >> >> "UNIX is very simple, it just needs a genius to understand its simplicity." >> [cit.] >> > > > -- > Luigi 'Comio' Mantellini > My Professional Profile > > "UNIX is very simple, it just needs a genius to understand its simplicity." > [cit.] > -- Luigi 'Comio' Mantellini My Professional Profile "UNIX is very simple, it just needs a genius to understand its simplicity." [cit.] ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition
Il giorno dom 14 mar 2021 alle ore 16:58 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Sun, Mar 14, 2021 at 10:30:31AM +0100, Luigi 'Comio' Mantellini wrote: > > The failures are part of the test and after the HW restoring I'm pretty > > sure that the protocol waltzer is running fine. I noticed that the ptp4l > > shows master offset and delay summaries. In order to have offset and > delay > > values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I > > right? > > Right. > > > > Another observation is that Killing and restarting again the ptp4l I > reach > > the SLAVE state without servo jump. > > Probably because the offset is below the threshold. > > I knew, I remarked this only to say that the clock was attached. > Just now I placed the servo_reset() inside handle_state_decision_event() > > when we have a fresh new best master, after the clock_freq_est_reset() > > method. > > Don't do that. That spoils your synchronization for nothing. > > I will better investigate. Thanks again luigi Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition
HI Richard, thanks for your answer. The failures are part of the test and after the HW restoring I'm pretty sure that the protocol waltzer is running fine. I noticed that the ptp4l shows master offset and delay summaries. In order to have offset and delay values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I right? Another observation is that Killing and restarting again the ptp4l I reach the SLAVE state without servo jump. Just now I placed the servo_reset() inside handle_state_decision_event() when we have a fresh new best master, after the clock_freq_est_reset() method. Thanks for your help, luigi luigi Il giorno ven 12 mar 2021 alle ore 20:04 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Fri, Mar 12, 2021 at 10:03:39AM +0100, luigi.mantell...@gmail.com > wrote: > > > The issue that I'm facing is the following: > > - After a fault, the port lost the SLAVE role (correct) passing to > > MASTER state (cortect) > > - After this transition, and after restoring the working condition I'm > > unable to move from UNCALIBRATED state to SLAVE state. > > The main reason for getting stuck in UNCALIBRATED is that the port is > not able to complete a delay request/response exchange. > > > My suspect is a wrong servo condition and my idea is to add a > > servo_reset() into clock_update_slave() function. > > > > Is it a good idea or a comlete non-sense? > > That doesn't make any sense to me. You need to find the root cause > and fix it. > > HTH, > Richard > > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
Correct. This is good observation. The 2.1 is backward compatible and I don't see any other issue. BTW I will give a check to the standard and I will ask to standard experts in my company. Luigi Il dom 21 feb 2021, 20:18 Richard Cochran ha scritto: > On Sun, Feb 21, 2021 at 08:10:48PM +0100, Luigi 'Comio' Mantellini wrote: > > The only use case that I can suppose is an old device into the network > that > > doesn't handle the new protocol version and we need to accommodate. For > > this reason I was asking to handle at port level. > > But older devices cannot reject frames with minor version .1 because > that field did not exist in version v2.0, right? > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
The only use case that I can suppose is an old device into the network that doesn't handle the new protocol version and we need to accommodate. For this reason I was asking to handle at port level. Luigi Il dom 21 feb 2021, 19:56 Richard Cochran ha scritto: > On Sun, Feb 21, 2021 at 07:05:26PM +0100, Luigi 'Comio' Mantellini wrote: > > I will suggest to offer two enums to handle 2 or 2.1. > > If a justification can be found for "downgrading" the advertised > version, then yes, it would be better to enumerate the actual released > and supported versions. > > > I have a question: is it insane to offer different version on port basis? > > Yes, possibly - but again, what is the use case for not always saying v2.1? > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
HI, I will suggest to offer two enums to handle 2 or 2.1. I have a question: is it insane to offer different version on port basis? Ciao Luigi Il dom 21 feb 2021, 16:34 Richard Cochran ha scritto: > On Sat, Feb 20, 2021 at 02:26:44PM +0800, Yangbo Lu wrote: > > IEEE 1588-2019 specified new UInteger4 type minorVersionPTP field in > header, > > and minorVersionNumber data in portDS. It has the value 1 for IEEE > 1588-2019, > > and has the value 0 for IEEE 1588-2008. > > I'd like to let the stack advertise the verion upgrade, since it does, > in fact, comply. > > > This patch is to make versionNumber and minorVersionNumber configurable, > rather > > than using hard-coded IEEE 1588-2008 version, for PTP packets. > > However I don't understand why this must be configurable. The user > should not be free to claim, for example, version 2.5 compliance. > > What is the use case for making the version configurable? > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 0/1] clock: Introduce step_window to free run n Sync events after a clock step.
Hi, This patch cover my scenario where the timestamper can be aligned once at second. Can I suggest to a avoid to touch free_running variable and introduce another one? Thanks, Luigi Il dom 14 feb 2021, 06:55 ha scritto: > From: Vincent Cheng > > When clock stepping is unable to happen instantaneously the subsequent > timestamps after a clock step does not reflect the step result and > undesired clock freq and clock steps would occur. > > When using ts2phc to synchronize timestamping clock using external > 1 PPS, it could take up to 1 second for the timestamps to reflect the > clock step. > > step_window, when set, indicates the number of Sync events after > a clock step in which the clock servo will not do any frequency or > step adjustments. > > Below example illustrates the problem for 16 PPS when clock step > does not occur before the next set of timestamps are received. > > Debug statements were added to show T1 and T2 timestamps and the freq > and step requests at clock_sychronize() for SERVO_JUMP. > > ptp4l[255352.651]: selected best master clock 00b0ae.fffe.02e810 > ptp4l[255352.651]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[255352.717]: debug: T1: 1611934788908411436T2: 10341336582 > ... > ptp4l[255352.904]: master offset -1611934778567080326 s0 freq-128 path > delay 5436 > ptp4l[255352.967]: debug: T1: 1611934789158411436T2: 10591336566 > ptp4l[255352.967]: debug: adj freq -159.67232 > ptp4l[255352.971]: debug: step 1611934778567080308 > ... > ptp4l[255353.217]: debug: T1: 1611934789408411436T2: 10841336502 > ptp4l[255353.217]: debug: adj freq 0.27648 > ptp4l[255353.221]: debug: step 1611934778567080368 > > At 16 PPS, the packet interval is 0.0625 seconds. > > The first step occurs at [255352.971], T2 is around 10 seconds. > The next step occurs at [255353.221], T2 is still around 10 seconds. > In an ideal setup, the clock step would be reflected instantaneously > and the correct T2 should be around 1611934799 seconds. > > Below shows result of adding step_window. > > Clock step occurs at s1, SERVO_JUMP. s2 is SERVO_LOCKED. > > The setup is using ts2phc to synhronize the network PHC to external time > stamp signal. The progation delay of the 1 PPS signals have a worst case > of 2 seconds. > > step_window is set to 0 (default 0), so retains original behavior, > ie. will use subsequent timestamps to calculate next clock adjustments. > > logSyncInterval -4 > logMinDelayReqInterval -4 > first_step_threshold0.00100 > step_threshold 0.01000 > step_window 0 > > ptp4l[3831.568]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[3831.634]: master offset -1613279867776376096 s0 freq +0 path > delay 7711 > ptp4l[3831.698]: master offset -1613279867776376100 s1 freq -64 path > delay 7707 > ptp4l[3831.822]: master offset -1613279867776376124 s0 freq -64 path > delay 7711 > ptp4l[3831.884]: master offset -1613279867776376140 s0 freq -64 path > delay 7711 > ptp4l[3831.948]: master offset -1613279867776376124 s1 freq+192 path > delay 7703 > ... > ptp4l[3832.447]: master offset -1613279867776376180 s0 freq-128 path > delay 7707 > ptp4l[3832.511]: master offset -1613279867776376166 s1 freq +96 path > delay 7705 > ptp4l[3833.572]: rms 587555636859904 max 645311947089248 freq > +67785 +/- 119252 delay 8448 +/- 2020 > ptp4l[3834.634]: rms 645311947031904 max 645311947031904 freq > -139 +/- 360 delay 7711 +/- 21 > ptp4l[3835.697]: rms 7237815975126660096 max 8136258558135193600 freq > +75045 +/- 113951 delay -137763073020509120 +/- 496711823640969536 > ptp4l[3836.696]: rms 6068654064854322176 max 8136258558135192576 freq > +69808 +/- 117623 delay 8492 +/- 1500 > ptp4l[3837.759]: rms 2174226957844811520 max 2174226957844814848 freq > -3409 +/- 6863 delay 7697 +/- 43 > ptp4l[3838.821]: rms 1348149014385676288 max 2174226957844810752 freq > -85 +/- 39 delay -113134119417210480 +/- 265323028344133024 > ptp4l[3839.821]: rms 703483405420974336 max 703483405420974336 freq -199 > +/- 52 delay 7712 +/- 11 > > The multiple clock steps (s1 - [3831.698], [3831.948], etc.) overlap each > other > and causes convergence propblems for higher packet rates like 16 packets > per second. > > Setting step_window to 32 (2 seconds at 16 PPS): > > logSyncInterval -4 > logMinDelayReqInterval -4 > first_step_threshold0.00100 > step_threshold 0.01000 > step_window 32 > > ptp4l[4051.547]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[4051.676]: master offset -1613280090261264012 s0 freq +0 path > delay 7723 > ptp4l[4051.740]: master offset -1613280090261263998 s1 freq+224 path > delay 7701 > ptp4l[4051.926]: master offset -1613280090261264042 s0 freq-256 path > delay 7709 > ptp4l[4052.051]: master offset -261264088 s0 freq +10 path delay > 7727 > ptp4l[4052.176]: master
Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support
Thanks Richard, I will try to better describe my scenario. On my input-only ITU 8271 interface I receive a Time Event message (with T1=Time and T2 timestamp and a configurable "cable delay") and at the same time I receive an Announcement-like message. Ideally, this port should work like any other slave port (slave only). My question is: how can I push T1, T2 and the "cable delay' into linuxPTP? (T3 and T4 can be derived easily). And How Can I push the announcement-like message, that can be easily mapped 1-to-1 to a PTP Announce message? You speak about an already available IPC interface, but, sorry if I ask again, can you point me to the exact calls to use? I will appreciate it a lot. Another issue is that my hw doesn't have any "linux" interface, but a creepy API that provides the TS in some way and I cannot use RAW transport. I would like to avoid touching raw.c code, but, again, I have not found any better way to implement the transport. You are right saying that this is an orrible choice, but I'm not understanding how I can create this building block outside the linuxPTP sources without hacking the transport.* This is the model PTP raw <--- creepy ETH1 driver --> [ Supervisor ] <--- ??? ---> [LinuxPTP] PTP raw <--- creepy ETH2 driver --> [ Supervisor ] <--- ??? ---^ ??? is the interface that I'm not understanding. Thanks again for your patience (but I started just now to dive into the ptp world). luigi Il giorno mer 11 nov 2020 alle ore 13:26 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Wed, Nov 11, 2020 at 10:04:46AM +0100, Luigi 'Comio' Mantellini wrote: > > This is an aspect really interesting for me, because in my environment I > > haven't true linux interfaces and the serial line discussed above. > > Is there an example of "new transport" implementation using your API? > > Yes, there is udp, udp6, and raw. > > > My idea is to directly hack transport.c/.h files adding a new entry > inside > > the create switch. Is it the correct way? > > No, that is a terrible idea. > > > Or do you have any other > > suggestions? > > Yes, and I already told you: > > > > Don't over-engineer it. Just write a program that controls the serial > > > port with PPS. All of the IPC interfaces that you need are already > > > implemented. There is no need to change ptp4l, phc2sys, or ts2phc. > > Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support
Hi Richard, Reading the project homepage I read the following statement: "Modular design allowing painless addition of new transports and clock servos.". This is an aspect really interesting for me, because in my environment I haven't true linux interfaces and the serial line discussed above. Is there an example of "new transport" implementation using your API? My idea is to directly hack transport.c/.h files adding a new entry inside the create switch. Is it the correct way? Or do you have any other suggestions? Thanks a lot, luigi Il giorno mer 4 nov 2020 alle ore 17:30 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Wed, Nov 04, 2020 at 09:43:52AM +0100, Luigi 'Comio' Mantellini wrote: > > The announce message should br managed by protocol as a normal PTP > Announce > > message to handle the BMC and select the grandmaster (I suppose). > > Don't conflate those two. > > > From my protocol picture I think that ts2phc is not the best solution > > because: > > - this cover only sink scenario (slave). What about source scenario > > (master) > > For this you don't need ts2phc. You can use ioctls directly from your > supervisor program, call out to testptp, or even use a shell script to > configure the PPS via sysfs. > > > - TAM cannot be handled in this way > > You supervisor program can do this. > > > - We cannot select automatically the best source between the serial and > > the other eth interface > > You supervisor program can do this as well. > > > Do you have any suggestions in order to handle the message (announcement > in > > primis). An idea that I have is to have a sort of "RAW_SERIAL" transport > > that translate the TEM messages into SYNC and TAM to PTP Announce. > > Don't over-engineer it. Just write a program that controls the serial > port with PPS. All of the IPC interfaces that you need are already > implemented. There is no need to change ptp4l, phc2sys, or ts2phc. > > Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support
Hi Richard, Hi All, sorry if I'm returning on this topic. The Annex A (serial interface) handles the following messages: - Time Event Message (TEM) that contains: the timestamp (48bit integer), flags (leap61m leap59, ...), and the currentUTCOffset - Time Announce message (TAM) that is very similar the PTP announce message - GNSS Status message, with information laike type of time source, status, alarms (I don't know if we really need this) Reading the standard I understood that interfaces cannot be source or sink at the same time (siee Table A.1). For this reason, the port can be configured to be just a sink or a source of signals (slave only or master only). Time Event Message is triggered on 1PPS rising edge. The message must be sent after 1ms after rising edge and be finished within 500ms. It's very similar to sync message and measuring the timestamp at 1PPS edge (T_1PPS) and the timestamp contained into the event time message (T_TEM), we can easily calculate the time offset (T_1PPS - T_TEM). The announce message should br managed by protocol as a normal PTP Announce message to handle the BMC and select the grandmaster (I suppose). >From my protocol picture I think that ts2phc is not the best solution because: - this cover only sink scenario (slave). What about source scenario (master) - TAM cannot be handled in this way - We cannot select automatically the best source between the serial and the other eth interface Do you have any suggestions in order to handle the message (announcement in primis). An idea that I have is to have a sort of "RAW_SERIAL" transport that translate the TEM messages into SYNC and TAM to PTP Announce. But I am not sure to invest this way. Again, your suggestions regarding the software design are really appreciated. Thanks a lot in advance, luigi Il giorno mer 28 ott 2020 alle ore 18:55 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Wed, Oct 28, 2020 at 06:47:29PM +0100, Luigi 'Comio' Mantellini wrote: > > > The idea under the Annex A is to propagate some information from the > serial > > link to master port. > > What "information" are we talking about? > > For setting GM attributes in ptp4l, you should use the management > interface. > > > Should be an async thread into linuxPTP that gathers these information > and > > updates the ptp messages accordingly. > > I don't think this is needed. > > > Your code save my job every day, thanks for this. > > Glad to hear that feedback! > > Thanks, > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support
Hi Richard, I'm not sure that ts2phc solution fits well. The idea under the Annex A is to propagate some information from the serial link to master port. Should be an async thread into linuxPTP that gathers these information and updates the ptp messages accordingly. Your code save my job every day, thanks for this. ciao luigi Il giorno mer 28 ott 2020 alle ore 18:31 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Wed, Oct 28, 2020 at 09:35:36AM +0100, Luigi 'Comio' Mantellini wrote: > > thanks for your reply. I'm referring to G.8271/Y.1366 document: > > https://www.itu.int/rec/T-REC-G.8271-202003-I/en > > The new standard added a protocol on top of TOD/1PPS link as defined in > the > > cited Annex A. > > Thanks for the link. Now I see. > > > > On Tue, Oct 27, 2020 at 08:03:34PM +0100, Luigi 'Comio' Mantellini > wrote: > > > > Dear All, > > > > > > > > I'm trying to understand if I can support the G.8271 Annex A.1.3 > directly > > > > via LinuxPTP. > > The Annex defines Yet Another Binary ToD message. > > I don't see ts2phc supporting dozens and dozens of different binary > ToD format. > > Instead, I would write a stand alone program that groks the Binary ToD > and serves standard NMEA RMC sentences on a local TCP port. > > Then configure ts2phc by setting > > ts2phc.nmea_remote_host > ts2phc.nmea_remote_port > > appropriately. > > (This is exactly the approach I am using to support some random GPS > device that doesn't produce usable RMC sentences.) > > Thanks, > Richard > > > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support
Hi Richard, thanks for your reply. I'm referring to G.8271/Y.1366 document: https://www.itu.int/rec/T-REC-G.8271-202003-I/en The new standard added a protocol on top of TOD/1PPS link as defined in the cited Annex A. Thanks a lot for your help, luigi Il giorno mar 27 ott 2020 alle ore 20:45 Richard Cochran < richardcoch...@gmail.com> ha scritto: > On Tue, Oct 27, 2020 at 08:03:34PM +0100, Luigi 'Comio' Mantellini wrote: > > Dear All, > > > > I'm trying to understand if I can support the G.8271 Annex A.1.3 directly > > via LinuxPTP. > > My copy doesn't have any "Annex" at all, but only Appendixes. > >ITU-T G.8271.1/Y.1366.1 (08/2013) > > No idea what you are asking about. > > Sorry, > > Richard > -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support
Dear All, I'm trying to understand if I can support the G.8271 Annex A.1.3 directly via LinuxPTP. Is there any support in place? I noticed ts2phc for NMEA messages, but nothing for LinuxPTP. From my understanding, Annex A.1.3 should be supported directly by PTP instance in order to move meta information between the TOD interface and the Eth interfaces. Alternatively do you have any suggestion to support the given scenario? Thanks a lot for my stupid questions. luigi -- *Luigi 'Comio' Mantellini* My Professional Profile <http://www.linkedin.com/in/comio> *"UNIX is very simple, it just needs a genius to understand its simplicity." [cit.]* ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
