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

Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource temporarily unavailable

[Rayagond K. <ray...@gm...>]

Thank you Richard, I will implement .adjfreq and use default.cfg and test
it and let you know.

On 5 February 2013 22:20, Richard Cochran <ric...@gm...> wrote:

> On Tue, Feb 05, 2013 at 09:23:03PM +0530, Rayagond Kokatanur wrote:
> >
> > I am not getting how to write configuration file that can be provided as
> > input to *ptp4l, *please send me one example.
>
> There are two example files in the code, default.cfg, and gPTP.cfg.
> I would start with the first one.
>
> > Yes, it is unpublished driver and I referred Linux driver and document
> and
> > added PTP support into my driver.
> >
> > I have written PHC driver, but its not yet complete, need to implement
> some
> > other clock operations like .adjfreq and .enable.
>
> You can leave .enable as a stub, but you must implement the other
> methods, otherwise you won't be able to run PTP.
>
> > My test setup is as below,
> >
> > 1. Two system connected back to back and both the system running Linux
> > 3.1.1 kernel.
> > 2. On one side my HW and driver is running and on other side realteck
> 8169
> > driver is running. I modified the realteck driver to support software
> > timestamping ie added "skb_tx_timestamp()" in start_xmit function. Since
> I
> > don't have other NIC card that support HW time stamping, so I am using
> > software timestaping on other side.
> >
> > So is it possible to do basic validation/tetsing of PTP using above
> setup ?
>
> Yes, I think so.
>
> > Feb  5 20:11:04 snps ptp4l: [17640.898] failed to adjust the clock:
> > Operation not supported
>
> Because your driver isn't finished.
>
> > I am new to PTP so not able to understand the above log completely,
> please
> > let me know if my test setup is correct or not.
>
> Looks okay to me.
>
> HTH,
> Richard
>

Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource temporarily unavailable

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

To use the configuration files you have to pass them to ptp4l via "-f default.cfg", the default won't change any settings as it represents the default settings. However, just modifying the file won't cause ptp4l to automatically load it. You have to request loading using the -f flag.

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Tuesday, February 05, 2013 8:51 AM
> To: Rayagond Kokatanur
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource
> temporarily unavailable
> 
> On Tue, Feb 05, 2013 at 09:23:03PM +0530, Rayagond Kokatanur wrote:
> >
> > I am not getting how to write configuration file that can be provided as
> > input to *ptp4l, *please send me one example.
> 
> There are two example files in the code, default.cfg, and gPTP.cfg.
> I would start with the first one.
> 
> > Yes, it is unpublished driver and I referred Linux driver and document
> and
> > added PTP support into my driver.
> >
> > I have written PHC driver, but its not yet complete, need to implement
> some
> > other clock operations like .adjfreq and .enable.
> 
> You can leave .enable as a stub, but you must implement the other
> methods, otherwise you won't be able to run PTP.
> 
> > My test setup is as below,
> >
> > 1. Two system connected back to back and both the system running
> Linux
> > 3.1.1 kernel.
> > 2. On one side my HW and driver is running and on other side realteck
> 8169
> > driver is running. I modified the realteck driver to support software
> > timestamping ie added "skb_tx_timestamp()" in start_xmit function.
> Since I
> > don't have other NIC card that support HW time stamping, so I am
> using
> > software timestaping on other side.
> >
> > So is it possible to do basic validation/tetsing of PTP using above setup
> ?
> 
> Yes, I think so.
> 
> > Feb  5 20:11:04 snps ptp4l: [17640.898] failed to adjust the clock:
> > Operation not supported
> 
> Because your driver isn't finished.
> 
> > I am new to PTP so not able to understand the above log completely,
> please
> > let me know if my test setup is correct or not.
> 
> Looks okay to me.
> 
> HTH,
> Richard
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource temporarily unavailable

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

It's an error with Tx timestamping, and the most likely cause is that your driver is not returning the timestamp within the timeout. I suggest increasing the tx_timeout variable in the config file and passing it using -f /path/to/config

Thanks

 - Jake

> -----Original Message-----
> From: Rayagond Kokatanur [mailto:ray...@gm...]
> Sent: Tuesday, February 05, 2013 4:48 AM
> To: lin...@li...
> Subject: [Linuxptp-users] recvmsg tx timestamp failed: Resource
> temporarily unavailable
> 
> Hi All
> 
> I am getting following messages when I run the command - ptp4l -i eth1
> -p /dev/ptp0 -m
> 
> ptp4l[9393.328]: selected /dev/ptp0 as PTP clock
> ptp4l[9393.330]: failed to read out the clock frequency adjustment:
> Operation not supported
> ptp4l[9393.330]: port 1: get_ts_info not supported
> ptp4l[9393.335]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[9393.335]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[9399.335]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[9400.342]: recvmsg tx timestamp failed: Resource temporarily
> unavailable
> ptp4l[9400.342]: port 1: send sync failed
> ptp4l[9400.342]: port 1: MASTER to FAULTY on FAULT_DETECTED
> ptp4l[9415.349]: port 1: FAULTY to LISTENING on FAULT_CLEARED
> ptp4l[9421.349]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[9422.356]: recvmsg tx timestamp failed: Resource temporarily
> unavailable
> ptp4l[9422.356]: port 1: send sync failed
> ptp4l[9422.356]: port 1: MASTER to FAULTY on FAULT_DETECTED
> ptp4l[9437.363]: port 1: FAULTY to LISTENING on FAULT_CLEARED
> 
> What does this error means ?
> 
> I am returning the timestamp back to socket using "skb_tstamp_tx()"
> api in my driver.
> 
> 
> WWR
> Rayagond
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource temporarily unavailable

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

On Tue, Feb 05, 2013 at 09:23:03PM +0530, Rayagond Kokatanur wrote:
> 
> I am not getting how to write configuration file that can be provided as
> input to *ptp4l, *please send me one example.

There are two example files in the code, default.cfg, and gPTP.cfg.
I would start with the first one.

> Yes, it is unpublished driver and I referred Linux driver and document and
> added PTP support into my driver.
> 
> I have written PHC driver, but its not yet complete, need to implement some
> other clock operations like .adjfreq and .enable.

You can leave .enable as a stub, but you must implement the other
methods, otherwise you won't be able to run PTP.
 
> My test setup is as below,
> 
> 1. Two system connected back to back and both the system running Linux
> 3.1.1 kernel.
> 2. On one side my HW and driver is running and on other side realteck 8169
> driver is running. I modified the realteck driver to support software
> timestamping ie added "skb_tx_timestamp()" in start_xmit function. Since I
> don't have other NIC card that support HW time stamping, so I am using
> software timestaping on other side.
> 
> So is it possible to do basic validation/tetsing of PTP using above setup ?

Yes, I think so.
 
> Feb  5 20:11:04 snps ptp4l: [17640.898] failed to adjust the clock:
> Operation not supported

Because your driver isn't finished.
 
> I am new to PTP so not able to understand the above log completely, please
> let me know if my test setup is correct or not.

Looks okay to me. 

HTH,
Richard

Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource temporarily unavailable

[Rayagond K. <ray...@gm...>]

Hi Richard,

On 5 February 2013 18:54, Richard Cochran <ric...@gm...> wrote:

> On Tue, Feb 05, 2013 at 06:18:05PM +0530, Rayagond Kokatanur wrote:
> > Hi All
> >
> > I am getting following messages when I run the command - ptp4l -i eth1
> > -p /dev/ptp0 -m
> >
> > ptp4l[9393.328]: selected /dev/ptp0 as PTP clock
> > ptp4l[9393.330]: failed to read out the clock frequency adjustment:
> > Operation not supported
>
> Looks like your /dev/ptp0 does not support clock_adjtime().
>
> > ptp4l[9393.330]: port 1: get_ts_info not supported
> > ptp4l[9393.335]: port 1: INITIALIZING to LISTENING on INITIALIZE
> > ptp4l[9393.335]: port 0: INITIALIZING to LISTENING on INITIALIZE
> > ptp4l[9399.335]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> > ptp4l[9400.342]: recvmsg tx timestamp failed: Resource temporarily
> unavailable
>
> No Tx time stamp arrived on the socket error queue. The code tries to
> read this 100 times, but you can increase the number of retries using
> the 'tx_timestamp_retries' configuration file option.
>

Yes, I am able to fix this issue, the bug was in my driver only ie I was
not returning the tx timestamp to stack early.

I am not getting how to write configuration file that can be provided as
input to *ptp4l, *please send me one example.


>
> > I am returning the timestamp back to socket using "skb_tstamp_tx()"
> > api in my driver.
>
> So I guess that your have custom, unpublished driver. It looks like to
> me that the driver is not working correctly. You can check the PHC
> functions of the driver by using the 'testptp' program found in
> Documentation/ptp in the Linux kernel source tree.
>

Yes, it is unpublished driver and I referred Linux driver and document and
added PTP support into my driver.

I have written PHC driver, but its not yet complete, need to implement some
other clock operations like .adjfreq and .enable.

My test setup is as below,

1. Two system connected back to back and both the system running Linux
3.1.1 kernel.
2. On one side my HW and driver is running and on other side realteck 8169
driver is running. I modified the realteck driver to support software
timestamping ie added "skb_tx_timestamp()" in start_xmit function. Since I
don't have other NIC card that support HW time stamping, so I am using
software timestaping on other side.

So is it possible to do basic validation/tetsing of PTP using above setup ?

I tried configuring the realteck as MASTER with SOFTWARE timestamping($*ptp4l
-i eth0 -S -m*) and my HW as slave with HW timestamping ($*ptp4l -i eth0 -p
/dev/ptp0 -m -s*). With this I am able to see the SYNC, FOLLOW_UP,
DELAY_REQ and DELAY_RESP message exchange between MASTER and SLEVE.

Following are the debug message got on SLAVE side,

Feb  5 20:11:02 snps ptp4l: [17638.899] selected best master clock
f0def1.fffe.58de16
Feb  5 20:11:02 snps ptp4l: [17638.899] foreign master not using PTP
timescale
Feb  5 20:11:02 snps ptp4l: [17638.899] port 1: LISTENING to UNCALIBRATED
on RS_SLAVE
Feb  5 20:11:03 snps kernel:
Feb  5 20:11:03 snps ptp4l: [17639.586] negative path delay -1457969541
Feb  5 20:11:03 snps ptp4l: [17639.586] path_delay = (t2 - t3) + (t4 - t1)
Feb  5 20:11:03 snps ptp4l: [17639.586] t2 - t3 = -3603036636
Feb  5 20:11:03 snps ptp4l: [17639.586] t4 - t1 = +687097553
Feb  5 20:11:03 snps ptp4l: [17639.586] c1          0
Feb  5 20:11:03 snps ptp4l: [17639.586] c2          0
Feb  5 20:11:03 snps ptp4l: [17639.586] c3          0
Feb  5 20:11:03 snps ptp4l: [17639.899] master offset -728444660000 s0
adj      +0 path delay -1457969541
Feb  5 20:11:04 snps ptp4l: [17640.898] master offset -725178558579 s1 adj
+50000000 path delay -1457969541
Feb  5 20:11:04 snps ptp4l: [17640.898] failed to adjust the clock:
Operation not supported
Feb  6 20:11:05 snps kernel:
Feb  5 20:11:05 snps kernel:
Feb  5 20:11:05 snps ptp4l: [17641.898] master offset 32827238152 s2 adj
+50000000 path delay -1457969541
Feb  5 20:11:05 snps ptp4l: [17641.898] failed to adjust the clock:
Operation not supported
Feb  5 20:11:05 snps ptp4l: [17641.898] port 1: UNCALIBRATED to SLAVE on
MASTER_CLOCK_SELECTED
Feb  5 20:11:06 snps ptp4l: [17642.897] master offset 36093339114 s2 adj
+50000000 path delay -1457969541
Feb  5 20:11:06 snps ptp4l: [17642.897] failed to adjust the clock:
Operation not supported
Feb  5 20:11:07 snps ptp4l: [17643.484] negative path delay -328446461
Feb  5 20:11:07 snps ptp4l: [17643.484] path_delay = (t2 - t3) + (t4 - t1)
Feb  5 20:11:07 snps ptp4l: [17643.484] t2 - t3 = -1244255534
Feb  5 20:11:07 snps ptp4l: [17643.484] t4 - t1 = +587362612
Feb  5 20:11:07 snps ptp4l: [17643.484] c1          0
Feb  5 20:11:07 snps ptp4l: [17643.484] c2          0
Feb  5 20:11:07 snps ptp4l: [17643.484] c3          0
Feb  5 20:11:07 snps kernel:
Feb  5 20:11:07 snps ptp4l: [17643.897] master offset 38794768811 s2 adj
+50000000 path delay -893208001
Feb  5 20:11:07 snps ptp4l: [17643.897] failed to adjust the clock:
Operation not supported
Feb  5 20:11:08 snps ptp4l: [17644.225] negative path delay -183759008
Feb  5 20:11:08 snps ptp4l: [17644.225] path_delay = (t2 - t3) + (t4 - t1)
Feb  5 20:11:08 snps ptp4l: [17644.226] t2 - t3 = -696186278
Feb  5 20:11:08 snps ptp4l: [17644.226] t4 - t1 = +328668261
Feb  5 20:11:08 snps ptp4l: [17644.226] c1          0
Feb  5 20:11:08 snps ptp4l: [17644.226] c2          0
Feb  5 20:11:08 snps ptp4l: [17644.226] c3          0
Feb  5 20:11:08 snps kernel:
Feb  5 20:11:08 snps kernel:
Feb  5 20:11:08 snps ptp4l: [17644.517] negative path delay -346790341
Feb  5 20:11:08 snps ptp4l: [17644.517] path_delay = (t2 - t3) + (t4 - t1)
Feb  5 20:11:08 snps ptp4l: [17644.517] t2 - t3 = -1313738070
Feb  5 20:11:08 snps ptp4l: [17644.517] t4 - t1 = +620157388
Feb  5 20:11:08 snps ptp4l: [17644.517] c1          0
Feb  5 20:11:08 snps ptp4l: [17644.517] c2          0
Feb  5 20:11:08 snps ptp4l: [17644.517] c3          0
Feb  5 20:11:08 snps ptp4l: [17644.896] master offset 41746912836 s2 adj
+50000000 path delay -579241337
Feb  5 20:11:08 snps ptp4l: [17644.896] failed to adjust the clock:
Operation not supported

I am new to PTP so not able to understand the above log completely, please
let me know if my test setup is correct or not.


> You can also test the SO_TIMESTAMPING support using the program found
> in Documentation/networking/timestamping.
>
> HTH,
> Richard
>

Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource temporarily unavailable

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

On Tue, Feb 05, 2013 at 06:18:05PM +0530, Rayagond Kokatanur wrote:
> Hi All
> 
> I am getting following messages when I run the command - ptp4l -i eth1
> -p /dev/ptp0 -m
> 
> ptp4l[9393.328]: selected /dev/ptp0 as PTP clock
> ptp4l[9393.330]: failed to read out the clock frequency adjustment:
> Operation not supported

Looks like your /dev/ptp0 does not support clock_adjtime().

> ptp4l[9393.330]: port 1: get_ts_info not supported
> ptp4l[9393.335]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[9393.335]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[9399.335]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[9400.342]: recvmsg tx timestamp failed: Resource temporarily unavailable

No Tx time stamp arrived on the socket error queue. The code tries to
read this 100 times, but you can increase the number of retries using
the 'tx_timestamp_retries' configuration file option.

> I am returning the timestamp back to socket using "skb_tstamp_tx()"
> api in my driver.

So I guess that your have custom, unpublished driver. It looks like to
me that the driver is not working correctly. You can check the PHC
functions of the driver by using the 'testptp' program found in
Documentation/ptp in the Linux kernel source tree.

You can also test the SO_TIMESTAMPING support using the program found
in Documentation/networking/timestamping.

HTH,
Richard

[Linuxptp-users] recvmsg tx timestamp failed: Resource temporarily unavailable

[Rayagond K. <ray...@gm...>]

Hi All

I am getting following messages when I run the command - ptp4l -i eth1
-p /dev/ptp0 -m

ptp4l[9393.328]: selected /dev/ptp0 as PTP clock
ptp4l[9393.330]: failed to read out the clock frequency adjustment:
Operation not supported
ptp4l[9393.330]: port 1: get_ts_info not supported
ptp4l[9393.335]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[9393.335]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[9399.335]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[9400.342]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[9400.342]: port 1: send sync failed
ptp4l[9400.342]: port 1: MASTER to FAULTY on FAULT_DETECTED
ptp4l[9415.349]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[9421.349]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[9422.356]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[9422.356]: port 1: send sync failed
ptp4l[9422.356]: port 1: MASTER to FAULTY on FAULT_DETECTED
ptp4l[9437.363]: port 1: FAULTY to LISTENING on FAULT_CLEARED

What does this error means ?

I am returning the timestamp back to socket using "skb_tstamp_tx()"
api in my driver.


WWR
Rayagond

Re: [Linuxptp-users] Need help : new to PTP testing

[Rayagond K. <ray...@gm...>]

Thanks Jacob and Richard for your quick help, I will try it and let you
know.


On 26 January 2013 13:23, Keller, Jacob E <jac...@in...> wrote:

> > -----Original Message-----
> > From: Richard Cochran [mailto:ric...@gm...]
> > Sent: Friday, January 25, 2013 11:39 PM
> > To: Keller, Jacob E
> > Cc: Rayagond Kokatanur; lin...@li...
> > Subject: Re: [Linuxptp-users] Need help : new to PTP testing
> >
> > On Fri, Jan 25, 2013 at 10:56:44AM -0800, Jacob Keller wrote:
> > >
> > > For testing purposes I would use the -v option which switches to
> > verbose
> > > mode and prevents the daemon software from backgrounding. This
> > will
> > > allow  you to more easily view the output.
> >
> > I changed the -v option to show the version info, just before making
> > release 1.0. Instead you now use -m and -q.
> >
> > Otherwise, Jacob's advice is good.
>
> Yes I had forgotten :) Thanks
>
>  - Jake
> >
> > Thanks,
> > Richard
>

Re: [Linuxptp-users] Need help : new to PTP testing

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Friday, January 25, 2013 11:39 PM
> To: Keller, Jacob E
> Cc: Rayagond Kokatanur; lin...@li...
> Subject: Re: [Linuxptp-users] Need help : new to PTP testing
> 
> On Fri, Jan 25, 2013 at 10:56:44AM -0800, Jacob Keller wrote:
> >
> > For testing purposes I would use the -v option which switches to
> verbose
> > mode and prevents the daemon software from backgrounding. This
> will
> > allow  you to more easily view the output.
> 
> I changed the -v option to show the version info, just before making
> release 1.0. Instead you now use -m and -q.
> 
> Otherwise, Jacob's advice is good.

Yes I had forgotten :) Thanks

 - Jake
> 
> Thanks,
> Richard

Re: [Linuxptp-users] Need help : new to PTP testing

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

On Fri, Jan 25, 2013 at 10:56:44AM -0800, Jacob Keller wrote:
> 
> For testing purposes I would use the -v option which switches to verbose 
> mode and prevents the daemon software from backgrounding. This will 
> allow  you to more easily view the output.

I changed the -v option to show the version info, just before making
release 1.0. Instead you now use -m and -q.

Otherwise, Jacob's advice is good.

Thanks,
Richard

Re: [Linuxptp-users] Need help : new to PTP testing

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

On Fri, Jan 25, 2013 at 04:28:39PM +0530, Rayagond Kokatanur wrote:
> I am new to PTP implementation and testing.

...

> 6. I ran following commands ...

Up until this point, you did everything just right.
 
> $ptp4l -i eth0 -p /dev/ptp0
> 
> ie I choose my system ad PTP master and it is sending the SYNC messages and
> all.

I would do

   ptp4l -i eth0 -p /dev/ptp0 -m -q

then you will see all the messages that show the estimated offset from
master. You can also add '-s' to force slave-only mode.

> I am not getting how to use -f option and what is the configuration file
> etc.

For simple testing, you don't need the configuration file at all.

HTH,
Richard

Re: [Linuxptp-users] Need help : new to PTP testing

[Jacob K. <jac...@in...>]

On 01/25/2013 02:58 AM, Rayagond Kokatanur wrote:
> Hi All,
>
> I am new to PTP implementation and testing.
>
> So far I have done following with the help of Linux doc and browsing
> (http://linuxptp.sourceforge.net/),
>
> 1. I referred Linux doc and reference driver and implemented PTP V1 and
> V2 in MAC driver - MAC driver is able to handle PTP packets, it can pass
> the transmitted/received packets timestamp value to stack.
>
> 2. I am able to write PTP Hardware Clock (PHC) driver and integrate with
> my MAC driver - Through PHC driver I have registered all the clock API's
> like gettime/settime/adjtime etc to ptp clock driver or ptp stack. My
> MAC has internal clock source, so I am registering the PHC driver as
> part of MAC driver itself.
>
> 3. I build Linux kernel with version 3.1.1 and enabled all the PTP
> related kernel configurations like CONFIG_PPS,
> CONFIG_NETWORK_PHY_TIMESTAMPING and PTP_1588_CLOCK.
>
> 4. After loading MAC driver I can see /dev/ptp0 entry for my PHC driver.
>
> 5. For testing PTP, I downloaded the ptp application from -  git clone
> git://git.code.sf.net/p/linuxptp/code
> <http://git.code.sf.net/p/linuxptp/code>, and compiled the ptp it and
> installed in my system. Now I can run the ptp application.
>
> 6. I ran following commands ...
>
> $ptp4l -i eth0 -p /dev/ptp0
>
> ie I choose my system ad PTP master and it is sending the SYNC messages
> and all.
>
> I am not getting how to use -f option and what is the configuration file
> etc.
>
> I don't have clear idea on how to test the PTP, please give me some
> suggestions to go ahead.
>
> Thank you all in advance for any help.
>
> ---------------
> Rayagond
>
>
>

Hi Rayagond -

The config file has a lot of fine tuning options that you may (or may 
not) need for your part to work, and for fine tuning some settings. I 
would suggest viewing the man page which is provided in the source. This 
page describes the options available and how to use them.

If your device has a method of externally generating a pulse per second 
you can set up a test that helps to compare the calculated offset value 
by PTP and the actual jitter of the pulse per second.

You will need two machines, at least one of which has your part, linked 
to the other end that has a working PTP implementation, whether that is 
your own part, another part, or software timestamping.

For testing purposes I would use the -v option which switches to verbose 
mode and prevents the daemon software from backgrounding. This will 
allow  you to more easily view the output.

I would suggest providing a known working hardware timestamp NIC or 
switch or something on the other end of the link in order to test your 
part against that.

Hope this helps.

- Jake

[Linuxptp-users] Need help : new to PTP testing

[Rayagond K. <ray...@gm...>]

Hi All,

I am new to PTP implementation and testing.

So far I have done following with the help of Linux doc and browsing (
http://linuxptp.sourceforge.net/),

1. I referred Linux doc and reference driver and implemented PTP V1 and V2
in MAC driver - MAC driver is able to handle PTP packets, it can pass the
transmitted/received packets timestamp value to stack.

2. I am able to write PTP Hardware Clock (PHC) driver and integrate with my
MAC driver - Through PHC driver I have registered all the clock API's like
gettime/settime/adjtime etc to ptp clock driver or ptp stack. My MAC has
internal clock source, so I am registering the PHC driver as part of MAC
driver itself.

3. I build Linux kernel with version 3.1.1 and enabled all the PTP related
kernel configurations like CONFIG_PPS, CONFIG_NETWORK_PHY_TIMESTAMPING and
PTP_1588_CLOCK.

4. After loading MAC driver I can see /dev/ptp0 entry for my PHC driver.

5. For testing PTP, I downloaded the ptp application from -  git clone
git://git.code.sf.net/p/linuxptp/code, and compiled the ptp it and
installed in my system. Now I can run the ptp application.

6. I ran following commands ...

$ptp4l -i eth0 -p /dev/ptp0

ie I choose my system ad PTP master and it is sending the SYNC messages and
all.

I am not getting how to use -f option and what is the configuration file
etc.

I don't have clear idea on how to test the PTP, please give me some
suggestions to go ahead.

Thank you all in advance for any help.

---------------
Rayagond

[Linuxptp-users] [announce] version 1.0 released

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

Dear linuxptp users and developers,

Today I pushed out a v1.0 tag and released a tar ball on SF.

The authors who contributed to this release are as follows.

Christian Riesch
Delio Brignoli
Eliot Blennerhassett
Jacob Keller
Miroslav Lichvar
Richard Cochran

Many thanks to all who gave feedback on the lists to those who
contributed to the development effort.

Enjoy,
Richard

Re: [Linuxptp-users] Time to make a 1.0 release?

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

On Fri, Dec 07, 2012 at 07:31:14PM +0000, Keller, Jacob E wrote:
>
> In terms of future list, I definitely would like to see Asymmetry correction at some point.

I thought this should be included in v1.0, and it wasn't too hard, so
I posted a patch today. Care to give it a try?

Thanks,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] Time to make a 1.0 release?

[Mario M. <Mar...@we...>]

+1 for an official release.

I am more than happy with it. 

Regards and thanks for all,
Mario

Re: [Linuxptp-users] Time to make a 1.0 release?

[Stephen T. <sgt...@au...>]

+1 release
------------------------
Stephen Turner
AudioScience, Inc.
+1-949-650-6263
www.audioscience.com

Re: [Linuxptp-users] [Linuxptp-devel] Time to make a 1.0 release?

[Stephan G. <ste...@gm...>]

+1 for an official release.

We use ptp4l in our products, its stable and we are more than happy with it.

Regards,

Stephan

Re: [Linuxptp-users] Time to make a 1.0 release?

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Friday, December 07, 2012 12:08 AM
> To: lin...@li...
> Cc: lin...@li...
> Subject: [Linuxptp-users] Time to make a 1.0 release?
> 
> Dear linuxptp users and developers,
> 
> Here some features that can wait for some future release, if demand
> appears for them:
> 
>   - Transparent clock.
>   - Asymmetry correction.
>   - Reading out individual data set elements via management messages.
>   - Reconfiguration (SET and COMMAND) via management messages.
>   - DeviceNET, ControlNET, and PROFINET transports.
>   - All other "optional" stuff, like unicast, alternate masters, and so on.
> 
> What do you all think, is it time for a release?
> Or should we even bother with numbered releases at all?
> 

+1 for release. I think the project is stable. I recently attended the last IEEE 1588 Plugfest, and many companies and people were still using ptpdv2 (with hacks for hardware timestamping) and had never heard of ptp4l or the linuxptp project. I think announcing an official release is definitely a good idea. None of the features on the future list are high priority, but I think as more people see the project they can definitely be implemented in the future.

Official release is definitely great for getting many users who would otherwise avoid it.

In terms of future list, I definitely would like to see Asymmetry correction at some point.

Thanks again!

- Jake

Re: [Linuxptp-users] Time to make a 1.0 release?

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

On Fri, Dec 07, 2012 at 09:08:29AM +0100, Richard Cochran wrote:
> 
> The following features have already been finished:
> 
>   - Hardware and software time stamping.
>   - Linux PTP Hardware Clock (PHC) subsystem, and
>     synchronizing the system clock to it.
>   - Boundary Clock and Ordinary Clock.
>   - IEEE 802.1AS-2011 in the role of end station.
>   - Transport over UDP/IPv4, UDP/IPv6, and raw Ethernet (Layer 2 and VLAN).
>   - Profile configuration via INI like files.
>   - Reading out of the data sets via management messages.
>   - Path trace TLV.
>   - Man pages.

Forgot to add:

   - Local IPC via UNIX Domain Sockets.
   - Simple management client.

Thanks,
Richard

[Linuxptp-users] Time to make a 1.0 release?

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

Dear linuxptp users and developers,

The project is now just over one year old, and everything on my todo
list has been implemented (or at least everything important to me).
We have had a few bugs fixed via the email lists, and there have also
been a number of nice improvements contributed over that last few
months.

Up until now I haven't released any tar ball on SF.net, and so I
wonder whether it is time to publish a 1.0 version. I think the
present state is quite useable and stable, and there haven't been any
bugs reported recently.

The following features have already been finished:

  - Hardware and software time stamping.
  - Linux PTP Hardware Clock (PHC) subsystem, and
    synchronizing the system clock to it.
  - Boundary Clock and Ordinary Clock.
  - IEEE 802.1AS-2011 in the role of end station.
  - Transport over UDP/IPv4, UDP/IPv6, and raw Ethernet (Layer 2 and VLAN).
  - Profile configuration via INI like files.
  - Reading out of the data sets via management messages.
  - Path trace TLV.
  - Man pages.

Here some features that can wait for some future release, if demand
appears for them:

  - Transparent clock.
  - Asymmetry correction.
  - Reading out individual data set elements via management messages.
  - Reconfiguration (SET and COMMAND) via management messages.
  - DeviceNET, ControlNET, and PROFINET transports.
  - All other "optional" stuff, like unicast, alternate masters, and so on.

What do you all think, is it time for a release?
Or should we even bother with numbered releases at all?

Thanks,
Richard

Re: [Linuxptp-users] PTP4L daemon seems to have a problem with to a link local address for IPv6

[Mario M. <Mar...@we...>]

----- Original Message ----- 
From: "Richard Cochran" <ric...@gm...>
To: "Mario Molitor" <mar...@we...>
Cc: <lin...@li...>
Sent: Sunday, November 25, 2012 8:36 PM
Subject: Re: [Linuxptp-users] PTP4L daemon seems to have a problem with to a 
link local address for IPv6


> On Fri, Nov 23, 2012 at 03:33:03PM +0100, Mario Molitor wrote:
>> Hallo Richard,
>> I have make a observation that the PTP4L daemon seems to have a problem 
>> with to a link local address for IPv6 .
>> For IPV6 tests I have changed PTP_PRIMARY_MCAST_IP6ADDR  to a link local 
>> address.
>> (#define PTP_PRIMARY_MCAST_IP6ADDR "FF02:0:0:0:0:0:0:181")
>> After this change I have saw that the communication  and explicit the 
>> udp6_send didn't work.
>
> Mario,
>
> I just pushed out a few changes for IPv6 transport. Now you can set
> the scope in the configuration file. Please give the new code a try.
>
> Thanks,
> Richard

Richard,
Sorry for the late response, but now I will send my result.
Many thanks for your great job, now it works as expected and I am also very 
happy that the user can modify the scope of address in configuration file.
I have also made same observation as you with scope-id by link local 
communication and my googling was with same result.
Thanks and have nice day tommorw,
Mario

Re: [Linuxptp-users] PTP4L daemon seems to have a problem with to a link local address for IPv6

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

On Fri, Nov 23, 2012 at 03:33:03PM +0100, Mario Molitor wrote:
> Hallo Richard,
> I have make a observation that the PTP4L daemon seems to have a problem with to a link local address for IPv6 .
> For IPV6 tests I have changed PTP_PRIMARY_MCAST_IP6ADDR  to a link local address.
> (#define PTP_PRIMARY_MCAST_IP6ADDR "FF02:0:0:0:0:0:0:181")
> After this change I have saw that the communication  and explicit the udp6_send didn't work.

Mario,

I just pushed out a few changes for IPv6 transport. Now you can set
the scope in the configuration file. Please give the new code a try.

Thanks,
Richard

Re: [Linuxptp-users] PTP4L daemon seems to have a problem with to a link local address for IPv6

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

On Sun, Nov 25, 2012 at 06:38:01AM +0100, Mario Molitor wrote:
> 
> >It looks like we will have to set sin6_scope_id for the Pdelay
> >messages in P2P mode in any case. I will do some testing on this to
> >find out.
> 
> Ok. Thanks

I tried IPv6 with the OTMC 100, and it sends using site-local (0x5)
scope. So I hacked that in like

   #define PTP_PRIMARY_MCAST_IP6ADDR "FF05:0:0:0:0:0:0:181"

and it worked fine for me, both E2E and P2P mode.

The Pdelay messages still work even though addr.sin6_scope_id was set
to zero, while the actual interface index was three. Strange.

I will make a few changes to fix this up:

1. clear the ipv6 address structure.
2. remember the interface index.
3. set addr.sin6_scope_id for Pdelay messages.
4. add an option to specify the ipv6 scope, and
   set addr.sin6_scope_id when appropriate

Thanks,
Richard

Re: [Linuxptp-users] PTP4L daemon seems to have a problem with to a link local address for IPv6

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

On Sun, Nov 25, 2012 at 06:38:01AM +0100, Mario Molitor wrote:
> >>For IPV6 tests I have changed PTP_PRIMARY_MCAST_IP6ADDR  to a
> >>link local address.
> >>(#define PTP_PRIMARY_MCAST_IP6ADDR "FF02:0:0:0:0:0:0:181")
> >
> >Why do you think this should be a link local address?
> 
> used the local scope in order to use only modules in a closed
> network segments.

But I think using link-local doesn't make sense for E2E.

Won't it prevent operation through a transparent switch or a non-BC
router?

Also, even if you are using directly connected PTP nodes, I would
think that using global scope should still work.

> >(I chose the global scope in order to maximise the chance of reaching
> >a master when running slave, and vice versa. I confess that I don't
> >really know what scope is correct to use here.
> 
> This is correct and makes sense.
> But in some cases maybe would like the user change this, but this is
> not the point at the moment.

If changing the scope is needed, then the udp6.c code will have to
behave differently depending on the scope. Setting the sin6_scope_id
non-zero only makes sense for link-local.

I read up on the scope field in IPv6 multicast addresses (Stevens, the
man page, and a bit of googling), and it might present a bit of a
problem. Each combination of scope and mcast addresses is a unqiue
group, so a general IPv6 client would have to join *all* of the groups
in order to find the server.

Thanks,
Richard