> -Original Message-
> From: Miroslav Lichvar
> Sent: Thursday, October 29, 2020 10:24 AM
> To: Richard Cochran
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
>
> On Thu, Oct 29,
On Thu, Oct 29, 2020 at 09:53:42AM -0700, Richard Cochran wrote:
> On Thu, Oct 29, 2020 at 11:58:41AM +0100, Miroslav Lichvar wrote:
>
> > That wouldn't work well, but as phc2sys doesn't use PTP to synchronize
> > the clocks, I think it can use a different terminology than ptp4l. It
> > might
On Thu, Oct 29, 2020 at 11:58:41AM +0100, Miroslav Lichvar wrote:
> That wouldn't work well, but as phc2sys doesn't use PTP to synchronize
> the clocks, I think it can use a different terminology than ptp4l. It
> might actually be less confusing. In the current code the same clock
> is master
On Tue, Oct 27, 2020 at 04:26:53PM -0700, Richard Cochran wrote:
> On Mon, Aug 24, 2020 at 09:41:06AM +0200, Miroslav Lichvar wrote:
> > It seems you are set on this terminology. I think it would work for
> > me, although in my head I mostly see the packets on the network
> > instead of a time
On 10/27/2020 4:26 PM, Richard Cochran wrote:
> On Mon, Aug 24, 2020 at 09:41:06AM +0200, Miroslav Lichvar wrote:
>> It seems you are set on this terminology. I think it would work for
>> me, although in my head I mostly see the packets on the network
>> instead of a time signal. Have you
On Mon, Aug 24, 2020 at 09:41:06AM +0200, Miroslav Lichvar wrote:
> It seems you are set on this terminology. I think it would work for
> me, although in my head I mostly see the packets on the network
> instead of a time signal. Have you considered adopting a server/client
> terminology like NTP
On Tue, Aug 18, 2020 at 01:43:02PM -0700, Richard Cochran wrote:
> The information flowing through a PTP network may best be described as
> a time signal. As any EE will tell you, a signal flows from its
> source to one or more sinks. Thus we can trace the time signal in a
> PTP network as it
ork.com/privacy>.
Von: Richard Hill
Gesendet: Friday, August 21, 2020 7:00:51 AM
An: 'Vladimir Oltean'
Cc: linuxptp-devel@lists.sourceforge.net
Betreff: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
> But what is wrong with 'Master' - ie Master Craftsma
> But what is wrong with 'Master' - ie Master Craftsman, Master
> Boatmaker, Master Baker, therefore Master Clock. And doesn't it
> correctly describe what it's function is ?
> What do you mean what's wrong with it? The same thing that is wrong with
> 'slave', of course. Which is one meaning
On 8/20/2020 2:16 PM, Vladimir Oltean wrote:
> On Thu, Aug 20, 2020 at 11:07:09AM -0700, Richard Cochran wrote:
>> On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
>>
>>> What if the terms on which IEEE 1588 settles are not the terms in your
>>> mind ("source"/"sink")?
>>
>>
On Thu, Aug 20, 2020 at 11:07:09AM -0700, Richard Cochran wrote:
> On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
>
> > What if the terms on which IEEE 1588 settles are not the terms in your
> > mind ("source"/"sink")?
>
> Because linuxptp is widely deployed, what we do could
On Thu, Aug 20, 2020 at 07:50:29PM +0100, Richard Hill wrote:
> the word 'Slave' needs to be dropped ASAP.
> Waiting for the official committee might be like watching paint dry.
>
Sorry for being a bit thick here, but where is this sudden urgency
coming from? It's been like this for many, many
but rather replace
"slave" with "sink" starting right away.
> But what is wrong with 'Master' - ie Master Craftsman, Master Boatmaker,
> Master Baker,
> therefore
> Master Clock. And doesn't it correctly describe what it's function is ?
My plan is leave the "master" term in place for now.
On Thu, Aug 20, 2020 at 07:50:29PM +0100, Richard Hill wrote:
> I'm all a bit lost here. Perfectly understandable that the word 'Slave'
> needs to be
> dropped ASAP.
> Waiting for the official committee might be like watching paint dry.
Agreed. My plan is NOT to wait for the committee but
it correctly describe what it's function is ?
-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com]
Sent: Donnerstag, 20. August 2020 19:07
To: Vladimir Oltean
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive
On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
> What I don't get is where is the need for linuxptp to "take the lead" on
> this topic?
see next answer...
> What if the terms on which IEEE 1588 settles are not the terms in your
> mind ("source"/"sink")?
Because linuxptp is
On Thu, Aug 20, 2020 at 08:25:39AM -0700, Richard Cochran wrote:
>
> I expect that the change in the IEEE standard and in the industry is
> coming.
So, yes, the IEEE 1588 committee has changed terminology before
("time-aware bridge" -> "time-aware relay") and may do so again, to
remove words that
On Thu, Aug 20, 2020 at 04:02:30PM +0300, 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
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,
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
On Wed, Aug 19, 2020 at 11:37:15PM +0530, Jagmeet Singh Hanspal wrote:
> 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.
"closed-loop dogfight" -- love it!
> Anyways,
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,
: linuxptp-devel@lists.sourceforge.net
Subject: 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
the leader.
Erez
-Original Message-
From: Richard Cochran
Sent: Wednesday, 19 August 2020 17:20
To: Geva, Erez (ext) (DI PA CI R 3)
Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On Wed
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
that they are follows the leader.
Erez
-Original Message-
From: Richard Cochran
Sent: Wednesday, 19 August 2020 17:20
To: Geva, Erez (ext) (DI PA CI R 3)
Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive
On Wed, Aug 19, 2020 at 03:06:22PM +, Geva, Erez wrote:
> Personally I prefer leader/followers over source/sink.
Let's think about those terms...
If clock A is leading clock B, then clock A is running ahead.
If clock A is following clock B, then clock A is running behind.
Sounds rather
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
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
On 8/18/2020 1:43 PM, Richard Cochran wrote:
> There is an industry wide effort underway to replace historically and
> culturally loaded terms like master/slave with neutral alternatives.
> The IEEE 1588 committee will most likely amend the standard, but so
> far no consensus on the new
On 8/18/20, Richard Cochran wrote:
> There is an industry wide effort underway to replace historically and
> culturally loaded terms like master/slave with neutral alternatives.
...
> The information flowing through a PTP network may best be described as
> a time signal. As any EE will tell you,
31 matches
Mail list logo
