Re: [Linuxptp-devel] Transport specific in UDP
On Fri, Feb 16, 2018 at 12:18:16PM +0100, Petr Kulhavy wrote: > that sounds like a good solution. Are you going to include it in the > mainstream? If it works for you, then yes. Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
Hi Richard,
that sounds like a good solution. Are you going to include it in the
mainstream?
Regards
Petr
On 13/02/18 19:19, Richard Cochran wrote:
On Tue, Feb 13, 2018 at 06:04:55PM +0100, Petr Kulhavy wrote:
Let me develop this idea further. What about splitting the transportSpecific
into the two nibbles, where lower nibble is as now and the upper nibble is a
mask telling which bits to ignore on RX.
I think it would less confusing to simply have a new configuration
item. It could be:
transport_specific_ignore [0|1]
When set, the transportSpecific field of incoming messages is
ignored.
(untested patch, below)
In my view, this would be enough. I doubt we will get to the point of
needing individual bits ignored.
One more thing to mention here. The different tools are still not aligned on
the configuration. So while ptp4l takes the transportSpecific value from the
config file, pmc from the command line, phc2sys doesn't have this option.
Would this approach still work also with phc2sys?
The phc2sys program has enough command line options as is. It would
be useful to add one last option, phc2sys -f [file].
And does it make sense to require full match of transportSpecific on UDS?
It isn't needed, of course, but for the sake of consistency it makes
sense. You can send management messages locally via UDS, and
depending on the value of 'boundary_hops' these are forwarded out the
network interfaces. So we really want to treat UDS in the same way.
Thanks,
Richard
---
diff --git a/config.c b/config.c
index bbaf36e..4c30214 100644
--- a/config.c
+++ b/config.c
@@ -192,6 +192,7 @@ struct config_item config_tab[] = {
PORT_ITEM_INT("freq_est_interval", 1, 0, INT_MAX),
GLOB_ITEM_INT("gmCapable", 1, 0, 1),
PORT_ITEM_INT("hybrid_e2e", 0, 0, 1),
+ PORT_ITEM_INT("ignore_transport_specific", 0, 0, 1),
PORT_ITEM_INT("ingressLatency", 0, INT_MIN, INT_MAX),
GLOB_ITEM_INT("kernel_leap", 1, 0, 1),
PORT_ITEM_INT("logAnnounceInterval", 1, INT8_MIN, INT8_MAX),
diff --git a/port.c b/port.c
index d8e29d5..9bf2c39 100644
--- a/port.c
+++ b/port.c
@@ -125,6 +125,7 @@ struct port {
int follow_up_info;
int freq_est_interval;
int hybrid_e2e;
+ int match_transport_specific;
int min_neighbor_prop_delay;
int path_trace_enabled;
int rx_timestamp_offset;
@@ -641,7 +642,8 @@ static int port_ignore(struct port *p, struct ptp_message
*m)
if (path_trace_ignore(p, m)) {
return 1;
}
- if (msg_transport_specific(m) != p->transportSpecific) {
+ if (p->match_transport_specific &&
+ msg_transport_specific(m) != p->transportSpecific) {
return 1;
}
if (pid_eq(&m->header.sourcePortIdentity, &p->portIdentity)) {
@@ -1489,6 +1491,7 @@ static int port_initialize(struct port *p)
p->syncReceiptTimeout = config_get_int(cfg, p->name,
"syncReceiptTimeout");
p->transportSpecific = config_get_int(cfg, p->name,
"transportSpecific");
p->transportSpecific <<= 4;
+ p->match_transport_specific = !config_get_int(cfg, p->name,
"ignore_transport_specific");
p->logSyncInterval = config_get_int(cfg, p->name,
"logSyncInterval");
p->logMinPdelayReqInterval = config_get_int(cfg, p->name,
"logMinPdelayReqInterval");
p->neighborPropDelayThresh = config_get_int(cfg, p->name,
"neighborPropDelayThresh");
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
On Tue, Feb 13, 2018 at 06:04:55PM +0100, Petr Kulhavy wrote:
> Let me develop this idea further. What about splitting the transportSpecific
> into the two nibbles, where lower nibble is as now and the upper nibble is a
> mask telling which bits to ignore on RX.
I think it would less confusing to simply have a new configuration
item. It could be:
transport_specific_ignore [0|1]
When set, the transportSpecific field of incoming messages is
ignored.
(untested patch, below)
In my view, this would be enough. I doubt we will get to the point of
needing individual bits ignored.
> One more thing to mention here. The different tools are still not aligned on
> the configuration. So while ptp4l takes the transportSpecific value from the
> config file, pmc from the command line, phc2sys doesn't have this option.
> Would this approach still work also with phc2sys?
The phc2sys program has enough command line options as is. It would
be useful to add one last option, phc2sys -f [file].
> And does it make sense to require full match of transportSpecific on UDS?
It isn't needed, of course, but for the sake of consistency it makes
sense. You can send management messages locally via UDS, and
depending on the value of 'boundary_hops' these are forwarded out the
network interfaces. So we really want to treat UDS in the same way.
Thanks,
Richard
---
diff --git a/config.c b/config.c
index bbaf36e..4c30214 100644
--- a/config.c
+++ b/config.c
@@ -192,6 +192,7 @@ struct config_item config_tab[] = {
PORT_ITEM_INT("freq_est_interval", 1, 0, INT_MAX),
GLOB_ITEM_INT("gmCapable", 1, 0, 1),
PORT_ITEM_INT("hybrid_e2e", 0, 0, 1),
+ PORT_ITEM_INT("ignore_transport_specific", 0, 0, 1),
PORT_ITEM_INT("ingressLatency", 0, INT_MIN, INT_MAX),
GLOB_ITEM_INT("kernel_leap", 1, 0, 1),
PORT_ITEM_INT("logAnnounceInterval", 1, INT8_MIN, INT8_MAX),
diff --git a/port.c b/port.c
index d8e29d5..9bf2c39 100644
--- a/port.c
+++ b/port.c
@@ -125,6 +125,7 @@ struct port {
int follow_up_info;
int freq_est_interval;
int hybrid_e2e;
+ int match_transport_specific;
int min_neighbor_prop_delay;
int path_trace_enabled;
int rx_timestamp_offset;
@@ -641,7 +642,8 @@ static int port_ignore(struct port *p, struct ptp_message
*m)
if (path_trace_ignore(p, m)) {
return 1;
}
- if (msg_transport_specific(m) != p->transportSpecific) {
+ if (p->match_transport_specific &&
+ msg_transport_specific(m) != p->transportSpecific) {
return 1;
}
if (pid_eq(&m->header.sourcePortIdentity, &p->portIdentity)) {
@@ -1489,6 +1491,7 @@ static int port_initialize(struct port *p)
p->syncReceiptTimeout = config_get_int(cfg, p->name,
"syncReceiptTimeout");
p->transportSpecific = config_get_int(cfg, p->name,
"transportSpecific");
p->transportSpecific <<= 4;
+ p->match_transport_specific = !config_get_int(cfg, p->name,
"ignore_transport_specific");
p->logSyncInterval = config_get_int(cfg, p->name,
"logSyncInterval");
p->logMinPdelayReqInterval = config_get_int(cfg, p->name,
"logMinPdelayReqInterval");
p->neighborPropDelayThresh = config_get_int(cfg, p->name,
"neighborPropDelayThresh");
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
Hi Richard, On 13/02/18 17:27, Richard Cochran wrote: On Tue, Feb 13, 2018 at 10:50:23AM +0100, brain wrote: Dante sends ts=8 and other manufacturers send ts=0. Unless Linuxptp properly implements the ts handling (i.e. ignoring bits 1-3) it cannot work in such networks. Simply because fix-configuring to one value (Dante or non-Dante) filters out the other clock source(s). Ok. Thanks for explaining this. I wonder what ts=8 means in a Dante network. Do you know? Maybe it comes from PTPv1? Because Dante natively uses PTPv1 and in AES67 mode uses PTPv2. What other answer would offer to this problem then? I have another idea how to support this use case. We can use a configuration value of transportSpecific = 0x10 to mean "ignore". Let me develop this idea further. What about splitting the transportSpecific into the two nibbles, where lower nibble is as now and the upper nibble is a mask telling which bits to ignore on RX. This would have several advantages * the TX value can be configured independently, whereas with a special "ignore value" it would be fixed to 1 value. * on RX it can be fully configured bitwise which bits to process * backwards compatible (as your proposal) * all 256 values have a meaning and there is no "special case" value, which gives a cleaner design One more thing to mention here. The different tools are still not aligned on the configuration. So while ptp4l takes the transportSpecific value from the config file, pmc from the command line, phc2sys doesn't have this option. Would this approach still work also with phc2sys? And does it make sense to require full match of transportSpecific on UDS? Regards Petr -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
On Tue, Feb 13, 2018 at 10:50:23AM +0100, brain wrote: > Dante sends ts=8 and other manufacturers send ts=0. Unless Linuxptp > properly implements the ts handling (i.e. ignoring bits 1-3) it > cannot work in such networks. Simply because fix-configuring to one > value (Dante or non-Dante) filters out the other clock source(s). Ok. Thanks for explaining this. I wonder what ts=8 means in a Dante network. Do you know? > What other answer would offer to this problem then? I have another idea how to support this use case. We can use a configuration value of transportSpecific = 0x10 to mean "ignore". > I'm wondering what blocks you to accept this simple change. It a) > improves compliancy with the standard, b) improves interoperability, > c) is very small and therefore low risk. For me these are already > very strong arguments for the change. You seem to must have even > stronger argument against it, when you still rejecting it. I would > like to learn that logical argument. I do want to support inter-operation as much as is practical. However, I also want to understand the issues and find the best solution, keeping in mind the design of the software. Simply put, I want to keep the non-standard option of matching on transportSpecific. As I mentioned, this allows AVB over IP to just work. Possibly other people are using or will use transportSpecific in creative ways that we don't know about. We can support your use case without breaking any other uses of that field... Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
Hi Richard, Unfortunately the fixed configuration doesn't work in mixed networks, as I already said. An AES67 network with Dante and some other AES67 manufacturer equipment (Ravenna, Archwave or other) is a very common use case. AES67 is all about interoperability of different vendors and Dante is very widely used technology in pro audio networking. So the chances that an AES67 network contains one Dante and one non-Dante device are quite high. Dante sends ts=8 and other manufacturers send ts=0. Unless Linuxptp properly implements the ts handling (i.e. ignoring bits 1-3) it cannot work in such networks. Simply because fix-configuring to one value (Dante or non-Dante) filters out the other clock source(s). So there would have to be someone permanently standing there and changing the Linuxptp configuration according to the current best master clock selected. Which is totally impractical. What other answer would offer to this problem then? I'm wondering what blocks you to accept this simple change. It a) improves compliancy with the standard, b) improves interoperability, c) is very small and therefore low risk. For me these are already very strong arguments for the change. You seem to must have even stronger argument against it, when you still rejecting it. I would like to learn that logical argument. RegardsPetr Původní zpráva Od: Richard Cochran Datum: 13.02.18 3:11 (GMT+01:00) Komu: Petr Kulhavy Cc: linuxptp-devel@lists.sourceforge.net Předmět: Re: [Linuxptp-devel] Transport specific in UDP On Mon, Feb 12, 2018 at 08:05:36PM +0100, Petr Kulhavy wrote: > As you probably know, it is closed. I don't know very much about it, and that is why I asked. Maybe there is a good reason to set these bits. If dante networks use value X, then the easiest and most logical way to inter-operate is to use --transportSpecific=X and be done with it. As an added bonus, all of the PTP frames will be consistent. The general approach that I have haven with linuxptp is to make most everything configurable. That is how we are able to support such a large variety of profiles, including 1588 and 802.1-AS. Rather than hard coding different profiles, the user may freely mix and match. For example, there has been some talk about using AVB over IP networks. With linuxptp, this is already supported. You simply edit gPTP.cfg and change 'network_transport' from 'L2' to 'UDPv4', and it works. > However let's not divert from the original topic. I do indeed have several > pointers to the IEEE1588-2008 specification showing where Linuxptp is not > compliant and do have a real-life situation where this incompatibility makes > Linuxptp unusable in a professional environment. Which is quite a pity. Too bad the software isn't working in your "professional" environment. Sorry, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
On Mon, Feb 12, 2018 at 08:05:36PM +0100, Petr Kulhavy wrote: > As you probably know, it is closed. I don't know very much about it, and that is why I asked. Maybe there is a good reason to set these bits. If dante networks use value X, then the easiest and most logical way to inter-operate is to use --transportSpecific=X and be done with it. As an added bonus, all of the PTP frames will be consistent. The general approach that I have haven with linuxptp is to make most everything configurable. That is how we are able to support such a large variety of profiles, including 1588 and 802.1-AS. Rather than hard coding different profiles, the user may freely mix and match. For example, there has been some talk about using AVB over IP networks. With linuxptp, this is already supported. You simply edit gPTP.cfg and change 'network_transport' from 'L2' to 'UDPv4', and it works. > However let's not divert from the original topic. I do indeed have several > pointers to the IEEE1588-2008 specification showing where Linuxptp is not > compliant and do have a real-life situation where this incompatibility makes > Linuxptp unusable in a professional environment. Which is quite a pity. Too bad the software isn't working in your "professional" environment. Sorry, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
On 12/02/18 19:12, Richard Cochran wrote: On Mon, Feb 12, 2018 at 08:12:38AM +0100, brain wrote: I understand that you might find this requirement to be pointless. However in protocols it is not uncommon that certain bits are reserved for future use. In order to provide forward compatible implementations it is a common practice to require reserved bits to be ignored on reception. That is not what is going on here. These bits are *not* reserved for future use. I cannot agree with you. See Annex D.4 of IEEE1588-2008. It clearly says "bit 1-3: reserved". Due to the non-compliant implementation Linuxptp does not work in a mixed AES67 network where Dante devices are present. Other AES67 implementations work well because they correctly ignore bits 1-3. Ah, now we are getting somewhere. These bits are set by Dante devices when they try and do PTP, correct? Do you have a pointer to the Dante specification that explains this behavior? As you probably know, it is closed. However let's not divert from the original topic. I do indeed have several pointers to the IEEE1588-2008 specification showing where Linuxptp is not compliant and do have a real-life situation where this incompatibility makes Linuxptp unusable in a professional environment. Which is quite a pity. Regards Petr -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
On Mon, Feb 12, 2018 at 08:12:38AM +0100, brain wrote: > I understand that you might find this requirement to be > pointless. However in protocols it is not uncommon that certain bits > are reserved for future use. In order to provide forward compatible > implementations it is a common practice to require reserved bits to > be ignored on reception. That is not what is going on here. These bits are *not* reserved for future use. > In any case, the point of standards is not to cherrypick what one > finds good on them (and indeed there are bad standards too), but to > fully comply to them to get the maximum compatibility between > devices. But not to the point of madness. We have already seen many examples of PTP implementations ignoring the standard and creatively inventing new behavior. That is just the real world. > Due to the non-compliant implementation Linuxptp does not work in a > mixed AES67 network where Dante devices are present. Other AES67 > implementations work well because they correctly ignore bits 1-3. Ah, now we are getting somewhere. These bits are set by Dante devices when they try and do PTP, correct? Do you have a pointer to the Dante specification that explains this behavior? Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
Hi Richard, I understand that you might find this requirement to be pointless. However in protocols it is not uncommon that certain bits are reserved for future use. In order to provide forward compatible implementations it is a common practice to require reserved bits to be ignored on reception. In any case, the point of standards is not to cherrypick what one finds good on them (and indeed there are bad standards too), but to fully comply to them to get the maximum compatibility between devices. Due to the non-compliant implementation Linuxptp does not work in a mixed AES67 network where Dante devices are present. Other AES67 implementations work well because they correctly ignore bits 1-3. RegardsPetr Původní zpráva Od: Richard Cochran Datum: 12.02.18 1:41 (GMT+01:00) Komu: Petr Kulhavy Cc: linuxptp-devel@lists.sourceforge.net Předmět: Re: [Linuxptp-devel] Transport specific in UDP On Sun, Feb 11, 2018 at 05:55:25PM +0100, Petr Kulhavy wrote: > It seems linuxptp does not comply to the IEEE1588-2008 standard when it > comes to processing of the transport specific field in UDP transport. > > The Annex D.4 of the standard says "bit 1-3, reserved, The bit shall be > transmitted as zero and ignored by the receiver". > Linuxptp does not ignore bits 1-3, it requires them to be identical to the > configured value. > > Why this incompatibility? This is one of a few requirements that is illogical, pointless, and just plain wrong. Probably some vendor with a legacy, non-fixable HW got this text in, but only because the vendor sat on the committee. I can't think of any valid technical reason to ignore these bits. Having said that, do you actually have some equipment that depends on this behavior? Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Transport specific in UDP
On Sun, Feb 11, 2018 at 05:55:25PM +0100, Petr Kulhavy wrote: > It seems linuxptp does not comply to the IEEE1588-2008 standard when it > comes to processing of the transport specific field in UDP transport. > > The Annex D.4 of the standard says "bit 1-3, reserved, The bit shall be > transmitted as zero and ignored by the receiver". > Linuxptp does not ignore bits 1-3, it requires them to be identical to the > configured value. > > Why this incompatibility? This is one of a few requirements that is illogical, pointless, and just plain wrong. Probably some vendor with a legacy, non-fixable HW got this text in, but only because the vendor sat on the committee. I can't think of any valid technical reason to ignore these bits. Having said that, do you actually have some equipment that depends on this behavior? Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
