Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
> -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, 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 actually be less confusing. In the current code the same clock > > > is master and slave at the same time in different contexts. > > > > So how about using client/server in the context of the PTP and > > source/sink in phc2sys and ts2phc? > > Yes, I think I would prefer that over source/sink everywhere. To me, > server and client are network-related terms, something implementing a > network protocol, which in context of PTP has a single clock. Sink and > source work as more general terms. As an adjective of a clock, "source > clock" works well, but "sink clock" sounds weird to me. I found this > term in some DisplayPort and HDMI documentation. Maybe it's alright, I > don't know. Native speakers should give you a better feedback or > suggestions. If we used "time source" and "time sink", but that wouldn't include clock in the name. What about "target clock"? ___ 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
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 actually be less confusing. In the current code the same clock > > is master and slave at the same time in different contexts. > > So how about using client/server in the context of the PTP and > source/sink in phc2sys and ts2phc? Yes, I think I would prefer that over source/sink everywhere. To me, server and client are network-related terms, something implementing a network protocol, which in context of PTP has a single clock. Sink and source work as more general terms. As an adjective of a clock, "source clock" works well, but "sink clock" sounds weird to me. I found this term in some DisplayPort and HDMI documentation. Maybe it's alright, I don't know. Native speakers should give you a better feedback or suggestions. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 0/1] msg: fix incorrect suffix detection for frames longer than messageLength
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 drop frames which fail the check. This fundamental to the correct operation of Ethernet. > It may be that some NICs strip the CRC before sending a packet to > the host, but there’s no standard requiring it to do so (that I know > of?), and many NICs optionally allow users to turn this stripping > off. Where in 802.3 can I read about disabling the CRC or putting other things (like time stamps) in there? > It is not completely useless to forward the CRC to software. I gave > some examples of cases where software may want to see the CRC for > various reasons, for example, switches doing (completely utterly > ridiculously) silly things with CRCs, And why on Earth do I want to support that? > or software that is doing capture/analysis of raw frames. Okay, so that is a valid use case. If you would like to implement it, then the proper way is adding a configuration option, say "raw.fcs", that enables stripping the extra bytes. > Any correct software should be able to handle both cases (with and > without a CRC) and indeed all software that I’ve come across so far > that parses Ethernet frames directly does so (with the exception of > this project it would seem). Moreover, if I understand it correctly, > the argument made by Matt Sanders (for this patch) is that 1558 > standard does not require systems to rely on the length of a > frame/packet to determine if a TLV is present (as this project > does). Instead the standard provides a mechanism, which is the > messageLength value in the header, for figuring this out. It seems > that you don’t want to make use of this mechanism, but the > justification eludes me. The messageLength field is nice to have, but it is redundant for all of the implemented transports. The code carefully verifies the lengths of PDUs for each transport. This practice is called error checking. 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
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 slave at the same time in different contexts. So how about using client/server in the context of the PTP and source/sink in phc2sys and ts2phc? 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
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 signal. Have you considered adopting a server/client > > terminology like NTP is using? I know some people that use it with PTP > > and maybe it would be easier for a wider adoption. > > I considered that, but ... > > How would you feel about client/server terminology in the context of > phc2sys? 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 slave at the same time in different contexts. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
