Re: [Linuxptp-devel] Machine Readable Output

2020-10-27 Thread Matthew P. Grosvenor 
Thanks for this. I just ended up writing a log parser for the ptp4l output 
which did the job as well. The current output contains exactly the outputs that 
I wanted/needed. 

The reason for asking here was to see if there was more value that I could add 
by making this sort of thing available to the community at large rather than 
just in my own personal project. 

Cheers,
Matt


> On 28 Oct 2020, at 07:04, Richard Cochran  wrote:
> 
> On Wed, Jul 22, 2020 at 06:16:01AM -0700, Richard Cochran wrote:
>> On Wed, Jul 22, 2020 at 02:14:48PM +1000, Luke Howard wrote:
>>> [resending from correct email]
>>> 
 The output of the pmc tool is still unstructured text. So to feed it into 
 a script I would still need to write an output parser of some sort and I 
 would have to guess that my parser covers all of the cases that the tool 
 might generate and I would have to assume that the output format doesn’t 
 change. This is what got me thinking about structuring the output format 
 somehow in a way that any tool could consume it. 
>>> 
>>> Perhaps in that case a structured text option to pmc(8) would be useful and 
>>> not too hard to add?
>> 
>> In contrast to the logging, I think the pmc output is already
>> structured and easy to parse.
> 
> Case in point:
> 
> - I wanted to add simple client monitoring to a deployment.
> 
> - Running pmc every second (or so) is really easy in systemd, and the
>  output is logged automatically, BUT
> 
> - the client's records are spread across multiple lines, and that is
>  not very convenient in the syslog.
> 
> - So, what do I do?  Invent a new logging interface?  Nah.
> 
> Something like this in python could emit json pretty easily, I would
> expect...
> 
> ---8<--- pmc-monitor.service --
> [Unit]
> Description=PTP Logging Service
> After=network.target
> 
> [Service]
> Type=exec
> ExecStart=/usr/local/bin/pmc-monitor.sh
> Restart=always
> 
> [Install]
> WantedBy=multi-user.target
> 
> ---8<--- pmc-monitor.sh --
> #!/bin/sh
> 
> while [ 1 ]; do
>   pmc -u 'get current' | awk -e '
> function print_last_record() {
>   if (!last) {
>   return;
>   }
>   gsub("\t", " ", last);
>   print last;
> }
> {
>   if ($1 == "sending:") {
>   next;
>   }
>   if ($4 == "RESPONSE" && $5 == "MANAGEMENT") {
>   print_last_record();
>   last = $1 " " $6;
>   next;
>   }
>   last = last $0;
> }
> END {
>   print_last_record();
> }
> '
>   sleep 1
> done



___
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

2020-10-27 Thread Jacob Keller 



On 10/27/2020 4:26 PM, 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?
> 
> For example, you would have to call eth0 the "server" and
> CLOCK_REALTIME the "client".
> 
> Thoughts?
> 
> Richard

For myself, I would be reasonably ok with this, but I do prefer the
source/sink terminology overall because it feels more accurate to this
relationship.

Thanks,
Jake


___
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

2020-10-27 Thread Richard Cochran 
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?

For example, you would have to call eth0 the "server" and
CLOCK_REALTIME the "client".

Thoughts?

Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/1] missing.h: uclic-ng has clock_nanosleep support since v1.0.31

2020-10-27 Thread Richard Cochran 
On Tue, Sep 29, 2020 at 08:58:26AM +0200, Heiko Thiery wrote:
> Due to uclic-ng supports clock_nanosleep without enabled threads we do
> not need to provide clock_nanosleep in that case.
> 
> Cc: Richard Cochran 
> Signed-off-by: Heiko Thiery 

Applied.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Machine Readable Output

2020-10-27 Thread Richard Cochran 
On Wed, Jul 22, 2020 at 06:16:01AM -0700, Richard Cochran wrote:
> On Wed, Jul 22, 2020 at 02:14:48PM +1000, Luke Howard wrote:
> > [resending from correct email]
> > 
> > > The output of the pmc tool is still unstructured text. So to feed it into 
> > > a script I would still need to write an output parser of some sort and I 
> > > would have to guess that my parser covers all of the cases that the tool 
> > > might generate and I would have to assume that the output format doesn’t 
> > > change. This is what got me thinking about structuring the output format 
> > > somehow in a way that any tool could consume it. 
> > 
> > Perhaps in that case a structured text option to pmc(8) would be useful and 
> > not too hard to add?
> 
> In contrast to the logging, I think the pmc output is already
> structured and easy to parse.

Case in point:

- I wanted to add simple client monitoring to a deployment.

- Running pmc every second (or so) is really easy in systemd, and the
  output is logged automatically, BUT

- the client's records are spread across multiple lines, and that is
  not very convenient in the syslog.

- So, what do I do?  Invent a new logging interface?  Nah.

Something like this in python could emit json pretty easily, I would
expect...

---8<--- pmc-monitor.service --
[Unit]
Description=PTP Logging Service
After=network.target

[Service]
Type=exec
ExecStart=/usr/local/bin/pmc-monitor.sh
Restart=always

[Install]
WantedBy=multi-user.target

---8<--- pmc-monitor.sh --
#!/bin/sh

while [ 1 ]; do
pmc -u 'get current' | awk -e '
function print_last_record() {
if (!last) {
return;
}
gsub("\t", " ", last);
print last;
}
{
if ($1 == "sending:") {
next;
}
if ($4 == "RESPONSE" && $5 == "MANAGEMENT") {
print_last_record();
last = $1 " " $6;
next;
}
last = last $0;
}
END {
print_last_record();
}
'
sleep 1
done


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support

2020-10-27 Thread Richard Cochran 
On Tue, Oct 27, 2020 at 08:03:34PM +0100, Luigi 'Comio' Mantellini wrote:
> Dear All,
> 
> I'm trying to understand if I can support the G.8271 Annex A.1.3 directly
> via LinuxPTP.

My copy doesn't have any "Annex" at all, but only Appendixes.

   ITU-T G.8271.1/Y.1366.1 (08/2013)

No idea what you are asking about.

Sorry,

Richard


___
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

2020-10-27 Thread Richard Cochran 
On Wed, Oct 28, 2020 at 06:27:42AM +1100, mgrosve...@gmail.com wrote:

> Furthermore, some switches (Eg Arista and and Cisco) use the CRC to
> convey timestamps in packets. It would be absolutely necessary to be
> able to see the “CRC” for this this use case, on the same interface
> that PTP traffic traverses, even if PTP traffic itself is
> unaffected.

But why would ptp4l need to see that "timestamp" ?

It doesn't use it at all.

What a switch does internally is its own business.

However, the end points need to receiver a proper Ethnernet frame with
a correct checksum.

Thanks,
Richard


___
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

2020-10-27 Thread mgrosvenor 

> AFAICT, receiving the FCS is totally useless.  After all, it must be
> correct, otherwise the MAC would drop the frame.

I don’t know the context of this argument, but what I can say for a fact is 
that this is not not a true statement. A NIC is free to decide to filter out 
the CRC if it wants, or to forward it if it wants. There are lots of good 
reasons to do both. There’s no part of the Linux TCP/IP stack that either 
explicitly requires or denies a NIC from doing this. And the Linux TCP/IP stack 
works correctly in either case. 

Again I don’t know the context. But If PTP4L is making some assumption that a 
raw Ethernet does not include a CRC, that’s a broken assumption. 

Furthermore, some switches (Eg Arista and and Cisco) use the CRC to convey 
timestamps in packets. It would be absolutely necessary to be able to see the 
“CRC” for this this use case, on the same interface that PTP traffic traverses, 
even if PTP traffic itself is unaffected. 

---
Sent from my phone, sorry about the typos. 

> On 28 Oct 2020, at 03:58, Richard Cochran  wrote:
> 
> 
> AFAICT, receiving the FCS is totally useless.  After all, it must be
> correct, otherwise the MAC would drop the frame.


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support

2020-10-27 Thread Luigi 'Comio' Mantellini 
Dear All,

I'm trying to understand if I can support the G.8271 Annex A.1.3 directly
via LinuxPTP.
Is there any support in place?
I noticed ts2phc for NMEA messages, but nothing for LinuxPTP. From my
understanding, Annex A.1.3 should be supported directly by PTP instance in
order to move meta information between the TOD interface and the Eth
interfaces.

Alternatively do you have any suggestion to support the given scenario?

Thanks a lot for my stupid questions.

luigi
-- 
*Luigi 'Comio' Mantellini*
My Professional Profile 

*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
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

2020-10-27 Thread Richard Cochran 
On Tue, Oct 27, 2020 at 11:12:54AM +, Matt Sanders (matt8) wrote:
> and uses the mechanisms that the standard implies to resolve the 
> problem.

I disagree with your intrepretation of the what the standard "implies".

> What’s
> your objection to going down this path?

Check the list archives.  You will find people trying to justify
letting broken hardware tag on any amount of random bytes onto PTP
frames.

You haven't even explained WHY your change is so important.

What is the use case?

AFAICT, receiving the FCS is totally useless.  After all, it must be
correct, otherwise the MAC would drop the frame.

Thanks,
Richard







___
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

2020-10-27 Thread Matt Sanders (matt8) via Linuxptp-devel 

On 10/23/20 2:13 AM, Richard Cochran wrote:
 > On Thu, Oct 22, 2020 at 11:17:51AM +, Matt Sanders (matt8) via 
Linuxptp-devel wrote:
 >
 >> It is possible for 802.3 Ethernet adapters to be configured include 
the Ethernet
 >> CRC value in the raw frame which will be returned by the PF_PACKET / 
SOCK_RAW
 >> interface used by Linux PTP. This is configured on a per interface basis
 >> (e.g. ethtool -K eth1 rx-fcs on) and is independent of using Linux 
PTP on that
 >> interface (e.g. some other application may want or need this to be 
configured).
 >
 > If this configuration truly needs to be supported, then the code in
 > raw.c should handle the extraneous length before returning from
 > raw_recv().
 >

Yes, I had considered that. The trouble is, to support this in 
raw_recv() would
require some fairly nasty querying of the configured interface 
properties using
the ethtool interfaces. I’m sure this could be done, but it would more 
complex
and thus more brittle than the proposed fix. The proposed fix is simple, 
clean
and uses the mechanisms that the standard implies to resolve the 
problem. What’s
your objection to going down this path?

Regards,
Matt S.

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel