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
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
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
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
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
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
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
> 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
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
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
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
11 matches
Mail list logo
