[Linuxptp-users] PTP_TIMESCALE flag query

[Rohit Borse]

Hi Team,


I am using linuxptp-1.3 stack for our eavb stack. I have one query with respect to PTP_TIMESCALE flag bit in linuxptp source code.


In port.c file port_tx_announce() function, flagField[1] byte which contains timeflag byte is added in message header and message is ready to be sent on port.


But for other messages like sync, followup, pdelay_resp and pdelay_resp_fup flagField[1] byte is not set.

Is this expected behavior. We need to send flagField[1] to other messages also.

Can we modify the same for sync,followup message.


Thanks and Regards,

Rohit Borse

This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.

[Ledda William EXT]

Because It is implemented according to the IEEE 1588 standard. It is the GMC that set this bit in the ANNOUNCE message. This information is then available through the Time Properties Data Set of the clock. The question is... why do you need it also for Sync and Follow Up messages?

Regards

William


[iterlogo]<http://www.iter.org/>
William LEDDA
External Contractor
CODAC Section

ITER Organization, Building 72/4115, SCOD, Control System Division
Route de Vinon-sur-Verdon - CS 90 046 - 13067 St Paul Lez Durance Cedex - France
Phone: [phone]
Get the latest ITER news on http://www.iter.org/whatsnew
From: Rohit Borse [mailto:***@kpit.com]
Sent: 30 March 2016 06:40
To: linuxptp-***@lists.sourceforge.net
Subject: [Linuxptp-users] PTP_TIMESCALE flag query


Hi Team,



I am using linuxptp-1.3 stack for our eavb stack. I have one query with respect to PTP_TIMESCALE flag bit in linuxptp source code.



In port.c file port_tx_announce() function, flagField[1] byte which contains timeflag byte is added in message header and message is ready to be sent on port.



But for other messages like sync, followup, pdelay_resp and pdelay_resp_fup flagField[1] byte is not set.

Is this expected behavior. We need to send flagField[1] to other messages also.

Can we modify the same for sync,followup message.



Thanks and Regards,

Rohit Borse
This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.

[Richard Cochran]

Post by Ledda William EXT
Because It is implemented according to the IEEE 1588 standard. It is
the GMC that set this bit in the ANNOUNCE message. This information
is then available through the Time Properties Data Set of the
clock. The question is... why do you need it also for Sync and
Follow Up messages?

Yes, for 1588, that bit is only set for Announce messages.
For AVB, the bit is supposed to be ignored by the receivers.

Table 10-6 - Values of flag bits

Octet Bit Message Types Name Value
1 3 All ptpTimescale Reserved as TRUE,
ignored on reception

- IEEE 802.1AS-2011, page 89

Since the bit must be ignored, we simply send according to 1588,
knowing that any correct AVB implementation must ignore the bit.

The statement "Reserved as TRUE" is quite strange. Normally, reserved
bits are sent on the wire cleared. I understand this statement to
mean, that the *logical* value for AVB is always TRUE, even though the
on the wire value may be zero. Otherwise, the restriction "ignored on
reception" does not make any sense.

Thanks,
Richard