linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] Expected throughput of the ptp4l

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

Hi Miroslav & Richard,

Not sure whether I have understood your concern here.

High quality PLLs offer stepping in pico seconds.

512 sync packets are a reasonable rate for frequency corrections. In case of ToD, the fractional HW arithmetic (2^-16) can give you capability to achieve the highest accuracy possible, if the stack can supply such fine-grained values.

As for 'what is that supposed to achieve?', in ideal scenario, targeting 50pbb for CDMA is what I look at. I am further trying to analyze SyncE requirements from 1588 perspective, which seems too tough at this moment due to OS scheduling jitter itself.

Please correct me as appropriate and pour in your thoughts.

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"


-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...]
Sent: Wednesday, March 18, 2015 12:44 AM
To: Richard Cochran
Cc: Chandra Mallela; lin...@li...
Subject: Re: [Linuxptp-users] Expected throughput of the ptp4l

On Tue, Mar 17, 2015 at 05:32:38PM +0100, Richard Cochran wrote:
> On Tue, Mar 17, 2015 at 04:15:46PM +0000, Chandra Mallela wrote:
> > Could you elaborate your experience with the ptp4l performance?
>
> I never tried 512 Syncs per second, nor do I see any reason to run
> such a high rate.  What is that supposed to achieve?

I'm wondering that too. Even if we assume a very unstable clock, the clock resolution and jitter would have to be somewhere in low picoseconds to -9 provide any theoretical improvement over -8.

--
Miroslav Lichvar

________________________________

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

Re: [Linuxptp-users] Expected throughput of the ptp4l

[Miroslav L. <mli...@re...>]

On Tue, Mar 17, 2015 at 05:32:38PM +0100, Richard Cochran wrote:
> On Tue, Mar 17, 2015 at 04:15:46PM +0000, Chandra Mallela wrote:
> > Could you elaborate your experience with the ptp4l performance?
> 
> I never tried 512 Syncs per second, nor do I see any reason to run
> such a high rate.  What is that supposed to achieve?

I'm wondering that too. Even if we assume a very unstable clock, the
clock resolution and jitter would have to be somewhere in low
picoseconds to -9 provide any theoretical improvement over -8.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Expected throughput of the ptp4l

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

On Tue, Mar 17, 2015 at 04:15:46PM +0000, Chandra Mallela wrote:
> Could you elaborate your experience with the ptp4l performance?

I never tried 512 Syncs per second, nor do I see any reason to run
such a high rate.  What is that supposed to achieve?

In general, if you want to handle one event every 1.9 milliseconds,
then you must be running RT_PREEMPT with ptp4l at sufficiently high
priority.  Standard Linux will exhibit scheduling latencies well above
2 milliseconds.

Thanks,
Richard

Re: [Linuxptp-users] logAnnounceInterval Vs announceReceiptTimeout

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

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

HTH,
Richard

[Linuxptp-users] Expected throughput of the ptp4l

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

Hi Friends,

Do we have any performance numbers for the ptp4l stack performance on a 10Gbps link? When I increase the sync packet frequency to 512 and the DelayReq packet frequency to 512, I see many synchronization faults, meaning that the ptp4l runs for some time, faces synchronization faults, resumes the sync operation, faces the sync faults and resumes the operation showing a lot of instability in the overall ptp stack operation.

Is it due to the limitation from the stack performance as the HW supports a 10G link? The 512 packets per sync and 512 packet sets of {DelayReq, DelayResp} donot occupy even 1% of the 10Gbps bandwidth.

Could you elaborate your experience with the ptp4l performance?

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.

[Linuxptp-users] logAnnounceInterval Vs announceReceiptTimeout

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

Hi Friends,

While running the ptp4l, I observe the errors due to Announce message timeouts. Could you clarify the following?


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

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

Please share your experience with these options.

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] Port option: logMinDelayReqInterval

[Ledda W. E. <Wil...@it...>]

If you are able to take a look into the IEEE 1588 standards, see section 9.5.11 (Transmission of a Delay_req message) and in particular section 9.5.11.2 (Timing requirements). It states that:

The transmission of the Delay request message from a port SHALL be limited as follows:

- The initial may be transmitted when required
- Following messages in a way such that the mean interval, in seconds, is not less than the value of 2^logMinDelayreqInterval seconds (where logMinDelayreqInterval  us the logMessageInterval field of the last Delay response received)

The standard provides also two option to meet this requirement.

HTH

William
-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...] 
Sent: 17 March 2015 14:03
To: Chandra Mallela
Cc: Ledda William EXT; lin...@li...
Subject: Re: [Linuxptp-users] Port option: logMinDelayReqInterval

On Tue, Mar 17, 2015 at 12:47:13PM +0000, Chandra Mallela wrote:
> 1.      Which field in the delay response indicates the value to the slave announed by the master? Is it logMessageInterval?

Yes.

> 2.      DelayReq packet is sent by the slave. Thus, the number of DelayReq packets to be sent is to be controlled by the slave. Am I right? Why should it be an option with master?

Master tells slaves how often they should be polling the master.

> An answer to my own question: It is the master being burdened to respond to possibly many number of slaves. Hence, it controls the number. Is this the rationale for what you have mentioned below?

Yes, I think that's correct. The sync interval is controlled by master, so the delay interval should be too.

--
Miroslav Lichvar

Re: [Linuxptp-users] Port option: logMinDelayReqInterval

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

Hi Miroslav,

Please elucidate me on the following.

1.      Which field in the delay response indicates the value to the slave announed by the master? Is it logMessageInterval?
2.      DelayReq packet is sent by the slave. Thus, the number of DelayReq packets to be sent is to be controlled by the slave. Am I right? Why should it be an option with master?

An answer to my own question: It is the master being burdened to respond to possibly many number of slaves. Hence, it controls the number. Is this the rationale for what you have mentioned below?

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"


-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...]
Sent: Tuesday, March 17, 2015 7:34 PM
To: Chandra Mallela
Cc: Ledda William EXT; lin...@li...
Subject: Re: [Linuxptp-users] Port option: logMinDelayReqInterval

On Tue, Mar 17, 2015 at 11:18:20AM +0000, Chandra Mallela wrote:
> I think I have resolved the issue though not sure whether it is the right way. When I have used the option 'logMinDelayReqInterval -5' in ptp4l.conf at both slave and master (as opposed to just at the slave), I could see that the frequency of delay calculations has increased. Perhaps, at the slave, the option might imply 'number of delay request packets to be sent' and at the master, 'number of delay request packets to be processed'. Only when they match, the ptp4l is taking the option into consideration.

That option needs to be set on master. On slaves it sets only the initial value, after receiving first delay response message they will switch to the value announced by the master.

--
Miroslav Lichvar



  ________________________________

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] Port option: logMinDelayReqInterval

[Miroslav L. <mli...@re...>]

On Tue, Mar 17, 2015 at 12:47:13PM +0000, Chandra Mallela wrote:
> 1.      Which field in the delay response indicates the value to the slave announed by the master? Is it logMessageInterval?

Yes.

> 2.      DelayReq packet is sent by the slave. Thus, the number of DelayReq packets to be sent is to be controlled by the slave. Am I right? Why should it be an option with master?

Master tells slaves how often they should be polling the master.

> An answer to my own question: It is the master being burdened to respond to possibly many number of slaves. Hence, it controls the number. Is this the rationale for what you have mentioned below?

Yes, I think that's correct. The sync interval is controlled by
master, so the delay interval should be too.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Port option: logMinDelayReqInterval

[Ledda W. E. <Wil...@it...>]

Good to know! This is way I get always 2^3 in the slave whatever value I use (it corresponds to the value of the GMC).

Bye

William

-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...] 
Sent: 17 March 2015 12:34
To: Chandra Mallela
Cc: Ledda William EXT; lin...@li...
Subject: Re: [Linuxptp-users] Port option: logMinDelayReqInterval

On Tue, Mar 17, 2015 at 11:18:20AM +0000, Chandra Mallela wrote:
> I think I have resolved the issue though not sure whether it is the right way. When I have used the option 'logMinDelayReqInterval -5' in ptp4l.conf at both slave and master (as opposed to just at the slave), I could see that the frequency of delay calculations has increased. Perhaps, at the slave, the option might imply 'number of delay request packets to be sent' and at the master, 'number of delay request packets to be processed'. Only when they match, the ptp4l is taking the option into consideration.

That option needs to be set on master. On slaves it sets only the initial value, after receiving first delay response message they will switch to the value announced by the master.

--
Miroslav Lichvar

Re: [Linuxptp-users] Port option: logMinDelayReqInterval

[Miroslav L. <mli...@re...>]

On Tue, Mar 17, 2015 at 11:18:20AM +0000, Chandra Mallela wrote:
> I think I have resolved the issue though not sure whether it is the right way. When I have used the option 'logMinDelayReqInterval -5' in ptp4l.conf at both slave and master (as opposed to just at the slave), I could see that the frequency of delay calculations has increased. Perhaps, at the slave, the option might imply 'number of delay request packets to be sent' and at the master, 'number of delay request packets to be processed'. Only when they match, the ptp4l is taking the option into consideration.

That option needs to be set on master. On slaves it sets only the
initial value, after receiving first delay response message they will
switch to the value announced by the master.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Port option: logMinDelayReqInterval

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

Hi William et al,

I think I have resolved the issue though not sure whether it is the right way. When I have used the option 'logMinDelayReqInterval -5' in ptp4l.conf at both slave and master (as opposed to just at the slave), I could see that the frequency of delay calculations has increased. Perhaps, at the slave, the option might imply 'number of delay request packets to be sent' and at the master, 'number of delay request packets to be processed'. Only when they match, the ptp4l is taking the option into consideration.

Please feel free to pass your comments.

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"

From: Chandra Mallela
Sent: Monday, March 16, 2015 6:55 PM
To: 'Ledda William EXT'; lin...@li...
Subject: RE: Port option: logMinDelayReqInterval



Hi William,

Thank you for your response.

Please note that the intended frequencies of Delay Request packets usually run till about 512 packets per second. Thus, the minimum interval time is 1/512 seconds between packets. It means that 2^(-9). Thus, negative numbers make sense more than positive numbers. Thus, we should be able to set these negative numbers.

As I am end user, I have not looked at the code. I appreciate further inputs on this.

BTW I have already used -ve numbers for logSyncInterval up to -9. Things seem to be fine out there.

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"

From: Ledda William EXT [mailto:Wil...@it...]
Sent: Monday, March 16, 2015 6:38 PM
To: Chandra Mallela; lin...@li...<mailto:lin...@li...>
Subject: RE: Port option: logMinDelayReqInterval

I didn't check the code, but I suppose that ptp4l expects to work with positive numbers. It is possible that if forces the value to zero otherwise.


From: Chandra Mallela [mailto:sma...@al...]
Sent: 16 March 2015 11:22
To: lin...@li...<mailto:lin...@li...>
Subject: [Linuxptp-users] Port option: logMinDelayReqInterval



Hi Friends,

I have had some difficulty in using the following option.


1.      I have used it as follows only at slave as keeping this option at the master does not make sense (the slave initiates these packets). In fact, I have varied the number between -1 to -5 to check the effect of increased frequency of pathdelay calculations (2 DelayReq packets per second to 32 DelayReq packets per second). Please note that I have used the negative numbers to suit the frequency to the mean interval between packets. Is the following usage correct?

[global]
logMinDelayReqInterval -5


2.      However, irrespective of the of the option number between -1 and -5, I have always got the following message.

Ptp4l[3022.814]: port 1: minimum delay request interval 2^0



What does this mean? If the message is correct, the numbers that have been used in the above option have not been used by the ptp4l and they have been defaulted to 0. If that is the case, how can I use the option correctly? Should I use the above option with any other options to cause its effect on the ptp operation?




Please clarify.

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.

________________________________

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] Port option: logMinDelayReqInterval

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

Hi William,

Thank you for your response.

Please note that the intended frequencies of Delay Request packets usually run till about 512 packets per second. Thus, the minimum interval time is 1/512 seconds between packets. It means that 2^(-9). Thus, negative numbers make sense more than positive numbers. Thus, we should be able to set these negative numbers.

As I am end user, I have not looked at the code. I appreciate further inputs on this.

BTW I have already used -ve numbers for logSyncInterval up to -9. Things seem to be fine out there.

Thanking you in anticipation,
Regards,
Chandra

(c) : 0175508142
(O): 701.6412

"Knowledge speaks, Wisdom listens"

From: Ledda William EXT [mailto:Wil...@it...]
Sent: Monday, March 16, 2015 6:38 PM
To: Chandra Mallela; lin...@li...
Subject: RE: Port option: logMinDelayReqInterval

I didn't check the code, but I suppose that ptp4l expects to work with positive numbers. It is possible that if forces the value to zero otherwise.


From: Chandra Mallela [mailto:sma...@al...]
Sent: 16 March 2015 11:22
To: lin...@li...<mailto:lin...@li...>
Subject: [Linuxptp-users] Port option: logMinDelayReqInterval



Hi Friends,

I have had some difficulty in using the following option.


1.      I have used it as follows only at slave as keeping this option at the master does not make sense (the slave initiates these packets). In fact, I have varied the number between -1 to -5 to check the effect of increased frequency of pathdelay calculations (2 DelayReq packets per second to 32 DelayReq packets per second). Please note that I have used the negative numbers to suit the frequency to the mean interval between packets. Is the following usage correct?

[global]
logMinDelayReqInterval -5


2.      However, irrespective of the of the option number between -1 and -5, I have always got the following message.

Ptp4l[3022.814]: port 1: minimum delay request interval 2^0



What does this mean? If the message is correct, the numbers that have been used in the above option have not been used by the ptp4l and they have been defaulted to 0. If that is the case, how can I use the option correctly? Should I use the above option with any other options to cause its effect on the ptp operation?




Please clarify.

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.

________________________________

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] Port option: logMinDelayReqInterval

[Ledda W. E. <Wil...@it...>]

I didn't check the code, but I suppose that ptp4l expects to work with positive numbers. It is possible that if forces the value to zero otherwise.


From: Chandra Mallela [mailto:sma...@al...]
Sent: 16 March 2015 11:22
To: lin...@li...
Subject: [Linuxptp-users] Port option: logMinDelayReqInterval



Hi Friends,

I have had some difficulty in using the following option.


1.      I have used it as follows only at slave as keeping this option at the master does not make sense (the slave initiates these packets). In fact, I have varied the number between -1 to -5 to check the effect of increased frequency of pathdelay calculations (2 DelayReq packets per second to 32 DelayReq packets per second). Please note that I have used the negative numbers to suit the frequency to the mean interval between packets. Is the following usage correct?

[global]
logMinDelayReqInterval -5


2.      However, irrespective of the of the option number between -1 and -5, I have always got the following message.

Ptp4l[3022.814]: port 1: minimum delay request interval 2^0



What does this mean? If the message is correct, the numbers that have been used in the above option have not been used by the ptp4l and they have been defaulted to 0. If that is the case, how can I use the option correctly? Should I use the above option with any other options to cause its effect on the ptp operation?




Please clarify.

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.

[Linuxptp-users] Port option: logMinDelayReqInterval

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

Hi Friends,

I have had some difficulty in using the following option.


1.      I have used it as follows only at slave as keeping this option at the master does not make sense (the slave initiates these packets). In fact, I have varied the number between -1 to -5 to check the effect of increased frequency of pathdelay calculations (2 DelayReq packets per second to 32 DelayReq packets per second). Please note that I have used the negative numbers to suit the frequency to the mean interval between packets. Is the following usage correct?

[global]
logMinDelayReqInterval -5


2.      However, irrespective of the of the option number between -1 and -5, I have always got the following message.

Ptp4l[3022.814]: port 1: minimum delay request interval 2^0



What does this mean? If the message is correct, the numbers that have been used in the above option have not been used by the ptp4l and they have been defaulted to 0. If that is the case, how can I use the option correctly? Should I use the above option with any other options to cause its effect on the ptp operation?




Please clarify.

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

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

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

[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] PTP grandmaster and P2P delay mechanism

[Daniel Le <dan...@ex...>]

Thanks Richard.

The TimeProvider 5000 doesn't have a configuration option to select delay mechanism. It works with E2E only. I did check that out. Also I just got Symmetricom (now Microsemi) technical support's confirmation that the TimeProvider 5000 only supports the end-to-end delay mechanism.

Daniel
________________________________________
From: Richard Cochran [ric...@gm...]
Sent: Saturday, March 07, 2015 2:05 AM
To: Daniel Le
Cc: lin...@li...
Subject: Re: [Linuxptp-users] PTP grandmaster and P2P delay mechanism

On Fri, Mar 06, 2015 at 05:39:17PM +0000, Daniel Le wrote:
> Hello,
>
> By IEEE 1588-2008 standard, can a grandmaster clock support peer-to-peer delay mechanism, in addition to the request-response delay mechanism?

Yes, a GM can and should support both the P2P and E2E mechanisms.  You
cannot mix the two in one network.  However, in ptp4l the delay
mechanism is a per-port option.  That means you can configure your BC
to ask as a bridge between different networks.

> I did an experiment where I ran ptp4l on one device as grandmaster and on other device as slave. The two devices were connected back-to-back, configured to do peer-to-peer delay measurement, and the protocol handshaking was fine.
>
> I then tested the Symmetricom TimeProvider 5000 grandmaster and realized it only worked with request-response delay measurement protocol.

Maybe they have a configuration option?

HTH,
Richard

Re: [Linuxptp-users] PTP grandmaster and P2P delay mechanism

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

On Fri, Mar 06, 2015 at 05:39:17PM +0000, Daniel Le wrote:
> Hello,
> 
> By IEEE 1588-2008 standard, can a grandmaster clock support peer-to-peer delay mechanism, in addition to the request-response delay mechanism?

Yes, a GM can and should support both the P2P and E2E mechanisms.  You
cannot mix the two in one network.  However, in ptp4l the delay
mechanism is a per-port option.  That means you can configure your BC
to ask as a bridge between different networks.
 
> I did an experiment where I ran ptp4l on one device as grandmaster and on other device as slave. The two devices were connected back-to-back, configured to do peer-to-peer delay measurement, and the protocol handshaking was fine.
> 
> I then tested the Symmetricom TimeProvider 5000 grandmaster and realized it only worked with request-response delay measurement protocol.

Maybe they have a configuration option?

HTH,
Richard

[Linuxptp-users] PTP grandmaster and P2P delay mechanism

[Daniel Le <dan...@ex...>]

Hello,

By IEEE 1588-2008 standard, can a grandmaster clock support peer-to-peer delay mechanism, in addition to the request-response delay mechanism?

I did an experiment where I ran ptp4l on one device as grandmaster and on other device as slave. The two devices were connected back-to-back, configured to do peer-to-peer delay measurement, and the protocol handshaking was fine.

I then tested the Symmetricom TimeProvider 5000 grandmaster and realized it only worked with request-response delay measurement protocol.

Thanks,
Daniel

[Linuxptp-users] R: Compile issue in RHEL v6.3

[Ledda W. E. <Wil...@it...>]

Hello, 
I started directly with 6.4 and currently I'm using 6.5 with an Intel i350. I don't have any workaround for 6.3. What about to compile and install a kernel 3.10x?

Regards
________________________________________
Da: Yoo, Choong Keun [cho...@hp...]
Inviato: venerdì 27 febbraio 2015 16.38
A: Ledda William EXT; lin...@li...
Oggetto: RE: Compile issue in RHEL v6.3

Hello, William

Thanks for the response.
Do you aware any workaround ? The customer want to stay with RHEL v6.3 for some reason.

Have you tried time-keeper on v6.3?
http://www.fsmlabs.com/pdfs/FSMLabs_Red_Hat_01042011.pdf

Thanks,

Yoo, Choong Keun

From: Ledda William EXT [mailto:Wil...@it...]
Sent: Thursday, February 26, 2015 6:11 PM
To: Yoo, Choong Keun; lin...@li...
Subject: RE: Compile issue in RHEL v6.3

PTP support starts from kernel 3.10x. Red Hat has backported this support into kernel 2.6x starting from 6.4 so I don’t think that a workaround exists for 6.4.I had the same problem.
Even if you can compile you will probably have problems with the network driver.

Regards

William

From: Yoo, Choong Keun [mailto:cho...@hp...]
Sent: 26 February 2015 09:46
To: lin...@li...<mailto:lin...@li...>
Subject: [Linuxptp-users] Compile issue in RHEL v6.3

Dear,

I have a customer who use HP DL380Gen8 server with RHEL v6.3 OS.
They want to implement PTP with HP NC560 (Intel® 82599 Controller) NIC.

They encountered problem when they try to compile linuxptp.

grep: /usr/include/linux/net_tstamp.h: No such file or directory
ptp4l.c:25:30: error: linux/net_tstamp.h: No such file or directory

There is no net_tstamp.h in kernel-header package of RHEL 6.3 kernel 2.6.32-279.el6.
RHEL v6.4 has net_tstamp.h.

Is there any way to compile linuxptp on RHEL v6.3 ?
If not, what is technical issue in RHEL v6.3.

According to linuxptp.sourceforge.net we need set below kernel config  option but  it seems like only CONFIG_PPS is available as module. In RHEL v6.3
Is there any workaround?

Option

Description

CONFIG_PPS

Required

CONFIG_NETWORK_PHY_TIMESTAMPING

Timestamping in PHY devices

PTP_1588_CLOCK

PTP clock support


Regards,

Yoo, Choong Keun

Re: [Linuxptp-users] Compile issue in RHEL v6.3

[Keller, J. E <jac...@in...>]

Hi,

So the problem is that the kernel clock support for ptp hardware clocks
was not backported until 6.4, and I wouldn't even trust its backport
until at least 6.5

I've done some decent validation of Intel stuff on 6.5 and it works well
enough, but you have to trust that Redhat backported the complex feature
correctly.

6.3 could do software timestamping, that really is about all.

Regards,
Jake

On Fri, 2015-02-27 at 15:38 +0000, Yoo, Choong Keun wrote:
> Hello, William
> 
>  
> 
> Thanks for the response.
> 
> Do you aware any workaround ? The customer want to stay with RHEL v6.3
> for some reason.
> 
>  
> 
> Have you tried time-keeper on v6.3?
> 
> http://www.fsmlabs.com/pdfs/FSMLabs_Red_Hat_01042011.pdf
> 
>  
> 
> Thanks,
> 
>  
> 
> Yoo, Choong Keun
> 
> 
>  
> 
> From: Ledda William EXT [mailto:Wil...@it...] 
> Sent: Thursday, February 26, 2015 6:11 PM
> To: Yoo, Choong Keun; lin...@li...
> Subject: RE: Compile issue in RHEL v6.3
> 
> 
>  
> 
> PTP support starts from kernel 3.10x. Red Hat has backported this
> support into kernel 2.6x starting from 6.4 so I don’t think that a
> workaround exists for 6.4.I had the same problem. 
> 
> Even if you can compile you will probably have problems with the
> network driver.
> 
>  
> 
> Regards
> 
>  
> 
> William
> 
>  
> 
> From: Yoo, Choong Keun [mailto:cho...@hp...] 
> Sent: 26 February 2015 09:46
> To: lin...@li...
> Subject: [Linuxptp-users] Compile issue in RHEL v6.3
> 
> 
>  
> 
> Dear, 
> 
>  
> 
> I have a customer who use HP DL380Gen8 server with RHEL v6.3 OS.
> 
> They want to implement PTP with HP NC560 (Intel® 82599 Controller)
> NIC.
> 
>  
> 
> They encountered problem when they try to compile linuxptp.
> 
>  
> 
> grep: /usr/include/linux/net_tstamp.h: No such file or directory
> 
> ptp4l.c:25:30: error: linux/net_tstamp.h: No such file or directory
> 
>  
> 
> There is no net_tstamp.h in kernel-header package of RHEL 6.3 kernel
> 2.6.32-279.el6.
> 
> RHEL v6.4 has net_tstamp.h.
> 
>  
> 
> Is there any way to compile linuxptp on RHEL v6.3 ?
> 
> If not, what is technical issue in RHEL v6.3. 
> 
>  
> 
> According to linuxptp.sourceforge.net we need set below kernel config
>  option but  it seems like only CONFIG_PPS is available as module. In
> RHEL v6.3
> 
> Is there any workaround?
> 
>  
> 
>               Option
> 
> 
>             Description
> 
> 
> CONFIG_PPS
> 
> 
> Required
> 
> 
> CONFIG_NETWORK_PHY_TIMESTAMPING
> 
> 
> Timestamping in PHY devices
> 
> 
> PTP_1588_CLOCK
> 
> 
> PTP clock support
> 
> 
> 
>  
> 
> Regards,
> 
>  
> 
> Yoo, Choong Keun
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Compile issue in RHEL v6.3

[Yoo, C. K. <cho...@hp...>]

Hello, William

Thanks for the response.
Do you aware any workaround ? The customer want to stay with RHEL v6.3 for some reason.

Have you tried time-keeper on v6.3?
http://www.fsmlabs.com/pdfs/FSMLabs_Red_Hat_01042011.pdf

Thanks,

Yoo, Choong Keun

From: Ledda William EXT [mailto:Wil...@it...]
Sent: Thursday, February 26, 2015 6:11 PM
To: Yoo, Choong Keun; lin...@li...
Subject: RE: Compile issue in RHEL v6.3

PTP support starts from kernel 3.10x. Red Hat has backported this support into kernel 2.6x starting from 6.4 so I don't think that a workaround exists for 6.4.I had the same problem.
Even if you can compile you will probably have problems with the network driver.

Regards

William

From: Yoo, Choong Keun [mailto:cho...@hp...]
Sent: 26 February 2015 09:46
To: lin...@li...<mailto:lin...@li...>
Subject: [Linuxptp-users] Compile issue in RHEL v6.3

Dear,

I have a customer who use HP DL380Gen8 server with RHEL v6.3 OS.
They want to implement PTP with HP NC560 (Intel(r) 82599 Controller) NIC.

They encountered problem when they try to compile linuxptp.

grep: /usr/include/linux/net_tstamp.h: No such file or directory
ptp4l.c:25:30: error: linux/net_tstamp.h: No such file or directory

There is no net_tstamp.h in kernel-header package of RHEL 6.3 kernel 2.6.32-279.el6.
RHEL v6.4 has net_tstamp.h.

Is there any way to compile linuxptp on RHEL v6.3 ?
If not, what is technical issue in RHEL v6.3.

According to linuxptp.sourceforge.net we need set below kernel config  option but  it seems like only CONFIG_PPS is available as module. In RHEL v6.3
Is there any workaround?

Option

Description

CONFIG_PPS

Required

CONFIG_NETWORK_PHY_TIMESTAMPING

Timestamping in PHY devices

PTP_1588_CLOCK

PTP clock support


Regards,

Yoo, Choong Keun