Re: [Linuxptp-users] logAnnounceInterval Vs announceReceiptTimeout

[Chandra M. <sma...@al...>]

Hi Richard,

I think the following fell through cracks. My main intention is to understand the usage of the options ' logAnnounceInterval' & 'announceReceiptTimeout'. Could you throw some light on them? Do you have any link that elucidates the relation between their usage and the PTP profiles?

My understanding is that logAnnounceInterval (default 1 in every two seconds) is to be set up at the master and announceReceiptTimeout (default 3 messages before the last message reception) to be at the slave. Am I right?

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"


-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...]
Sent: Wednesday, March 18, 2015 1:57 AM
To: Chandra Mallela
Cc: lin...@li...
Subject: Re: [Linuxptp-users] logAnnounceInterval Vs announceReceiptTimeout

On Tue, Mar 17, 2015 at 05:21:47PM +0000, Chandra Mallela wrote:
> ***Ours is typical telecom-networking profile. Could you point me to any info link that defines the parameters for different profiles?

First of all, the telecom profile is unicast only.  We do not support unicast.

Secondly, from the telecom profile:

   A.3.4 REQUEST_UNICAST_TRANSMISSION TLV

   For requesting unicast Sync messages: The configurable range shall
   be one message every 16 seconds to 128 messages per second. No
   default rate is specified.

   For requesting unicast Delay_Resp messages: The configurable range
   shall be one message every 16 seconds to 128 messages per
   second. No default rate is specified.

   ITU-T G.8265.1  page 20

So, your 512 figure is *way* out of spec.

> ***I understand the 1-step part. However, reducing DelayReq might not make sense. Average path delay should be at least half the rate of Sync packets to statistically arrive at better values of path delay. 1Hz seems quite low especially for telecom applications.

If the path is not changing, then it does not make sense to measure it so often.  I would expect a telecom network to be engineered to have fixed delays.

> I will google about SO_SELECT_ERR_QUEUE. However, if you have any good link, please let me know.

This means using Linux kernel version 3.10 or newer.

Thanks,
Richard

________________________________

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.