On Thu, Dec 07, 2017 at 12:58:16PM +, Rommel, Albrecht wrote:
> Ideally, the UDS port meets the requirements of a "virtual PTP port" as
> defined in ITU-T G.8275.
> A virtual PTP port supports all attributes as normally transported
> in Announce messages or general PTP headers, except that
On Thu, Dec 07, 2017 at 10:13:07AM +0100, Miroslav Lichvar wrote:
> The trouble is that forwarding() is called twice from
> clock_forward_mgmt_msg(), once with the source port and then with the
> destination port. So, if it returned 0 for p == uds->port and action
> == REQUEST, requests from pmc
> -Original Message-
> From: Frantisek Rysanek [mailto:frantisek.rysa...@post.cz]
> Sent: Thursday, December 07, 2017 12:41 PM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] Despite the patch, "timed out while polling for
> tx
> timestamp" keeps happening
>
>
On 7 Dec 2017 at 18:47, Keller, Jacob E wrote:
> > => the Intel NIC hardware is possibly sensitive to "irrelevant"
> > contents in the traffic. I can come up with the following candidate
> > culprits/theories:
> > - absence of the VLAN tag
> > - correction values of 10-20 ms
> > - other mcast
> -Original Message-
> From: Frantisek Rysanek [mailto:frantisek.rysa...@post.cz]
> Sent: Thursday, December 07, 2017 8:28 AM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] Despite the patch, "timed out while polling for
> tx
> timestamp" keeps happening
>
> =>
Note: I'm forwarding this message with PNG attachments removed,
as I got politely and deservedly reminded that big attachments are a
no-no in a mailing list. Here goes the message:
> > The "correction" field inserted by the RuggedCom switch contains
> > values between 10 and 20 million raw
Hi all,
Ideally, the UDS port meets the requirements of a "virtual PTP port" as defined
in ITU-T G.8275.
A virtual PTP port supports all attributes as normally transported in Announce
messages or general PTP headers, except that the timing information comes via
technology proprietary methods,
On Wed, Dec 06, 2017 at 08:02:56AM -0800, Richard Cochran wrote:
> On Wed, Dec 06, 2017 at 02:44:23PM +0100, Miroslav Lichvar wrote:
> > A better option might be to forward only responses to the UDS port. We
> > don't expect a PTP clock to be listening there, right?
>
> Right, but we should also
