linuxptp-devel

[Linuxptp-devel] PTP supported profiles.

[Emilio M. L. <em...@se...>]

Hello PTP developers,

I'm checking what kind of PTP profiles are supported by the last release 
of the linuxptp tool. I only have found this info at the README file:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
   - Implements Boundary Clock (BC) and Ordinary Clock (OC).

   - Transport over UDP/IPv4, UDP/IPv6, and raw Ethernet (Layer 2).
[...]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I've been sniffing around this mailing list and found a couple of mails 
about the topic three years ago.

I would like to know if the following PTP profiles are currently 
supported by the linuxptp:

-          PTP default profile
-          IEEE-C37.238 Power Profile
-          ITU-1 G.8265.1 Frequency Profile
-          ITU-T G.8275.1 Time and Phase Profile

... or if there is any plan to implement them...

Also I want to ask about the unicast traffic.

Thank you very much for your work and efforts

Best regards,

Emilio.

Re: [Linuxptp-devel] PTP supported profiles.

[Richard C. <ric...@gm...>]

On Thu, Feb 16, 2017 at 06:30:31PM +0100, Emilio Marín López wrote:
> I would like to know if the following PTP profiles are currently 
> supported by the linuxptp:
> 
> -          PTP default profile

Yes.

> -          IEEE-C37.238 Power Profile

Yes and no.  We do not produce messages with the profile specific TLV
attached.  So, as a client, we can support this profile.  It is simply
a matter of changing a few options in default.cfg.

Also, IIRC, the latest add on to IEC 61850 specifies something like
the Power Profile, but without the TLVs.  So we support that, too.

> -          ITU-1 G.8265.1 Frequency Profile

No.

> -          ITU-T G.8275.1 Time and Phase Profile

Again, as a client, we can support this.  As a Grand Master or
Boundary Clock, we don't support the profile specific "notSlave" or
"localPriority" options.  Even without "notSlave", I expect that a
normal GM would work fine in this profile.

> ... or if there is any plan to implement them...

I might be able to offer ITU-T G.8275.1 later on this year, but I
can't promise it.
 
> Also I want to ask about the unicast traffic.

We don't support unicast, and it would be lots of work to add it.

HTH,
Richard

Re: [Linuxptp-devel] PTP supported profiles.

[Miroslav L. <mli...@re...>]

On Fri, Feb 17, 2017 at 08:17:16AM +0100, Richard Cochran wrote:
> On Thu, Feb 16, 2017 at 06:30:31PM +0100, Emilio Marín López wrote:
> > Also I want to ask about the unicast traffic.
> 
> We don't support unicast, and it would be lots of work to add it.

Do you think it would be worth adding support for the hybrid
multicast/unicast mode, where only delay request and response are
unicast, in order to save network traffic in very large networks?
If I understand it correctly, this might work without the registration
part of the protocol.

-- 
Miroslav Lichvar

Re: [Linuxptp-devel] PTP supported profiles.

[Richard C. <ric...@gm...>]

On Fri, Feb 17, 2017 at 10:27:34AM +0100, Miroslav Lichvar wrote:
> Do you think it would be worth adding support for the hybrid
> multicast/unicast mode, where only delay request and response are
> unicast, in order to save network traffic in very large networks?
> If I understand it correctly, this might work without the registration
> part of the protocol.

We've got that already, as of v1.6.

   776f772 Merge the hybrid E2E work.
   e85cb68 Support hybrid E2E using unicast delay requests and responses.

Thanks,
Richard

Re: [Linuxptp-devel] PTP supported profiles.

[Miroslav L. <mli...@re...>]

On Fri, Feb 17, 2017 at 11:00:30AM +0100, Richard Cochran wrote:
> On Fri, Feb 17, 2017 at 10:27:34AM +0100, Miroslav Lichvar wrote:
> > Do you think it would be worth adding support for the hybrid
> > multicast/unicast mode, where only delay request and response are
> > unicast, in order to save network traffic in very large networks?
> > If I understand it correctly, this might work without the registration
> > part of the protocol.
> 
> We've got that already, as of v1.6.
> 
>    776f772 Merge the hybrid E2E work.
>    e85cb68 Support hybrid E2E using unicast delay requests and responses.

Awesome, I didn't realize we already have that :). Full unicast
support doesn't seem very useful to me, but maybe I just didn't see
the right use case for it.

Thanks,

-- 
Miroslav Lichvar

Re: [Linuxptp-devel] PTP supported profiles.

[Richard C. <ric...@gm...>]

On Fri, Feb 17, 2017 at 11:08:39AM +0100, Miroslav Lichvar wrote:
> Awesome, I didn't realize we already have that :). Full unicast
> support doesn't seem very useful to me, but maybe I just didn't see
> the right use case for it.

It is specified in one of the telecom profiles.  The ITU published two
profiles.

1. ITU-1 G.8265.1 Frequency Profile
2. ITU-T G.8275.1 Time and Phase Profile

#1 specifies unicast negotiation, forbidding multicast, boundary
 clocks, and transparent clocks.

#2 specifies multicast, forbidding unicast.  Transparent clocks are
 also not allowed, but they are named as a future possibility.

Both profiles exhibit a surprising level of cluelessness, but #1 is
worse than the other.

Thanks,
Richard