Re: [Linuxptp-users] logAnnounceInterval Vs announceReceiptTimeout

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

Hi Richard,

Please find my answers/questions in line.

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 12:27 AM
To: Chandra Mallela
Cc: lin...@li...
Subject: Re: [Linuxptp-users] logAnnounceInterval Vs announceReceiptTimeout

On Tue, Mar 17, 2015 at 04:04:45PM +0000, Chandra Mallela wrote:
> *         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?

This is defined by the profile.  What profile are you using?

***Ours is typical telecom-networking profile. Could you point me to any info link that defines the parameters for different profiles?

> *         I see more of these erros when I increase the packet frequency for Sync and DelayReq (say 512 packets per second). Are there any optimal values for the above for such high packet frequencies?
>
> *         Message_interval option also seems to play a role in addition to the increased packet frequency. If I reduce the message_interval to a very less value such as -9 (i.,e., increase the message frequency), the errors due to announce message timeouts seem to increase. Is it expected? Are the optimal values for 'logAnnounceInterval & announceReceiptTimeout' helpful in this case?

There is no "Message_interval" option.
***Sorry. I have used summary_interval option at -8 or -9 to understand the time between path delay calculations. I have seen sync faults at these high summary rates.

> Please share your experience with these options.

You are running an extremely short Sync period.  You can expect packet loss and related problems.  There is no silver bullet to help you here.

If I were going to attempt 512 Syncs per second, then I would:

- use one step (special HW required)
- reduce the DelayReq to something reasonable (like 1 Hz)
- make sure my kernel has SO_SELECT_ERR_QUEUE

***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.

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

BTW 512 sync is not that high rate at all unless it is coming from the stack as a limitation.

HTH,
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.