> -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, 2020 at 09:53:42AM -0700, Rich
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 act
On Thu, Oct 29, 2020 at 02:40:55PM +1100, Matthew P. Grosvenor wrote:
> I think you’re missing the point here. You made two assertions:
> The NIC MAC should either strip the CRC, or should drop a packet with a bad
> CRC.
No, that is not what I meant. The job of the MAC is to check the CRC
and d
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 and
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 sign
