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

[Linuxptp-users] List of Boundary clocks

[Mozhdeh K. <mo...@us...>]

Hi,

I am new in Linux PTP project, I hope you can help me in using this
project.

Can anyone help me with the list of boundary clocks?I wonder whether
boundary clocks are simple switch with hardware time stamping? what special
characteristics it must have?

Than you.

BR,
*Mozhdeh *

[Linuxptp-users] List of Boundary clocks

[Mozhdeh K. <kam...@gm...>]

Hi,

I am new in Linux PTP project. Can anyone help me with the list of boundary
clocks?

I wonder whether boundary clocks are simple switch with hardware time
stamping? what special characteristics it must have?

Than you.

BR,
*Mozhdeh *

Re: [Linuxptp-users] Xilinx Ethernet Lite does not support multicast packets

[nicolas l. <nic...@ub...>]

Hi Richard,

Thank you for the quick response.

Unfortunately it seem that not :
         "The EMACLite does not support promiscuous mode, and it always
accepts unicast and broadcast packets. "
>From : http://www.origin.xilinx.com/support/answers/17124.htm

I think we will try to implement another MAC API.

Nicolas

Le 19/03/2013 19:32, Richard Cochran a écrit :
> On Tue, Mar 19, 2013 at 03:07:03PM +0100, nicolas lantz wrote:
>> "Xilinx Ethernet Lite"  is marked as supporting PHY (and other)
>> timestamping in the Driver Support Matrix.
>> But according to data-sheet : "The Ethernet Lite MAC core does not
>> support multicast packets."
> Maybe they mean that there is no multicast filtering. I expect, at the
> very least, you should be able to run in promiscuous mode.
>  
>> I try to get it working with a DP83640 PHY since three weeks, but
>> without multicast support I now wonder how this would be possible.
>> But why the emaclite drivers implements "skb_defer_rx_timestamp(skb)"
>> function in the "xemaclite_rx_handler()" and
>> "skb_tx_timestamp(new_skb)"  in   the "xemaclite_send" (
>> .ndo_start_xmit) if it could not be usable ?
>> there is something I've missed ?
> I added the hooks to this MAC driver because it makes use of phylib,
> and it therefore can support a time stamping PHY. However, I never
> testing this, since I don't have access to this hardware.
>
> Anyhow, I would be surprised if the MAC prevents you sending and
> receiving multicast packets.
>
> HTH,
> Richard

Re: [Linuxptp-users] can't get linux PTP to run

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

Yes. You first of all need to determine which /dev/ptp device you are supposed to use.

Can you show me the command you use  to run ptp4l?

Second, you may need to modify the config file to increase the tx_retries value in the config file (and pass that config to ptp4l's command option)

Basically, the part may not be returning the tx timestamp on the socket fast enough. If you increase the tx_retries count to a fair bit higher that may resolve the particular error.

- Jake

> -----Original Message-----
> From: Tim...@de... [mailto:Tim-
> Ben...@de...]
> Sent: Tuesday, March 19, 2013 1:42 AM
> To: lin...@li...
> Subject: Re: [Linuxptp-users] can't get linux PTP to run
> 
> First of all thanks for your help.
> 
> >There may be a kernel module released on sourceforge with support  if
> you don't need in-kernel driver, this should >work with the PTP
> framework in 3.2
> 
> >http://sourceforge.net/projects/e1000/files/e1000e%20stable/
> 
> Now I have set up this driver and compiled it with PTP support but there
> is nothing different than before still
> 
> ptp4l[98.033]: port 1: get_ts_info not supported
> ptp4l[98.035]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[98.035]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[104.035]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[105.041]: recvmsg tx timestamp failed: Resource temporarily
> unavailable
> ptp4l[105.041]: port 1: send sync failed
> ptp4l[105.041]: port 1: MASTER to FAULTY on FAULT_DETECTED
> ptp4l[121.043]: port 1: FAULTY to LISTENING on FAULT_CLEARED
> ptp4l[127.043]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[128.049]: recvmsg tx timestamp failed: Resource temporarily
> unavailable
> 
> As you can see below that the new driver is working:
> 
> ~$ ethtool -i eth2
> driver: e1000e
> version: 2.3.2-NAPI
> firmware-version: 2.1-2
> bus-info: 0000:07:00.0
> 
> changing the kernel to 3.5 or 3.9 would take a lot of time because a lot
> of realtime support is bound into it. So I would prefer staying on 3.2.
> 
> Is there something I still can try?
> 
> Thanks,
> Benny
> 
> -----Ursprüngliche Nachricht-----
> Von: Keller, Jacob E [mailto:jac...@in...]
> Gesendet: Freitag, 15. März 2013 17:33
> An: Richard Cochran; Rapp, Tim-Benjamin
> Cc: lin...@li...
> Betreff: RE: [Linuxptp-users] can't get linux PTP to run
> 
> > -----Original Message-----
> > From: Richard Cochran [mailto:ric...@gm...]
> > Sent: Friday, March 15, 2013 8:37 AM
> > To: Tim...@de...
> > Cc: lin...@li...
> > Subject: Re: [Linuxptp-users] can't get linux PTP to run
> >
> > On Fri, Mar 15, 2013 at 01:24:16PM +0000, Tim-
> > Ben...@de... wrote:
> >
> > > I'm using a custom x86 3.2.37 Kernel with Real Time support. I'm
> > > using an "e1000e Intel 82574" with should be supported.
> >
> > The e1000e driver will have PHC and HW timestamping in kernel 3.9,
> and
> > it has SW time stamping as of kernel 3.5. So it is not supported on
> > your kernel version.
> >
> > The easiest way to get going with your 3.2 kernel is to back port the
> > SW time stamping patch.
> >
> > [ See the table of supported hardware at the linuxptp home page. ]
> >
> > HTH,
> > Richard
> >
> >
> 
> >There may be a kernel module released on sourceforge with support  if
> you don't need in-kernel driver, this should >work with the PTP
> framework in 3.2
> 
> >http://sourceforge.net/projects/e1000/files/e1000e%20stable/
> 
> >- Jake
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Xilinx Ethernet Lite does not support multicast packets

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

On Tue, Mar 19, 2013 at 03:07:03PM +0100, nicolas lantz wrote:
> 
> "Xilinx Ethernet Lite"  is marked as supporting PHY (and other)
> timestamping in the Driver Support Matrix.
> But according to data-sheet : "The Ethernet Lite MAC core does not
> support multicast packets."

Maybe they mean that there is no multicast filtering. I expect, at the
very least, you should be able to run in promiscuous mode.
 
> I try to get it working with a DP83640 PHY since three weeks, but
> without multicast support I now wonder how this would be possible.
> But why the emaclite drivers implements "skb_defer_rx_timestamp(skb)"
> function in the "xemaclite_rx_handler()" and
> "skb_tx_timestamp(new_skb)"  in   the "xemaclite_send" (
> .ndo_start_xmit) if it could not be usable ?
> there is something I've missed ?

I added the hooks to this MAC driver because it makes use of phylib,
and it therefore can support a time stamping PHY. However, I never
testing this, since I don't have access to this hardware.

Anyhow, I would be surprised if the MAC prevents you sending and
receiving multicast packets.

HTH,
Richard

[Linuxptp-users] Xilinx Ethernet Lite does not support multicast packets

[nicolas l. <nic...@ub...>]

Hello,

"Xilinx Ethernet Lite"  is marked as supporting PHY (and other)
timestamping in the Driver Support Matrix.
But according to data-sheet : "The Ethernet Lite MAC core does not
support multicast packets."

I try to get it working with a DP83640 PHY since three weeks, but
without multicast support I now wonder how this would be possible.
But why the emaclite drivers implements "skb_defer_rx_timestamp(skb)"
function in the "xemaclite_rx_handler()" and
"skb_tx_timestamp(new_skb)"  in   the "xemaclite_send" (
.ndo_start_xmit) if it could not be usable ?
there is something I've missed ?

Thanks

Nicolas

[Linuxptp-users] Xilinx Ethernet Lite does not support multicast packets

[nicolas l. <nic...@ub...>]

Hello,

"Xilinx Ethernet Lite"  is marked as supporting PHY (and other)
timestamping in the Driver Support Matrix.
But according to data-sheet : "The Ethernet Lite MAC core does not
support multicast packets."

I try to get it working with a DP83640 PHY since three weeks, but
without multicast support I now wonder how this would be possible.
But why the emaclite drivers implements "skb_defer_rx_timestamp(skb)"
function in the "xemaclite_rx_handler()" and
"skb_tx_timestamp(new_skb)"  in   the "xemaclite_send" (
.ndo_start_xmit) if it could not be usable ?
there is something I've missed ?

Thanks

Nicolas

-- 

Nicolas Lantz
R&D - Systèmes embarqués
Android, Linux, systèmes inertiels.

nic...@ub...
Tél : +33 (0)9 52 96 81 86 / 06 19 07 43 43
-
UBICORE
28 rue d'Alpignano, 38600 FONTAINE
www.ubicore.net

Re: [Linuxptp-users] can't get linux PTP to run

[<Tim...@de...>]

First of all thanks for your help.

>There may be a kernel module released on sourceforge with support  if you don't need in-kernel driver, this should >work with the PTP framework in 3.2

>http://sourceforge.net/projects/e1000/files/e1000e%20stable/

Now I have set up this driver and compiled it with PTP support but there is nothing different than before still 

ptp4l[98.033]: port 1: get_ts_info not supported
ptp4l[98.035]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[98.035]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[104.035]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[105.041]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[105.041]: port 1: send sync failed
ptp4l[105.041]: port 1: MASTER to FAULTY on FAULT_DETECTED
ptp4l[121.043]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[127.043]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[128.049]: recvmsg tx timestamp failed: Resource temporarily unavailable

As you can see below that the new driver is working:

~$ ethtool -i eth2
driver: e1000e
version: 2.3.2-NAPI
firmware-version: 2.1-2
bus-info: 0000:07:00.0

changing the kernel to 3.5 or 3.9 would take a lot of time because a lot of realtime support is bound into it. So I would prefer staying on 3.2. 

Is there something I still can try?

Thanks, 
Benny

-----Ursprüngliche Nachricht-----
Von: Keller, Jacob E [mailto:jac...@in...] 
Gesendet: Freitag, 15. März 2013 17:33
An: Richard Cochran; Rapp, Tim-Benjamin
Cc: lin...@li...
Betreff: RE: [Linuxptp-users] can't get linux PTP to run

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Friday, March 15, 2013 8:37 AM
> To: Tim...@de...
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] can't get linux PTP to run
> 
> On Fri, Mar 15, 2013 at 01:24:16PM +0000, Tim- 
> Ben...@de... wrote:
> 
> > I'm using a custom x86 3.2.37 Kernel with Real Time support. I'm 
> > using an "e1000e Intel 82574" with should be supported.
> 
> The e1000e driver will have PHC and HW timestamping in kernel 3.9, and 
> it has SW time stamping as of kernel 3.5. So it is not supported on 
> your kernel version.
> 
> The easiest way to get going with your 3.2 kernel is to back port the 
> SW time stamping patch.
> 
> [ See the table of supported hardware at the linuxptp home page. ]
> 
> HTH,
> Richard
> 
> 

>There may be a kernel module released on sourceforge with support  if you don't need in-kernel driver, this should >work with the PTP framework in 3.2

>http://sourceforge.net/projects/e1000/files/e1000e%20stable/ 

>- Jake

Re: [Linuxptp-users] can't get linux PTP to run

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Friday, March 15, 2013 8:37 AM
> To: Tim...@de...
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] can't get linux PTP to run
> 
> On Fri, Mar 15, 2013 at 01:24:16PM +0000, Tim-
> Ben...@de... wrote:
> 
> > I'm using a custom x86 3.2.37 Kernel with Real Time support. I'm
> > using an "e1000e Intel 82574" with should be supported.
> 
> The e1000e driver will have PHC and HW timestamping in kernel 3.9,
> and
> it has SW time stamping as of kernel 3.5. So it is not supported on
> your kernel version.
> 
> The easiest way to get going with your 3.2 kernel is to back port the
> SW time stamping patch.
> 
> [ See the table of supported hardware at the linuxptp home page. ]
> 
> HTH,
> Richard
> 
> 

There may be a kernel module released on sourceforge with support  if you don't need in-kernel driver, this should work with the PTP framework in 3.2

http://sourceforge.net/projects/e1000/files/e1000e%20stable/ 

- Jake

Re: [Linuxptp-users] can't get linux PTP to run

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

On Fri, Mar 15, 2013 at 01:24:16PM +0000, Tim...@de... wrote:

> I'm using a custom x86 3.2.37 Kernel with Real Time support. I'm
> using an "e1000e Intel 82574" with should be supported.

The e1000e driver will have PHC and HW timestamping in kernel 3.9, and
it has SW time stamping as of kernel 3.5. So it is not supported on
your kernel version.

The easiest way to get going with your 3.2 kernel is to back port the
SW time stamping patch.

[ See the table of supported hardware at the linuxptp home page. ]

HTH,
Richard

[Linuxptp-users] can't get linux PTP to run

[<Tim...@de...>]

Hi,

I'm having trouble to get started with LinuxPPT.

I'm using a custom x86 3.2.37 Kernel with Real Time support. I'm using an "e1000e Intel 82574" with should be supported.


I activated :
    <M> PPS support
     [*]   PPS debugging messages
     [*]   PPS kernel consumer support
       *** PPS clients support ***
  <M>   Kernel timer client (Testing client, use for debug)
  <M>   PPS line discipline
  <M>   Parallel port PPS client
  <M>   PPS client using GPIO
       *** PPS generators support ***
and

<M> PTP clock support
         *** Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional


After installing I've tried to get started with creating a Master  using "$ ptp4l -S -i eth2 -m -q" but I get the errors:

ptp4l[14927.233]: port 1: get_ts_info not supported
ptp4l[14927.235]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[14927.235]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[14933.235]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[14934.242]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[14934.242]: port 1: send sync failed
ptp4l[14934.242]: port 1: MASTER to FAULTY on FAULT_DETECTED
ptp4l[14950.245]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[14956.245]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[14957.252]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[14957.252]: port 1: send sync failed
ptp4l[14957.252]: port 1: MASTER to FAULTY on FAULT_DETECTED
ptp4l[14973.254]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[14979.254]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
...

or :

$ ptp4l -i eth2 -L -m
ptp4l[314.690]: port 1: get_ts_info not supported
ptp4l[314.692]: driver rejected most general HWTSTAMP filter
ptp4l[314.692]: ioctl SIOCSHWTSTAMP failed: Operation not supported
ptp4l[314.693]: port 1: INITIALIZING to FAULTY on INITIALIZE
ptp4l[314.693]: port 0: INITIALIZING to LISTENING on INITIALIZE


And on the slave "ptp4l -S -i eth2 -s -m -q"

ptp4l[14964.111]: port 1: get_ts_info not supported
ptp4l[14964.113]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[14964.113]: port 0: INITIALIZING to LISTENING on INITIALIZE

what am I doing wrong?  In /dev/ there is no ptp device.

Would be nice if someone can give me a hint.

Cheers
B.Rapp

Re: [Linuxptp-users] problem with version 1.1

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

On Mon, Mar 04, 2013 at 05:09:09PM +0100, Álvaro Bustos wrote:
> For simple testing the software I ran ">sudo phc2sys -d /dev/pps0" and it
> started running:
> 
> pps   (offset)   (servo_state)   (sec).(nanosec)   drift   (servo_drift)
> 
> If I desinstall the version 1.0 and I do the same for linuxptp version 1.1
> nothing works, it is possible that I've done something wrong.
> 
> Any ideas?

There is a difference which could explain why you don't see any output
from phc2sys. Since 1.1, the default is now to send messages to
syslog, to log to stdout/stderr you need use the -m option, similarly
to ptp4l.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] problem with version 1.1

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

On Mon, Mar 04, 2013 at 05:09:09PM +0100, Álvaro Bustos wrote:
> Hello,
> 
> I'm a beginner in ptp and 1588, I've download some time ago the linuxptp
> version 1.0 and I compiled and try to run it on an Ubuntu 12.10 64bits
> modified to enable pps and ptp, for now Im only trying to implement
> software timestamping.. I compiled it typing "make" and after, typing "sudo
> make install".
> 
> For simple testing the software I ran ">sudo phc2sys -d /dev/pps0" and it
> started running:

If you are using software time stamping, then you will not need
phc2sys at all. In the case of SW time stamping, the ptp4l program
adjusts the Linux system clock directly.

HTH,
Richard

[Linuxptp-users] problem with version 1.1

[Álvaro B. <alv...@al...>]

Hello,

I'm a beginner in ptp and 1588, I've download some time ago the linuxptp
version 1.0 and I compiled and try to run it on an Ubuntu 12.10 64bits
modified to enable pps and ptp, for now Im only trying to implement
software timestamping.. I compiled it typing "make" and after, typing "sudo
make install".

For simple testing the software I ran ">sudo phc2sys -d /dev/pps0" and it
started running:

pps   (offset)   (servo_state)   (sec).(nanosec)   drift   (servo_drift)

If I desinstall the version 1.0 and I do the same for linuxptp version 1.1
nothing works, it is possible that I've done something wrong.

Any ideas?

Thanks for all,

Álvaro Bustos, Universidad Politécnica de Madrid.

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

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

Hi Richard and Jacob,

Its working now :-) :-).

As you mentioned last week, the timestmp value were getting corrupted
because of bug in driver ie device updates the time stamp in terms of
seconds and nanoseconds, in the driver I was not converting the second part
to nano second instead I was just shifting the second by 32 and passing the
64-bit value to ns_to_ktime().

old code(buggy code)
---------------------------
ns = hw_if->get_tx_tstamp_low(txdesc);
ns |= hw_if->get_tx_tstamp_high(txdesc);

shhwtstamp.hwtstamp = ns_to_ktime(ns);

new code
------------
ns = hw_if->get_tx_tstamp_low(txdesc);
ns += hw_if->get_tx_tstamp_high(txdesc) * 1000000000ULL;

shhwtstamp.hwtstamp = ns_to_ktime(ns);

Thank you very much Richard and Jacob, without your help I couldn't have
completed this.

Now, I will work on extended feature like PPS.

WWR
Rayagond.


On 9 February 2013 19:19, Richard Cochran <ric...@gm...> wrote:

> On Sat, Feb 09, 2013 at 06:22:51PM +0530, Rayagond Kokatanur wrote:
> >
> > So once SLAVE sync to MASTER then ptp stack should not call .adjfreq api
> > right, unless there is change in MASTER time.
>
> No, the slave will continuously adjust its frequency to track the
> master.
>
> > But how 0xF0000029 value wrt 66MHz clock ?
>
> ifr=66666666            # input frequency
> nfr=62500000            # nominal frequency
> fdr=ifr/nfr             # frequency division ratio
> addend=ceil(2^32/fdr)
>
> So addend is 4026531881 or 0xF0000029.
>
> > In our device the way driver need to update the ADDEND registers is same
> as
> > ixp device ie (2^32)/freq_ratio, where freq_ratio =
> ptp_clock_freq/50000000.
> >
> > So in my case ptp clock freq or system clock freq is 62.5MHz, so DEFAULT
> > value i am taking is = ((2^32) * 50000000)/62500000 = 0xCCCCCC.
> >
> > Is my default addend value correct ?
>
> With ifr=62500000 and nfr=50000000, then addend is 0xCCCCCCCD, and
> max_adj is 249999999.
>
> But, then again, I don't know anything about your hardware. You will
> have to confirm the correct values yourself (or publish your data
> sheet).
>
> HTH,
> Richard
>

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

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

On Sat, Feb 09, 2013 at 06:22:51PM +0530, Rayagond Kokatanur wrote:
> 
> So once SLAVE sync to MASTER then ptp stack should not call .adjfreq api
> right, unless there is change in MASTER time.

No, the slave will continuously adjust its frequency to track the
master.
 
> But how 0xF0000029 value wrt 66MHz clock ?

ifr=66666666		# input frequency
nfr=62500000		# nominal frequency
fdr=ifr/nfr		# frequency division ratio
addend=ceil(2^32/fdr)

So addend is 4026531881 or 0xF0000029.

> In our device the way driver need to update the ADDEND registers is same as
> ixp device ie (2^32)/freq_ratio, where freq_ratio = ptp_clock_freq/50000000.
> 
> So in my case ptp clock freq or system clock freq is 62.5MHz, so DEFAULT
> value i am taking is = ((2^32) * 50000000)/62500000 = 0xCCCCCC.
> 
> Is my default addend value correct ?

With ifr=62500000 and nfr=50000000, then addend is 0xCCCCCCCD, and
max_adj is 249999999.

But, then again, I don't know anything about your hardware. You will
have to confirm the correct values yourself (or publish your data
sheet).

HTH,
Richard

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

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

On 9 February 2013 17:21, Richard Cochran <ric...@gm...> wrote:

> On Sat, Feb 09, 2013 at 04:13:08PM +0530, Rayagond Kokatanur wrote:
> >
> > What is max_adj value ? Is it a maximum clock frequency connect to my
> > MAC/PTP ?
>
> No.
>
> It is maximum adjustment (in parts per billion) tolerated by your
> clock. If your clock can accept an adjustment 0.1%, then max_adj
> will be 1000000.
>

okay, I will check with HW team and assign correct value.


>
> > Whenever ptp4l calls .adjfreq, it passes either +/1 .max_adj frequency to
> > .adjfreq api, why ?
>
> Because the servo is trying to steer the clock at the maximum possible
> rate. Probably your time stamps are messed up.
>

So once SLAVE sync to MASTER then ptp stack should not call .adjfreq api
right, unless there is change in MASTER time.


> > 2> DEFAULT_ADDEND = 0xF0000029
> >
> > What is this magic number ?
>
> The ixp featues a frequency compenstated clock, with input clock at
> 66 MHz. Every input clock, the addend is accumulated into a 32 bit
> register. When that register overflows, it produces one clock tick at
> the nominal frequency of 62.5 MHz. Changing the addend makes the clock
> go faster or slower.
>

But how 0xF0000029 value wrt 66MHz clock ?

In our device the way driver need to update the ADDEND registers is same as
ixp device ie (2^32)/freq_ratio, where freq_ratio = ptp_clock_freq/50000000.

So in my case ptp clock freq or system clock freq is 62.5MHz, so DEFAULT
value i am taking is = ((2^32) * 50000000)/62500000 = 0xCCCCCC.

Is my default addend value correct ?


> > Is it calculated based on max_adj frequency
> > value ?
>
> No, it is the other way round.
>
> HTH,
> Richard
>


Thanks and Regards
Rayagond

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

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

On Sat, Feb 09, 2013 at 04:13:08PM +0530, Rayagond Kokatanur wrote:
> 
> What is max_adj value ? Is it a maximum clock frequency connect to my
> MAC/PTP ?

No.

It is maximum adjustment (in parts per billion) tolerated by your
clock. If your clock can accept an adjustment 0.1%, then max_adj
will be 1000000.

> Whenever ptp4l calls .adjfreq, it passes either +/1 .max_adj frequency to
> .adjfreq api, why ?

Because the servo is trying to steer the clock at the maximum possible
rate. Probably your time stamps are messed up.

> 2> DEFAULT_ADDEND = 0xF0000029
> 
> What is this magic number ? 

The ixp featues a frequency compenstated clock, with input clock at
66 MHz. Every input clock, the addend is accumulated into a 32 bit
register. When that register overflows, it produces one clock tick at
the nominal frequency of 62.5 MHz. Changing the addend makes the clock
go faster or slower.

> Is it calculated based on max_adj frequency
> value ?

No, it is the other way round.

HTH,
Richard

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

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

Hi Richard and Jacob,

I am able to proceed further there were couple for programming bugs in my
.adjfreq and .adjtime api's.

Now am able to sync to MASTER time but its not so accurate, there is still
one minute difference between MASTER and SLAVE. MASTER is one minute ahead
than SLAVE.

Also I referred INTEL ptp clock driver(ppt_ixp46x.c) and I am not able to
understand two points,

1> .max_adj = 66666655

What is max_adj value ? Is it a maximum clock frequency connect to my
MAC/PTP ?
Whenever ptp4l calls .adjfreq, it passes either +/1 .max_adj frequency to
.adjfreq api, why ?

In my case, I am using 62.5MHz clock, so I specified .max_freq = 62500000.

2> DEFAULT_ADDEND = 0xF0000029

What is this magic number ? Is it calculated based on max_adj frequency
value ?


Thanks and Regards,
Rayagond




On 7 February 2013 14:14, Richard Cochran <ric...@gm...> wrote:

> On Thu, Feb 07, 2013 at 12:28:30PM +0530, Rayagond Kokatanur wrote:
> >
> > How to verify that time stamp are working with my driver ?
>
> How about this:
>
> 1. Send sync messages to the device at the rate of once per second.
> 2. Print out the received time stamps and verify that they are about
>    one second apart.
>
> Then repeat the excercise for the delay request message transmission.
>
> Also, you should try the Linux kernel test program in
> Documentation/networking/timestamping.
>
> > I send time stamp like this to stack,
> >
> > 1. read the tx/rx timestamp low and high value into "u64 ns;" variable.
> > 2. convert the raw timstamp value to ktime using - "ns_to_ktime()" api.
> > 3. assign the converted value to .hwtstamp field of struct
> > skb_shared_hwtstamps struct.
> > 3. finally pass the struct skb_shared_hwtstamps to stack.
> >
> > I am not manipulating other field of struct skb_shared_hwtstamps ie
> syststamp.
> >
> > Also I have configured device to capture time stamp for all received
> packets.
> >
> > Please let me if my procedure is wrong ?
>
> Sounds okay, but you have not shown us any code, so you never know.
> I encourage you to post your driver on the Linux netdev list.
>
> HTH,
> Richard
>

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

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

On Thu, Feb 07, 2013 at 12:28:30PM +0530, Rayagond Kokatanur wrote:
> 
> How to verify that time stamp are working with my driver ?

How about this:

1. Send sync messages to the device at the rate of once per second.
2. Print out the received time stamps and verify that they are about
   one second apart.

Then repeat the excercise for the delay request message transmission.

Also, you should try the Linux kernel test program in
Documentation/networking/timestamping.

> I send time stamp like this to stack,
> 
> 1. read the tx/rx timestamp low and high value into "u64 ns;" variable.
> 2. convert the raw timstamp value to ktime using - "ns_to_ktime()" api.
> 3. assign the converted value to .hwtstamp field of struct
> skb_shared_hwtstamps struct.
> 3. finally pass the struct skb_shared_hwtstamps to stack.
> 
> I am not manipulating other field of struct skb_shared_hwtstamps ie syststamp.
> 
> Also I have configured device to capture time stamp for all received packets.
> 
> Please let me if my procedure is wrong ?

Sounds okay, but you have not shown us any code, so you never know.
I encourage you to post your driver on the Linux netdev list.

HTH,
Richard

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

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

On 06/02/2013, Richard Cochran <ric...@gm...> wrote:
> On Wed, Feb 06, 2013 at 07:40:29PM +0530, Rayagond Kokatanur wrote:
>
>> Following are log message on SLAVE side,
> ...
>> ptp4l[3529.856]: negative path delay -273111420
>> ptp4l[3529.856]: path_delay = (t2 - t3) + (t4 - t1)
>> ptp4l[3529.856]: t2 - t3 = -1331967748
>> ptp4l[3529.856]: t4 - t1 = +785744908
>> ptp4l[3529.856]: c1          0
>> ptp4l[3529.856]: c2          0
>> ptp4l[3529.856]: c3          0
>> ptp4l[3530.070]: master offset -1360149853961689539 s0 adj      +0 path
>> delay -273111420
>
> It looks like your driver's time stamps are not correct. Have you
> verified that the time stamps are working with your driver?

How to verify that time stamp are working with my driver ?

I send time stamp like this to stack,

1. read the tx/rx timestamp low and high value into "u64 ns;" variable.
2. convert the raw timstamp value to ktime using - "ns_to_ktime()" api.
3. assign the converted value to .hwtstamp field of struct
skb_shared_hwtstamps struct.
3. finally pass the struct skb_shared_hwtstamps to stack.

I am not manipulating other field of struct skb_shared_hwtstamps ie syststamp.

Also I have configured device to capture time stamp for all received packets.

Please let me if my procedure is wrong ?

Thank you

Rayagond

> Richard
>

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

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

Yes. It looks like you've got incorrect stamps for some of those, or some of the operations aren't correct.

You should see log output similar to 
ptp4l[3530.070]: master offset -1360149853961689539 s0 adj      +0 path

Except that the master offset field should shrink, and adj should increase to a small value and stabilize. Also path should show the path delay value

Those fields are displayed in nanoseconds, and you shouldn't see many other messages in between. Certainly negative path delay should correct itself quickly unlike what you are seeing.

- Jake

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Wednesday, February 06, 2013 9:04 AM
> To: Rayagond Kokatanur
> Cc: Keller, Jacob E; lin...@li...
> Subject: Re: [Linuxptp-users] recvmsg tx timestamp failed: Resource
> temporarily unavailable
> 
> On Wed, Feb 06, 2013 at 07:40:29PM +0530, Rayagond Kokatanur wrote:
> 
> > Following are log message on SLAVE side,
> ...
> > ptp4l[3529.856]: negative path delay -273111420
> > ptp4l[3529.856]: path_delay = (t2 - t3) + (t4 - t1)
> > ptp4l[3529.856]: t2 - t3 = -1331967748
> > ptp4l[3529.856]: t4 - t1 = +785744908
> > ptp4l[3529.856]: c1          0
> > ptp4l[3529.856]: c2          0
> > ptp4l[3529.856]: c3          0
> > ptp4l[3530.070]: master offset -1360149853961689539 s0 adj      +0 path
> delay -273111420
> 
> It looks like your driver's time stamps are not correct. Have you
> verified that the time stamps are working with your driver?
> 
> Richard

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

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

On Wed, Feb 06, 2013 at 07:40:29PM +0530, Rayagond Kokatanur wrote:

> Following are log message on SLAVE side,
...
> ptp4l[3529.856]: negative path delay -273111420
> ptp4l[3529.856]: path_delay = (t2 - t3) + (t4 - t1)
> ptp4l[3529.856]: t2 - t3 = -1331967748
> ptp4l[3529.856]: t4 - t1 = +785744908
> ptp4l[3529.856]: c1          0
> ptp4l[3529.856]: c2          0
> ptp4l[3529.856]: c3          0
> ptp4l[3530.070]: master offset -1360149853961689539 s0 adj      +0 path delay -273111420

It looks like your driver's time stamps are not correct. Have you
verified that the time stamps are working with your driver?

Richard

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

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

Hi Richard and Jacob,

I implemented the .adjfreq api and able to proceed further,

I am running following commands,

on MASTER side - $ptp4l -i eth0 -S -m  #using software time stamping

on SLAVE side - $ptp4l -i eth0 -p /dev/ptp0 -s -m  #using HW time stamping

-------------------------------------------------------------------------------------------------------------------
Following are log message on SLAVE side,

ptp4l[3522.327]: selected /dev/ptp0 as PTP clock
ptp4l[3522.329]: failed to read out the clock frequency adjustment:
Operation not supported
ptp4l[3522.329]: port 1: get_ts_info not supported
ptp4l[3522.441]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[3522.442]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[3524.070]: port 1: new foreign master f0def1.fffe.58de16-1
ptp4l[3528.070]: selected best master clock f0def1.fffe.58de16
ptp4l[3528.070]: foreign master not using PTP timescale
ptp4l[3528.070]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[3529.856]: negative path delay -273111420
ptp4l[3529.856]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[3529.856]: t2 - t3 = -1331967748
ptp4l[3529.856]: t4 - t1 = +785744908
ptp4l[3529.856]: c1          0
ptp4l[3529.856]: c2          0
ptp4l[3529.856]: c3          0
ptp4l[3530.070]: master offset -1360149853961689539 s0 adj      +0
path delay -273111420
ptp4l[3530.331]: negative path delay  -90547500
ptp4l[3530.331]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[3530.331]: t2 - t3 = -441936828
ptp4l[3530.331]: t4 - t1 = +260841828
ptp4l[3530.331]: c1          0
ptp4l[3530.331]: c2          0
ptp4l[3530.331]: c3          0
ptp4l[3531.072]: master offset -1360149853357181388 s1 adj +62500000
path delay -181829460
ptp4l[3532.070]: master offset 32568703630 s2 adj +62500000 path delay
-181829460
ptp4l[3532.171]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[3533.070]: master offset 33158496191 s2 adj +62500000 path delay
-181829460
ptp4l[3533.188]: negative path delay  -33997756
ptp4l[3533.188]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[3533.188]: t2 - t3 = -183932418
ptp4l[3533.188]: t4 - t1 = +115936906
ptp4l[3533.189]: c1          0
ptp4l[3533.189]: c2          0
ptp4l[3533.189]: c3          0
ptp4l[3534.070]: master offset 35846471099 s2 adj +62500000 path delay
-132552225
ptp4l[3535.070]: master offset 38583743154 s2 adj +62500000 path delay
-132552225
ptp4l[3535.172]: negative path delay  -29724058
ptp4l[3535.172]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[3535.172]: t2 - t3 = -160933322
ptp4l[3535.172]: t4 - t1 = +101485205
ptp4l[3535.173]: c1          0
ptp4l[3535.173]: c2          0
ptp4l[3535.173]: c3          0
ptp4l[3536.070]: master offset 41295290499 s2 adj +62500000 path delay
-106845183
ptp4l[3536.630]: negative path delay -164345682
ptp4l[3536.630]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[3536.630]: t2 - t3 = -886761310
ptp4l[3536.630]: t4 - t1 = +558069946
ptp4l[3536.630]: c1          0
ptp4l[3536.630]: c2          0
ptp4l[3536.630]: c3          0
ptp4l[3537.070]: master offset 41896592574 s2 adj +62500000 path delay
-118345283
ptp4l[3537.543]: negative path delay -1213019806
ptp4l[3537.543]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[3537.544]: t2 - t3 = -2899017982
ptp4l[3537.544]: t4 - t1 = +472978370
ptp4l[3537.544]: c1          0
ptp4l[3537.544]: c2          0
ptp4l[3537.544]: c3          0
ptp4l[3538.070]: master offset 44816281933 s2 adj +62500000 path delay
-300791037
ptp4l[3538.210]: negative path delay  -41005278
ptp4l[3538.210]: path_delay = (t2 - t3) + (t4 - t1)
ptp4l[3538.210]: t2 - t3 = -221749632
ptp4l[3538.210]: t4 - t1 = +139739075
ptp4l[3538.210]: c1          0
ptp4l[3538.210]: c2          0
ptp4l[3538.210]: c3          0
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
Following are the log message on MASTER side

ptp4l[12946.863]: port 1: get_ts_info not supported
ptp4l[12946.979]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[12946.980]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[12952.979]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
-------------------------------------------------------------------------------------------------------------------

PTP stack is calling my PHC driver api's like .adjfreq and .adjtime.

But now I am not able to understand the log message on SLAVE side, how
to know whether SALVE is synchronized to MASTER or not ?

I tried using phc2sys command ($phc2sys -s /dev/ptp0) to adjust the
system time to PHC time, but SLAVE system time didn't become equal to
MASTER system time ?

Please provide me more inputs on how to test further.

Thank you

Rayagond.

On 06/02/2013, Rayagond Kokatanur <ray...@gm...> wrote:
> 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

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

On 6 February 2013 02:08, Keller, Jacob E <jac...@in...> wrote:

> It's an error with Tx timestamping, and the most likely cause is that your
> driver is not returning the timestamp within the timeout.


Yes Jacob, my driver was not returning the tx timestamp within the timeout.
I am able to fix it. Thank you.


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