Re: [Linuxptp-devel] connecting two devices clock via GPIO
Just for the record: On 13 Feb 2018 at 8:05, Richard Cochran wrote: > > The reason for this is that that the i210 latches the time on both > rising and falling edges of the input signal. You can't program it > for rising edge only, for example. > I've checked the datasheet again and you're right, no way to set the polarity of the SDP pins in general, and no way to trigger an auxiliary timestamp on a rising or falling edge only. Ahh well. There are several specific functions of the chip where you can configure the active polarity, but this is not the case with the SDP I/O in general. So I'm gonna have to do this in software. Well at least I can make it polarity-agnostic :-) Frank -- 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] Handling missing hardware timestamps on embedded systems
On Tue, Feb 13, 2018 at 07:01:22PM +0100, Oliver Westermann wrote: > The issue is that the PHY only has two slots for timestamps, one for > outgoing packages and one for incoming packages. If the device in question > is a ptp master and has multiple slave, it sometimes happen that both > DELAY_REQ packages come in short succession, which results in the PHY > driver/interrupt handler being to slow to get all timestamps. This is actually a bug in your driver. If an incoming delay request misses a time stamp, no fault is generated. The *transmit* time stamp is still available, but your driver fails to fetch it. > From a PTP perspective this is not a big issue: A single missing delay > measurement doesn't break a clock. Right. > But PTP4L threats this as a critical error, printing > "timed out while polling for tx timestamp", This should not happen. You should fix your driver so that it always fetches the Tx time stamp after sending a marked packet. No interrupt is necessary. 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] Handling missing hardware timestamps on embedded systems
On Tue, Feb 13, 2018 at 07:01:22PM +0100, Oliver Westermann wrote: > Is there a reason not to do this or a better idea to use linuxptp on > systems with similar hardware constraints? I have had such HW, and I usually just set "fault_reset_interval ASAP" in the configuration. > Are there design considerations within linuxptp that I should know of > before implementing and submitting such a fix? The vast majority of HW is not limited in this respect, and there are no mainline drivers that support such HW. My feeling is that the linuxptp stack shouldn't be filled with special cases just for buggy or deficient HW designs. 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 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
[Linuxptp-devel] Handling missing hardware timestamps on embedded systems
I've a setup of multiple devices with a ARM CPU using a Marvell PHY with hardware timestamping capabilitys for networking. These Marvell PHYs analyse incoming and outgoing packages for PTP packages, saves a hardware timestamp and issues a interrupt. The PHY driver catches the interrupt, gets the timestamp and places it in a queue for ptp4l to get it via sk_receive(). The issue is that the PHY only has two slots for timestamps, one for outgoing packages and one for incoming packages. If the device in question is a ptp master and has multiple slave, it sometimes happen that both DELAY_REQ packages come in short succession, which results in the PHY driver/interrupt handler being to slow to get all timestamps. >From a PTP perspective this is not a big issue: A single missing delay measurement doesn't break a clock. But PTP4L threats this as a critical error, printing "timed out while polling for tx timestamp", "increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug" and going into the "PS_FAULTY" state. My first idea for the fix is to add a EV_NONCRIT_FAULT_DETECTED event, fired on such occasions. This event would be counted in the fsm, reset by EV_NONE and resulting in a PS_FAULTY after x appearances. Is there a reason not to do this or a better idea to use linuxptp on systems with similar hardware constraints? Are there design considerations within linuxptp that I should know of before implementing and submitting such a fix? -- 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] connecting two devices clock via GPIO
Dear everyone (maybe Mr. Cochran especially), my setup with external PPS has started showing basic signs of life. Interestingly, my two i210 cards seem to be throwing an event on both PPS edges, rising and falling :-) They're spaced 200 ms apart. And, somehow the system converges to the "wrong" edge, which probably is not a problem, and which I could readily correct by flipping polarity at the Meinberg clock, but for other reasons (a 25MHz synth that I'm working on) I would prefer to reconfigure the i210 accordingly. I seem to recall notes from the i210 chip datasheet that the polarity can be adjusted. If you can give me a shortcut on how to do this in the code of your example proggie, it would save me some more time... Maybe I should just check the tools from kernel.org that you've mentioned in your other message. Or back to devmem2. I'm attaching a crude beta of my servo proggie, based on Mr. Cochran's example. See its output below. BTW: Yippeee!! :-D Frank Rysanek i210_ext_pps[1477.035]: ptp4 offset -3 s2 freq -22542 i210_ext_pps[1477.835]: ptp1 offset -200015399 s2 freq -10 i210_ext_pps[1477.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1478.035]: ptp1 offset -3 s2 freq -3720 i210_ext_pps[1478.035]: ptp4 offset 5 s2 freq -22534 i210_ext_pps[1478.835]: ptp1 offset -200015391 s2 freq -10 i210_ext_pps[1478.835]: ptp4 offset -200012381 s2 freq -10 i210_ext_pps[1479.035]: ptp1 offset -4 s2 freq -3722 i210_ext_pps[1479.035]: ptp4 offset -1 s2 freq -22539 i210_ext_pps[1479.835]: ptp1 offset -200015390 s2 freq -10 i210_ext_pps[1479.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1480.035]: ptp1 offset -2 s2 freq -3721 i210_ext_pps[1480.035]: ptp4 offset -3 s2 freq -22541 i210_ext_pps[1480.835]: ptp1 offset -200015389 s2 freq -10 i210_ext_pps[1480.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1481.035]: ptp1 offset 6 s2 freq -3714 i210_ext_pps[1481.035]: ptp4 offset 5 s2 freq -22534 i210_ext_pps[1481.835]: ptp1 offset -200015394 s2 freq -10 i210_ext_pps[1481.835]: ptp4 offset -200012382 s2 freq -10 i210_ext_pps[1482.035]: ptp1 offset 1 s2 freq -3717 i210_ext_pps[1482.035]: ptp4 offset -1 s2 freq -22539 i210_ext_pps[1482.835]: ptp1 offset -200015397 s2 freq -10 i210_ext_pps[1482.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1483.035]: ptp1 offset -2 s2 freq -3720 i210_ext_pps[1483.035]: ptp4 offset -3 s2 freq -22541 i210_ext_pps[1483.835]: ptp1 offset -200015398 s2 freq -10 i210_ext_pps[1483.835]: ptp4 offset -200012385 s2 freq -10 i210_ext_pps[1484.035]: ptp1 offset -2 s2 freq -3720 i210_ext_pps[1484.035]: ptp4 offset -4 s2 freq -22543 i210_ext_pps[1484.835]: ptp1 offset -200015390 s2 freq -10 i210_ext_pps[1484.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1485.035]: ptp1 offset -3 s2 freq -3722 i210_ext_pps[1485.035]: ptp4 offset 5 s2 freq -22535 i210_ext_pps[1485.835]: ptp1 offset -200015397 s2 freq -10 i210_ext_pps[1485.835]: ptp4 offset -200012381 s2 freq -10 i210_ext_pps[1486.035]: ptp1 offset -2 s2 freq -3722 i210_ext_pps[1486.035]: ptp4 offset 0 s2 freq -22539 i210_ext_pps[1486.835]: ptp1 offset -200015396 s2 freq -10 i210_ext_pps[1486.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1487.035]: ptp1 offset -1 s2 freq -3721 i210_ext_pps[1487.035]: ptp4 offset -3 s2 freq -22542 On 13 Feb 2018 at 11:45, linuxptp-devel@lists.sourcefo wrote: > > Dear Mr. Cochran, > > I've finally got back to my plan (ext.PPS to 2-4 i210 chips for > tcpdump timestamping) and I'm reviewing your proggie. > Yes the code is pretty self-explanatory :-) and packed with gems. > > If I understand correctly, setting up the SDP0 GPIO for external > PPS input (which takes two function calls in your program) > results in the respective phc throwing "events" on every PPS > leading edge - passing them to the user space proggie that > keeps waiting in a poll(), and keeps processing the events > thus received. The event essentially contains a precise timestamp (as > per the i210's timebase) of the PPS leading edge. > And, the "servo" is not autonomous (in hardware or in kernel), it is > in fact implemented by the synbc program, which has to explicitly > instruct the PHC to adjust stepwise or frequency-wise accordingly... > the required "ppb" value actually comes from the servo->sample() > PTP4l library function... > > Interestingly to me, your program seems to instruct the "slave PHC" > (PPS master) to send the pulses every 2 seconds, rather than every 1 > second... am I reading this correctly? > > int index = 0, perout = 20; > > I understand that the PHC's work in wall time, > and I should be able to prime them with the system time, > once on program startup (as I won't have a PPS
Re: [Linuxptp-devel] connecting two devices clock via GPIO
Ohh... excellent, that answers a question from my next message :-) In fact I don't mind if I see the falling edges as well - only I should detect them somehow, by timing calculation if there's no other way, and ignore them in the servo policing loop. As my application is tcpdump timestamping (rather than serving ptp), I'd prefer to use UTC for the timestamps. Oh wait. I'll be timestamping PTP traffic. So I'd better use TAI to have a common timescale inside the packets captured and in the timestamps :-) Allright, I'll probably just subtract a few seconds when setting the PHC's. Frank On 13 Feb 2018 at 8:05, Richard Cochran wrote: > On Tue, Feb 13, 2018 at 11:45:37AM +0100, Frantisek Rysanek wrote: > > Interestingly to me, your program seems to instruct the "slave PHC" > > (PPS master) to send the pulses every 2 seconds, rather than every 1 > > second... am I reading this correctly? > > > > int index = 0, perout = 20; > > The reason for this is that that the i210 latches the time on both > rising and falling edges of the input signal. You can't program it > for rising edge only, for example. > > > I understand that the PHC's work in wall time, > > and I should be able to prime them with the system time, > > once on program startup (as I won't have a PPS master / PTP slave PHC > > in my system). It's just a matter of asking clock_gettime() of the > > system timebase, rather than a particular PHC, in your function > > synbc_settime(). > > Normally the PHC time scale is TAI, which is offset from the system's > UTC by an integer number of seconds. You *can* use whatever time > scale you want, but PTP nodes will expect TAI by default. > > HTH, > 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] connecting two devices clock via GPIO
On Tue, Feb 13, 2018 at 11:45:37AM +0100, Frantisek Rysanek wrote: > Interestingly to me, your program seems to instruct the "slave PHC" > (PPS master) to send the pulses every 2 seconds, rather than every 1 > second... am I reading this correctly? > > int index = 0, perout = 20; The reason for this is that that the i210 latches the time on both rising and falling edges of the input signal. You can't program it for rising edge only, for example. > I understand that the PHC's work in wall time, > and I should be able to prime them with the system time, > once on program startup (as I won't have a PPS master / PTP slave PHC > in my system). It's just a matter of asking clock_gettime() of the > system timebase, rather than a particular PHC, in your function > synbc_settime(). Normally the PHC time scale is TAI, which is offset from the system's UTC by an integer number of seconds. You *can* use whatever time scale you want, but PTP nodes will expect TAI by default. HTH, 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] connecting two devices clock via GPIO
Dear Mr. Cochran,
I've finally got back to my plan (ext.PPS to 2-4 i210 chips for
tcpdump timestamping) and I'm reviewing your proggie.
Yes the code is pretty self-explanatory :-) and packed with gems.
If I understand correctly, setting up the SDP0 GPIO for external
PPS input (which takes two function calls in your program)
results in the respective phc throwing "events" on every PPS
leading edge - passing them to the user space proggie that
keeps waiting in a poll(), and keeps processing the events
thus received. The event essentially contains a precise timestamp (as
per the i210's timebase) of the PPS leading edge.
And, the "servo" is not autonomous (in hardware or in kernel), it is
in fact implemented by the synbc program, which has to explicitly
instruct the PHC to adjust stepwise or frequency-wise accordingly...
the required "ppb" value actually comes from the servo->sample()
PTP4l library function...
Interestingly to me, your program seems to instruct the "slave PHC"
(PPS master) to send the pulses every 2 seconds, rather than every 1
second... am I reading this correctly?
int index = 0, perout = 20;
I understand that the PHC's work in wall time,
and I should be able to prime them with the system time,
once on program startup (as I won't have a PPS master / PTP slave PHC
in my system). It's just a matter of asking clock_gettime() of the
system timebase, rather than a particular PHC, in your function
synbc_settime().
Interesting stuff. Thank you :-)
Frank Rysanek
On 8 Dec 2017 at 15:59, Richard Cochran wrote:
>
> On Fri, Dec 08, 2017 at 11:09:40PM +, Keller, Jacob E wrote:
> > I'm thinking the best way is to use the external timestamp events setup,
> > and then plug that in as the pps source into phc2sys?
> >
> > Does this make any sense, or am I paddling up the wrong creek?
>
> So you *could* extend phc2sys, but that program is complex enough as
> is. I have made thoughts about a successor to phc2sys that would
> handle gpio based measurements, including setting the pin functions
> using the PHC ioctls.
>
> But for now, I would just write a simple program for your specific
> setup. Below is an example for using three i210 cards whose first SDP
> are connected. The first card is hard coded as the PPS producer. In
> a more realistic JBOD setting, you would want to switch the PPS
> producer to be the PHC of the port that takes on the SLAVE role.
>
> HTH,
> Richard
>
> --->8---
> /**
> * @file synbc.c
> * @brief Synchronize the ports of a JBOD Boundary Clock.
> * @note Copyright (C) 2015 Richard Cochran
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> * You should have received a copy of the GNU General Public License along
> * with this program; if not, write to the Free Software Foundation, Inc.,
> * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> */
> #include
> #include
> #include
> #include
> #include
>
> #include
>
> #include "clockadj.h"
> #include "config.h"
> #include "phc.h"
> #include "print.h"
> #include "servo.h"
> #include "util.h"
>
> #define N_PHC 3
>
> static int synbc_extts(int fd, int enable)
> {
> struct ptp_extts_request extts_request;
> int index = 0;
> memset(&extts_request, 0, sizeof(extts_request));
> extts_request.index = index;
> extts_request.flags = enable ? PTP_ENABLE_FEATURE : 0;
> if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) {
> pr_err("PTP_EXTTS_REQUEST");
> return -1;
> }
> pr_info("external time stamp request okay");
> return 0;
> }
>
> static int synbc_pin_input(int fd)
> {
> struct ptp_pin_desc desc;
> int index = 0, pin_index = 0;
>
> memset(&desc, 0, sizeof(desc));
> desc.index = pin_index;
> desc.func = PTP_PF_EXTTS;
> desc.chan = index;
> if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) {
> pr_err("PTP_PIN_SETFUNC");
> return -1;
> }
> pr_info("set pin function okay");
> return 0;
> }
>
> static int synbc_pin_output(int fd)
> {
> struct ptp_pin_desc desc;
> int index = 0, pin_index = 0;
>
> memset(&desc, 0, sizeof(desc));
> desc.index = pin_index;
> desc.func = PTP_PF_PEROUT;
> desc.chan = index;
> if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) {
> pr_err("PTP_PIN_SETFUNC");
> return -1;
> }
> pr_info("set pin function okay");
> return 0;
> }
>
> static int synbc_pps_out
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
