linuxptp-users

[Linuxptp-users] Need offset instead of rms

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

Hi Friends,

I need some important help from you. I am unable to get offset at higher frequencies of sync packets (logSyncInterval -9 resulting in 512 packets per second). Only rms value is reported. I rather want offset values for understanding the behaviour of the system. Could you help me out?

Rms values donot indicate signed trend of the offset. It just indicates unsigned offset with unsigned maximum deviation not helping the cause of understanding the offset correction trend fully (with the signs).

I have tried different options such as summary interval, verbose etc.

Summary_interval was already tried out. It did not help me. When I matched it with the packet frequency (say logSyncInterval -9, summary_interval -9), the whole ptp operation was breaking down. When the summary interval is less than the packet frequency/mean interval time of sync packets (say logSyncInterval -9, summary_interval -8/-7/-6 etc), the values were just rms.

Similarly verbose option also did not help me to get offset instead of rms value.

Appreciate your help in this regard.

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"


________________________________

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.

Re: [Linuxptp-users] Need offset instead of rms

[Richard C. <ric...@gm...>]

On Sat, Mar 14, 2015 at 06:54:13AM +0000, Chandra Mallela wrote:
> I need some important help from you. I am unable to get offset at higher frequencies of sync packets (logSyncInterval -9 resulting in 512 packets per second). Only rms value is reported. I rather want offset values for understanding the behaviour of the system. Could you help me out?

At that rate, a new Sync frame arrives about every 2
milliseconds. That does not leave much time for printing messages,
etc.  So, you might have to hack something yourself.

If you want to see *every* offset, then I would copy the values into a
circular buffer, and then read them out when you have enough data.

If you only want to occasionally monitor the offset, then you can poll
using the pmc client and the time_status_np request (no hacking
required).

HTH,
Richard

Re: [Linuxptp-users] Need offset instead of rms

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

Hi Richard,

Could yo suggest me any way that I can request this as an enhancement to the ptp4l? As you know, rms is not as useful as the real offset value fluctuating between some values.

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"


-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...]
Sent: Saturday, March 14, 2015 10:28 PM
To: Chandra Mallela
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Need offset instead of rms

On Sat, Mar 14, 2015 at 06:54:13AM +0000, Chandra Mallela wrote:
> I need some important help from you. I am unable to get offset at higher frequencies of sync packets (logSyncInterval -9 resulting in 512 packets per second). Only rms value is reported. I rather want offset values for understanding the behaviour of the system. Could you help me out?

At that rate, a new Sync frame arrives about every 2 milliseconds. That does not leave much time for printing messages, etc.  So, you might have to hack something yourself.

If you want to see *every* offset, then I would copy the values into a circular buffer, and then read them out when you have enough data.

If you only want to occasionally monitor the offset, then you can poll using the pmc client and the time_status_np request (no hacking required).

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.