Another followup with shower-thoughts:
2018-03-06 18:53 GMT+01:00 Richard Cochran <richardcoch...@gmail.com>:
> Using UDS is not part of 1588. The UDS client has no 1588 port ID at
> all. Therefore, we set the source port ID to zero.
Suggestion:
Set the clockIdentity as usual (so like for ethernet use), but set the
portNumber to Zero (Standard V2, 7.5.2.3 allows this: "The all-zero
portNumber may also be used to represent [...] an uninitialized or invalid
portNumber value."
This will create answers with properly set TargetIdentitys and allow the
easy filtering.
Thanks, Olli
2018-03-07 9:00 GMT+01:00 Oliver Westermann <owesterm...@gmail.com>:
> First: Thanks for the extensive responses, not exactly common on some
> mailing lists :)
>
> 2018-03-06 18:53 GMT+01:00 Richard Cochran <richardcoch...@gmail.com>:
> > It really isn't rocket science. Here is an (untested) awk script that
> > accepts responses from exactly one port:
>
> My issue is a bit different from the script solution (and I'm not 100%
> sure the script is robust to my issue):
> I currently fork and execv pmc once, creating pipes for stdin, out and
> err. On a regular interval, I send 'GET WHATEVER_DATA_SET' to stdin and
> wait for stdout
> to respond (wait for '{Identity} RESPONSE MANAGEMENT WHATEVER_DATA_SET').
> But if the single device only querys every 5 seconds and another pmc on
> the net sends GET requests with boundary hops > 0, the stdout will deliver
> a lot of messages that might not contain what I want.
> If I always take the first correct response - Identity pair, I will soon
> only read outdated data.
> Considering what mess we created here in the network by just having 5-10
> devices missusing pmc, stdout was a constant stream of unwanted data.
>
> > Using UDS is not part of 1588. The UDS client has no 1588 port ID at
> > all. Therefore, we set the source port ID to zero.
> Understood, expected something like this.
>
> > I don't really see the need, as you can filter the pmc output fairly
> > easily.
> See above, I have to disagree on the "easy" part.
>
>
> > A fully featured PTP network monitoring program is really a
> > new feature for future development.
> More of a "local only" option for pmc.
>
> > I don't think your network setup is very common. Normally, you would
> > have just one PC sending monitoring requests into the network, not
> > dozens.
> Normally -> You know these "Users", don't you? ;)
>
> > > b) is there a reason not
> > > to use IP_MULTICAST_LOOP on the IPv4 port for pmc?
> > Actually, that won't work the way that you would want it to. The
> > transmitted frames from pmc will be looped back, but the multicast
> > responses from ptp4l will not.
> True :/
>
> Best regards, Olli
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
