On Fri, Nov 17, 2023 at 08:27:43PM -0800, Richard Cochran wrote:
> How does this requirement improve synchronization?
>
> What benefit does it bring to users of the PTP?
rhetorical questions :^(
___
Linuxptp-devel mailing list
On Fri, Nov 17, 2023 at 01:51:18PM +0100, Andrew Zaborowski wrote:
> It is exposed on the wire in the Pdelay messages. Compliance tests
> look at this. They also simulate a few hypothetical scenarios like a
> domain 0 PTP port trying to communicate with a CMLDS link port since
> 1588 talks
On Fri, 17 Nov 2023 at 05:50, Richard Cochran wrote:
> On Fri, Nov 17, 2023 at 01:41:19AM +0100, Andrew Zaborowski wrote:
> > Do you want to require the user to enforce that the port numbering is
> > the same between the ptp4l processes?
>
> No.
(I meant: do you want to require that the user
On Fri, Nov 17, 2023 at 01:41:19AM +0100, Andrew Zaborowski wrote:
> On Thu, 16 Nov 2023 at 23:46, Richard Cochran
> wrote:
> > No, I mean the PTP port number. These are taken from the order of the
> > interfaces on the command line and in the configuration file.
>
> Won't this be the same as
On Thu, 16 Nov 2023 at 23:46, Richard Cochran wrote:
> On Thu, Nov 16, 2023 at 11:11:50PM +0100, Andrew Zaborowski wrote:
> > The two timestamps are passed to clock_peer_delay() by the receiving
> > port and stored in c->tsproc. Then they're accessed by
> > get_raw_delay() which is used in the
On Thu, Nov 16, 2023 at 11:11:50PM +0100, Andrew Zaborowski wrote:
> The two timestamps are passed to clock_peer_delay() by the receiving
> port and stored in c->tsproc. Then they're accessed by
> get_raw_delay() which is used in the filter logic. I'm not sure how
> much value that has, we can
On Thu, 16 Nov 2023 at 05:27, Richard Cochran wrote:
> On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> > @@ -1129,6 +1130,27 @@ static int port_management_fill_response(struct port
> > *target,
> > memcpy(pwr, >pwr, sizeof(*pwr));
> > datalen =
On Wed, Nov 15, 2023 at 09:45:52PM -0800, Richard Cochran wrote:
> On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
>
> > @@ -473,6 +476,14 @@ struct msg_interface_rate_tlv {
> > UInteger16numberOfBitsAfterTimestamp;
> > } PACKED;
> >
> > +struct cmlds_info_np {
> > +
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -473,6 +476,14 @@ struct msg_interface_rate_tlv {
> UInteger16numberOfBitsAfterTimestamp;
> } PACKED;
>
> +struct cmlds_info_np {
> + Integer8 serviceMeasurementValid;
> + TimeInterval meanLinkDelay;
>
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -490,6 +491,15 @@ static int mgt_post_recv(struct management_tlv *m,
> uint16_t data_len,
> if (data_len != 0)
> goto bad_length;
> break;
> + case MID_CMLDS_INFO_NP:
> +
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -651,6 +652,18 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
> fprintf(fp, "LOG_MIN_PDELAY_REQ_INTERVAL "
> IFMT "logMinPdelayReqInterval %hhd", mtd->val);
> break;
>
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -473,6 +476,14 @@ struct msg_interface_rate_tlv {
> UInteger16numberOfBitsAfterTimestamp;
> } PACKED;
>
> +struct cmlds_info_np {
> + Integer8 serviceMeasurementValid;
> + TimeInterval meanLinkDelay;
>
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -1129,6 +1130,27 @@ static int port_management_fill_response(struct port
> *target,
> memcpy(pwr, >pwr, sizeof(*pwr));
> datalen = sizeof(*pwr);
> break;
> + case MID_CMLDS_INFO_NP:
Thanks for the reply.
Please add the explanation to the commit and to the structure.
Personally, I do not have an opinion, yet I did not participate in the IEEE
1558 committee.
Erez
On Tue, 16 May 2023 at 23:43, Kishen Maloor wrote:
> On 5/16/23 3:56 AM, Erez wrote:
> > On Tue, 16 May 2023
On 5/16/23 3:56 AM, Erez wrote:
> On Tue, 16 May 2023 at 00:29, Kishen Maloor wrote:
>
>> In a setup with multiple gPTP domains, the Common Mean Link Delay Service
>> (CMLDS) (IEEE 1588/16.6.3) performs link delay measurements in a single
>> domain and must (somehow) convey those to other
On Tue, 16 May 2023 at 00:29, Kishen Maloor wrote:
> In a setup with multiple gPTP domains, the Common Mean Link Delay Service
> (CMLDS) (IEEE 1588/16.6.3) performs link delay measurements in a single
> domain and must (somehow) convey those to other domains. IEEE 1588 does not
> specify this
In a setup with multiple gPTP domains, the Common Mean Link Delay Service
(CMLDS) (IEEE 1588/16.6.3) performs link delay measurements in a single
domain and must (somehow) convey those to other domains. IEEE 1588 does not
specify this interface and flags it as an implementation
detail (IEEE
17 matches
Mail list logo
