Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
Let's take it easy on one another. Initially it looks it is going towards humanoid rights, but it is different than that (more than machines' will). More towards sensitivities of the users/admin who'd read/use such terms day in/out and associated sensibilities. Unless it comes from standard, different people can choose similar but may not the same terms, and in this project contributors can take initiative & settle on something (doc, messages etc). Regards, Jagmeet On Thu, Aug 20, 2020 at 6:34 PM Vladimir Oltean wrote: > On Wed, Aug 19, 2020 at 09:42:40AM -0700, Richard Cochran wrote: > > > > In any case, this is just the kind of bikeshedding discussion that I > > want to avoid. > > But you are the one who asked for it, aren't you? > > I mean, yes, a slave is not only somebody who works for a master, but > somebody who does so for free and against their will. Whereas digital > entities don't really have a will, and therefore the term is > inappropriately used. In that sense, I think 'subordinate' is the word > you're looking for. Simple replacement and not as extravagant as > 'sheep'. > > That being said, 'master'/'slave' is a well-established technical > terminology which has little to do with human slavery, mind you. > I think you're going to have some difficulty fixing up config-visible > options such as 'slaveOnly' (without breaking deployments, which you > mentioned as one goal), so I'm not really sure what's the point, if > "words of dubious moral value" are not completely purged from the code > base. > > In the end I believe it's a balance between what problems this change is > solving, vs what problems it's creating. > > Thanks, > -Vladimir > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
Yes, each client is correcting itself to match to the the master and as a continuous process of matching to the chosen one by following it like a closed-loop dogfight. Anyways, source / sink are ok too, and maybe a super-source as GM? On Wed, Aug 19, 2020, 22:12 Richard Cochran wrote: > On Wed, Aug 19, 2020 at 04:13:38PM +, Geva, Erez wrote: > > I short. It means that they are follows the leader. > > Anyone who has ever been on a hiking trip or watched ducks in a pond > knows that the leader goes in front and the followers behind, with > each follower at different distance from the leader! > > When synchronized, a clock does not "follow" but rather matches > exactly with small adjustments. So I guess that means leader/matcher? > > And as far as sheep dogs go, the dogs are not the leaders, but rather > the farmer. Maybe we should use the terms shepard/sheep? > > In any case, this is just the kind of bikeshedding discussion that I > want to avoid. Just to be clear, I will not accept leader/follower > because it simply sounds silly. > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
Few suggestions: AVB uses end-stations and relays, as well as initiator/responder as the context maybe, like: - PTP End Instance: The AVB talkers and listener end-stations. It may also be a GM. - PTP Relay Instance: Could be inside a bridge, a router, or a multiport end-station. - PTP .1AS initiator: The node that has initiated the Peer-to-Peer delay mechanism. - PTP .1AS responder: The peer-node that is responding to the P2P delay request. And Source/Sink or Client/Server may also be ok, in the documentation. The master/slave etc will have to be replaced in the IEEE 1588 and GM etc all the way to ITU-T telecom standards. The term, “slave” has the negative connotations, rather a “follower” that chooses its leader or role-model (GM -> RM) and looks-up to follow its lead. Anyways, even in the IEEE standard (like Richard mentioned), a master is not employing slaves, instead, it is the follower that is "choosing" who it needs to consider a leader and subsequently follow it, so in our conversations, we are starting to use these terminologies instead. Regards, Jagmeet On Wed, Aug 19, 2020 at 3:26 AM Richard Cochran wrote: > On Tue, Aug 18, 2020 at 02:51:26PM -0700, Jacob Keller wrote: > > Yep, makes sense. Long term, after changing the stuff which doesn't > > impact config, we can work towards finding a way to deprecate and rename > > config options in a way that won't break existing deployment. I'm > > personally Ok with simply leaving the original name as a deprecated > > alternative name with an explanation. > > That is what I was thinking, too. > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
d on the last received sync. So it is more a TC with > > >> some artificial update. > > >> - as far as I understand the standard, the source port ID is the one > > >> from the grandmaster. Strange enough most implementations get this > > >> wrong. Maybe I'm wrong, it is very hard to follow that standard. > > >> > > >> There is also this patch > > >> [RFC V3, 3/4] port: drop erroneous neighbor rate ratio > > >> > > >> which I don't know why it is there. In my experience, this patch make > > >> things just worse. It won't sync anymore if the rate ratio is too > > >> high. > > >> While this might be mandatory to be compliant, I really question > > >> whether it is actually useful. So generic question, do we want to > > >> follow the standard no matter what, or do we want to be on the safe > > >> side and try to actually sync the clocks? > > >> > > >> -michael > > >> > > >> > If it helps your workflow, I can surely put those patches on a > > >> > branch on Github for you. > > >> > > > >> > Thanks, > > >> > Richard > > >> > > > >> > > > >> > > > >> > ___ > > >> > Linuxptp-devel mailing list > > >> > Linuxptp-devel@lists.sourceforge.net > > >> > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/lis > > >> > tin > > >> > fo/linuxptp-devel__;!!FbZ0ZwI3Qg!832O5vPvHyh_bdJuQJ2MUFpe66PcaA8zGa > > >> > 8Gk > > >> > 6djEA8klY2Depb33MK-NtLhWg7kbA$ > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
; > * @param sde Pass one (1) if need a decision event and zero if not.
> > > @@ -359,4 +383,25 @@ void clock_check_ts(struct clock *c, uint64_t ts);
> > > */
> > > double clock_rate_ratio(struct clock *c);
> > >
> > > +/**
> > > + * Prepare sync/follow_up relay.
> > > + * @param c The clock instance.
> > > + * @param sync The sync message.
> > > + * @param fup The follow_up message.
> > > + */
> > > +void clock_prepare_syfu_relay(struct clock *c, struct ptp_message
> *sync,
> > > + struct ptp_message *fup);
> > > +
> > > +/**
> > > + * Disable sync/follow_up relay.
> > > + * @param c The clock instance.
> > > + */
> > > +void clock_disable_syfu_relay(struct clock *c);
> > > +
> > > +/**
> > > + * Get sync/follow_up relay information.
> > > + * @param c The clock instance.
> > > + * @return The sync/follow_up relay information.
> > > + */
> > > +struct syfu_relay_info *clock_get_syfu_relay(struct clock *c);
> > > #endif
> > > diff --git a/port.c b/port.c
> > > index 07ad3f0..073e71a 100644
> > > --- a/port.c
> > > +++ b/port.c
> > > @@ -1241,6 +1241,10 @@ static void port_syfufsm(struct port *p, enum
> > > syfu_event event,
> > > break;
> > > case FUP_MATCH:
> > > syn = p->last_syncfup;
> > > + if (p->follow_up_info)
> > > + clock_prepare_syfu_relay(p->clock, syn, m);
> > > + else
> > > + clock_disable_syfu_relay(p->clock);
> > > port_synchronize(p, syn->hwts.ts, m->ts.pdu,
> > > syn->header.correction,
> > > m->header.correction,
> > > @@ -1261,6 +1265,10 @@ static void port_syfufsm(struct port *p, enum
> > > syfu_event event,
> > > break;
> > > case SYNC_MATCH:
> > > fup = p->last_syncfup;
> > > + if (p->follow_up_info)
> > > + clock_prepare_syfu_relay(p->clock, m, fup);
> > > + else
> > > + clock_disable_syfu_relay(p->clock);
> > > port_synchronize(p, m->hwts.ts, fup->ts.pdu,
> > > m->header.correction,
> > > fup->header.correction,
> > > @@ -1450,6 +1458,60 @@ int port_tx_announce(struct port *p, struct
> > > address
> > > *dst)
> > > return err;
> > > }
> > >
> > > +static void port_syfu_relay_info_insert(struct port *p,
> > > + struct ptp_message *sync,
> > > + struct ptp_message *fup)
> > > +{
> > > + struct syfu_relay_info *syfu_relay =
> clock_get_syfu_relay(p->clock);
> > > + struct follow_up_info_tlv *fui_relay = _relay->fup_info_tlv;
> > > + struct follow_up_info_tlv *fui = follow_up_info_extract(fup);
> > > + tmv_t ingress, egress, residence, path_delay;
> > > + double gm_rr, nrr, rr;
> > > + struct timestamp ts;
> > > +
> > > + if (syfu_relay->avail == 0)
> > > + return;
> > > +
> > > + fup->follow_up.preciseOriginTimestamp =
> > > + tmv_to_Timestamp(syfu_relay->precise_origin_ts);
> > > + fup->header.correction = syfu_relay->correction;
> > > +
> > > + /* Calculate residence time. */
> > > + ingress = clock_ingress_time(p->clock);
> > > + egress = sync->hwts.ts;
> > > + residence = tmv_sub(egress, ingress);
> > > + rr = clock_rate_ratio(p->clock);
> > > + if (rr != 1.0) {
> > > + residence = dbl_tmv(tmv_dbl(residence) * rr);
> > > + }
> > > +
> > > + gm_rr = 1.0 + (fui_relay->cumulativeScaledRateOffset + 0.0) /
> > > POW2_41;
> > > + nrr = clock_get_nrr(p->clock);
> > > +
> > > + /* Add corrected residence time into correction. */
> > > + fup->header.correction += tmv_to_TimeInterval(residence) * gm_rr *
> > > +nrr;
> > > +
> > > + /* Add corrected path delay into correction. */
> > > + path_delay = clock_get_path_delay(p->clock);
> > > + fup->header.correction += tmv_to_TimeInterval(path_delay) * gm_rr;
> > > +
> > > + /* Update follow_up TLV */
> > > + gm_rr *= nrr;
> > > + fui->cumulativeScaledRateOffset = gm_rr * POW2_41 - POW2_41;
> > > + fui->scaledLastGmPhaseChange = fui_relay->scaledLastGmPhaseChange;
> > > + fui->gmTimeBaseIndicator = fui_relay->gmTimeBaseIndicator;
> > > + memcpy(>lastGmPhaseChange, _relay->lastGmPhaseChange,
> > > + sizeof(fui->lastGmPhaseChange));
> > > +
> > > + ts.sec = fup->follow_up.preciseOriginTimestamp.seconds_msb;
> > > + ts.sec = ts.sec << 32 | fup-
> > > >follow_up.preciseOriginTimestamp.seconds_lsb;
> > > + ts.nsec = fup->follow_up.preciseOriginTimestamp.nanoseconds;
> > > + pr_debug("port %hu: syfu_relay info:", portnum(p));
> > > + pr_debug("port %hu: precise_origin_ts %" PRIu64 ".%u",
> portnum(p),
> > > ts.sec, ts.nsec);
> > > + pr_debug("port %hu: correction %" PRId64, portnum(p), fup-
> > > >header.correction >> 16);
> > > + pr_debug("port %hu: fup_info %.9f", portnum(p), gm_rr);
> > > +}
> > > +
> > > int port_tx_sync(struct port *p, struct address *dst) {
> > > struct ptp_message *msg, *fup;
> > > @@ -1543,10 +1605,15 @@ int port_tx_sync(struct port *p, struct
> > > address
> > > *dst)
> > > fup->address = *dst;
> > > fup->header.flagField[0] |= UNICAST;
> > > }
> > > - if (p->follow_up_info && follow_up_info_append(fup)) {
> > > - pr_err("port %hu: append fup info failed", portnum(p));
> > > - err = -1;
> > > - goto out;
> > > +
> > > + if (p->follow_up_info) {
> > > + if (follow_up_info_append(fup)) {
> > > + pr_err("port %hu: append fup info failed",
> portnum(p));
> > > + err = -1;
> > > + goto out;
> > > + }
> > > +
> > > + port_syfu_relay_info_insert(p, msg, fup);
> > > }
> > >
> > > err = port_prepare_and_send(p, fup, TRANS_GENERAL);
> > > --
> > > 2.7.4
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
--
Best Regards,
~
Jagmeet Singh Hanspal
~
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp filter architure
I have hardware which looks like a half of a TC function. > It has a local clock which counts time since boot in the correction field > format. (Clocked from the Ethernet RX clock for SyncE.) > On packet receive, it picks out the event packets and subtracts the local > clock from the correction field in the packet. (Incrementally updating the > udp and fcs.) > On packet transmit, it picks out the event packets and adds the local > clock to the correction field. > It's a half TC function because packet switching hardware supporting TC > might implement these functions so a packet transiting the box encounters > both the receive and transmit functions. > I plan to do the other half in the PTP packet handling software. > S/W rx reads local time and both sets the rx timestamp to this value and > adds it to the correction field. > S/W tx reads local time and both sets the tx timestamp and subtracts same > from the correction field. > Given this, no special per-packet timestamping functions are required in > the kernel and the reading of local time does not need to be especially > accurate. > > For output, I can tell the hardware what local time to put out a 1PPS for > testing. Not particularly interested in synchronizing the Linux system > time to the ptp time. > > The above seems a mind shift from where things are today, so I'd like to > first do something easy to see if it works before making it pretty. > I'd like to stay out of kernel space for now to keep the scope of the > experiment small enough to actually get done. > (Open /dev/mem and map a window to the fpga regs into the ptp4l.) > Given this, I can add another timestamping mode and put the s/w > timestamping into bc_event and port_prepare_and_send. > You have pointed out where to put in the dual filters. > The servo looks straight forward. > > The remaining part appears to be figuring out how to turn off the all the > kernel packet timestamping help. > Also, turning off the /dev/ptp0 stuff. > > > Thoughts? > > > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] condition of master clock re-selection at master clock failure?
IMO, it should be part of the BMC algo and IEEE 1588. Regards, jagmeet On Fri, Jul 5, 2019 at 12:01 PM Jeaho Hwang wrote: > Hi. I got a request to inform the mechanism of recognizing a failure of > original master clock and re-select a new master clock. Is it a part of > IEEE1588 or implementation of linuxptp? > > Thanks. > > -- > 황재호, Jay Hwang, a member of RTst > 010-7242-1593 > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
