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

Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER questions

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

On Fri, May 31, 2013 at 11:10:13PM +0200, Drasko DRASKOVIC wrote:
> 
> I will have to analyze what differences for wrror queue driver makes
> when in AP and when in STA mode.

You are going to have to spend some time in order to understand the
Linux kernel wifi stack. I think no one on this list knows anything
about it.

I did stumble upon this site today:

   http://wireless.kernel.org/en/developers/Documentation/mac80211

Good luck,
Richard

Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER questions

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

> -----Original Message-----
> From: Drasko DRASKOVIC [mailto:dra...@gm...]
> Sent: Friday, May 31, 2013 2:10 PM
> To: Keller, Jacob E
> Cc: Richard Cochran; lin...@li...
> Subject: Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER
> questions
> 
> Hi Jake,

Hi Drasko,

> 
> On Fri, May 31, 2013 at 9:59 PM, Keller, Jacob E
> <jac...@in...> wrote:
> > Are you certain that you are using the same driver?
> Yes, I am pretty sure of this, because I am using my modified driver
> with bunch of printouts for debug.
> 
> > The error you are seeing here is due to poll timing out.
> I can see that poll hits the sk_tx_timeout TO in sk_receive(). I am as
> well suspecting on the way wireless stack works in Linux.
> 
> >The misleading error message has been fixed in the upstream git
> repository but I don't believe it has been released yet.
> This is not such a problem, code is really well written and easy to
> read. I can figure out what is happening now that I have starting to
> be a little familiar ;).
> 
> > That means that the tx timestamp isn't being returned within the
> timelimit meaning your driver is not actually getting the timestamp
> result.
> Exactly. Now that I understood methodolgy of timestamp passing within
> socket error queue (as explained here
> http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/Docume
> ntation/networking/timestamping.txt),
> I started tracing what happens on packet TX in the driver through here
> : http://lxr.free-electrons.com/source/net/core/skbuff.c?v=3.0#L3007
> and here: http://lxr.free-
> electrons.com/source/net/core/skbuff.c?v=3.0#L2986,
> and these functions seem to work fine (at least none returns with an
> error).
> 
> I have spotted one strange thing though - when I put my device in AP
> mode, I have logs like this :
> root@master:/linux-ptp# ./ptp4l -S -i wlan0 -m -l9
> ptp4l[62586.626]: port 1: get_ts_info not supported
> ptp4l[62586.630]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[62586.630]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[62592.630]: port 1: announce timeout
> ptp4l[62592.630]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[62593.630]: port 1: master sync timeout
> ptp4l[62593.630]: port 1: setting asCapable
> ptp4l[62594.630]: port 1: master tx announce timeout
> ptp4l[62594.631]: port 1: master sync timeout
> ptp4l[62595.631]: port 1: master sync timeout
> ptp4l[62596.631]: port 1: master tx announce timeout
> ptp4l[62596.631]: port 1: master sync timeout
> ptp4l[62597.631]: port 1: master sync timeout
> ...
> 
> which is rather good news, and means that TX timestamping works fine
> an ptp4l master started broadcasting anounce and sync messages.
> 
> However, when I put my wireless device in STA mode, I am getting logs
> like this :
> root@slave:~/linuxptp# ./ptp4l -S -i wlan0 -m -l9 -s
> ptp4l[7264.414]: port 1: get_ts_info not supported
> ptp4l[7264.424]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[7264.425]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[7264.772]: port 1: setting asCapable
> ptp4l[7264.773]: port 1: new foreign master deadbe.fffe.ef0000-1
> ptp4l[7270.424]: port 1: announce timeout
> ptp4l[7270.711]: selected best master clock deadbe.fffe.ef0000
> ptp4l[7270.711]: foreign master not using PTP timescale
> ptp4l[7270.711]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[7271.892]: port 1: delay timeout
> ptp4l[7271.894]: poll tx timestamp failed: Success
> ptp4l[7271.894]: port 1: send delay request failed
> ptp4l[7271.894]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED
> (FT_UNSPECIFIED)
> ptp4l[7271.896]: waiting 2^{4} seconds to clear fault on port 0
> 
> which would say that TX timestamping for some reason do not work
> (although same driver is used).
> 
> In STA mode I can still see that  kernel's skb_tstamp_tx() function is
> adequately called, as I explained earlier, and from my log I would say
> that I inserted skb_tx_timestamp() in the correct place (actually, I
> have put it here :
> https://github.com/garwedgess/ti-wlan/blob/master/compat-wireless-
> wl12xx/drivers/net/wireless/wl12xx/main.c#L1563,
> which seems to be driver's TX function).
> 

It is possibly due to the poll timeout which is set to 1. You could try to increase this. The value is for polling 1 second which it is possible in STA mode it actually takes longer than 1 second to transmit your packet? I am not familiar that much with wireless devices.. But you could attempt to see if setting sk_tx_timeout higher (should be a configuration option) works.

> I will have to analyze what differences for wrror queue driver makes
> when in AP and when in STA mode.
> 
> But at this point I would like to be sure that it is error queue
> problem, and I still have not found where to look for error type
> ENOENT that Richard was talking about, in order to confirm that it is
> error queue problem or something else.
> 
> Does anybody knows how I can check this (to confirm that wireless
> stack returns ENOENT)?

I do not know this, but you should be able to go up the polling stack to see where poll is waiting on and see what error you were getting there...?

- Jake

> 
> BR,
> Drasko

Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER questions

[Drasko D. <dra...@gm...>]

Hi Jake,

On Fri, May 31, 2013 at 9:59 PM, Keller, Jacob E
<jac...@in...> wrote:
> Are you certain that you are using the same driver?
Yes, I am pretty sure of this, because I am using my modified driver
with bunch of printouts for debug.

> The error you are seeing here is due to poll timing out.
I can see that poll hits the sk_tx_timeout TO in sk_receive(). I am as
well suspecting on the way wireless stack works in Linux.

>The misleading error message has been fixed in the upstream git repository but I don't believe it has been released yet.
This is not such a problem, code is really well written and easy to
read. I can figure out what is happening now that I have starting to
be a little familiar ;).

> That means that the tx timestamp isn't being returned within the timelimit meaning your driver is not actually getting the timestamp result.
Exactly. Now that I understood methodolgy of timestamp passing within
socket error queue (as explained here
http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/Documentation/networking/timestamping.txt),
I started tracing what happens on packet TX in the driver through here
: http://lxr.free-electrons.com/source/net/core/skbuff.c?v=3.0#L3007
and here: http://lxr.free-electrons.com/source/net/core/skbuff.c?v=3.0#L2986,
and these functions seem to work fine (at least none returns with an
error).

I have spotted one strange thing though - when I put my device in AP
mode, I have logs like this :
root@master:/linux-ptp# ./ptp4l -S -i wlan0 -m -l9
ptp4l[62586.626]: port 1: get_ts_info not supported
ptp4l[62586.630]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[62586.630]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[62592.630]: port 1: announce timeout
ptp4l[62592.630]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[62593.630]: port 1: master sync timeout
ptp4l[62593.630]: port 1: setting asCapable
ptp4l[62594.630]: port 1: master tx announce timeout
ptp4l[62594.631]: port 1: master sync timeout
ptp4l[62595.631]: port 1: master sync timeout
ptp4l[62596.631]: port 1: master tx announce timeout
ptp4l[62596.631]: port 1: master sync timeout
ptp4l[62597.631]: port 1: master sync timeout
...

which is rather good news, and means that TX timestamping works fine
an ptp4l master started broadcasting anounce and sync messages.

However, when I put my wireless device in STA mode, I am getting logs
like this :
root@slave:~/linuxptp# ./ptp4l -S -i wlan0 -m -l9 -s
ptp4l[7264.414]: port 1: get_ts_info not supported
ptp4l[7264.424]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[7264.425]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[7264.772]: port 1: setting asCapable
ptp4l[7264.773]: port 1: new foreign master deadbe.fffe.ef0000-1
ptp4l[7270.424]: port 1: announce timeout
ptp4l[7270.711]: selected best master clock deadbe.fffe.ef0000
ptp4l[7270.711]: foreign master not using PTP timescale
ptp4l[7270.711]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[7271.892]: port 1: delay timeout
ptp4l[7271.894]: poll tx timestamp failed: Success
ptp4l[7271.894]: port 1: send delay request failed
ptp4l[7271.894]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[7271.896]: waiting 2^{4} seconds to clear fault on port 0

which would say that TX timestamping for some reason do not work
(although same driver is used).

In STA mode I can still see that  kernel's skb_tstamp_tx() function is
adequately called, as I explained earlier, and from my log I would say
that I inserted skb_tx_timestamp() in the correct place (actually, I
have put it here :
https://github.com/garwedgess/ti-wlan/blob/master/compat-wireless-wl12xx/drivers/net/wireless/wl12xx/main.c#L1563,
which seems to be driver's TX function).

I will have to analyze what differences for wrror queue driver makes
when in AP and when in STA mode.

But at this point I would like to be sure that it is error queue
problem, and I still have not found where to look for error type
ENOENT that Richard was talking about, in order to confirm that it is
error queue problem or something else.

Does anybody knows how I can check this (to confirm that wireless
stack returns ENOENT)?

BR,
Drasko

Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER questions

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

> -----Original Message-----
> From: Drasko DRASKOVIC [mailto:dra...@gm...]
> Sent: Friday, May 31, 2013 8:32 AM
> To: Richard Cochran
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER
> questions
> 
> On Fri, May 31, 2013 at 4:09 PM, Richard Cochran
> <ric...@gm...> wrote:
> > On Fri, May 31, 2013 at 02:31:27PM +0200, Drasko DRASKOVIC wrote:
> >
> >> 1) What is does exactly  exectly asCapable flasg represent?
> >
> > This is explained in 802.1AS.
> 
> Yes, found it. Based on what I can read here, this log is a good sign.
> 
> >> 2) I can see that tx announce timeouts because of FD_MANNO_TIMER
> event
> >> in FSM. Any ideas why this is happening and where to look?
> >
> > This is the master's announce timer. It means that it is time to
> > transmit an announce message.
> 
> Great, then this is also a good sign. From what I can see in the code,
> port_tx_announce() is called.
> 
> >From log presented in previous mail I can now conclude that master
> keeps broadcasting "announce" and "sync" messages.
> 
> Can somebody please confirm that this is normal behavior, and that
> these log actually does not represent any error (abnormal state) on
> master side?
> 
> 
> On the slave side, I have an evident error :
> 
> root@slave:~/linuxptp# ./ptp4l -S -i wlan0 -m -l9 -s
> ptp4l[7264.414]: port 1: get_ts_info not supported
> ptp4l[7264.424]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[7264.425]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[7264.772]: port 1: setting asCapable
> ptp4l[7264.773]: port 1: new foreign master deadbe.fffe.ef0000-1
> ptp4l[7270.424]: port 1: announce timeout
> ptp4l[7270.711]: selected best master clock deadbe.fffe.ef0000
> ptp4l[7270.711]: foreign master not using PTP timescale
> ptp4l[7270.711]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[7271.892]: port 1: delay timeout
> ptp4l[7271.894]: poll tx timestamp failed: Success
> ptp4l[7271.894]: port 1: send delay request failed
> ptp4l[7271.894]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED
> (FT_UNSPECIFIED)
> ptp4l[7271.896]: waiting 2^{4} seconds to clear fault on port 0
> 
> Is there any hints how this delay failure should be examined ? Looking
> at this code in port_delay_request() :
> cnt = transport_send(p->trp, &p->fda, 1, msg, pdulen, &msg->hwts);
> 	if (cnt <= 0) {
> 		pr_err("port %hu: send delay request failed",
> portnum(p));
> 		goto out;
> 	}
> it does not give too much information why sending this message fails.
> 
> Secondly, I am seeing again "poll tx timestamp failed: Success",
> although I have added skb_tx_timestamp(skb); to the wireless driver.
> This seemd to work well on master side, so master stopped complain. I
> am not sure why on the slave side I am facing the same error, while
> using the same driver with tx_timestamp added.
> 
> Best regards,
> Drasko
> 

Are you certain that you are using the same driver? The error you are seeing here is due to poll timing out. The misleading error message has been fixed in the upstream git repository but I don't believe it has been released yet.

That means that the tx timestamp isn't being returned within the timelimit meaning your driver is not actually getting the timestamp result.

- Jake

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

[Drasko D. <dra...@gm...>]

Hi Richard,

On Thu, May 30, 2013 at 7:53 PM, Richard Cochran
<ric...@gm...> wrote:
> On Thu, May 30, 2013 at 07:34:45PM +0200, Drasko DRASKOVIC wrote:
>>
>> What is :
>> ptp4l[234.056]: poll tx timestamp failed: No such file or directory
>> ptp4l[234.056]: port 1: send delay request failed
>>
>>
>> and how is it different than :
>> ptp4l[106753.952]: poll tx timestamp failed: Success
>> ptp4l[106753.952]: port 1: send sync failed
>> ptp4l[106753.952]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
>>
>> that I was seeing on MASTER side before skb_tx_timestamp(skb) was
>> inserted in the driver ?
>
> I guess that the wireless stack returns ENOENT because it doesn't have
> an error queue for the time stamps, or something like that.

This can be a good hint, but I still did not found where I can check this.

I have traced timestamping in the kernel and function skb_tstamp_tx()
is called, and inside sock_queue_err_skb(sk, skb) as well. This gives
me good indication that skb has been enqueued well in
sk->sk_error_queue.

Where should I check for ENOENT value ?

BR,
Drasko

Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER questions

[Drasko D. <dra...@gm...>]

On Fri, May 31, 2013 at 4:09 PM, Richard Cochran
<ric...@gm...> wrote:
> On Fri, May 31, 2013 at 02:31:27PM +0200, Drasko DRASKOVIC wrote:
>
>> 1) What is does exactly  exectly asCapable flasg represent?
>
> This is explained in 802.1AS.

Yes, found it. Based on what I can read here, this log is a good sign.

>> 2) I can see that tx announce timeouts because of FD_MANNO_TIMER event
>> in FSM. Any ideas why this is happening and where to look?
>
> This is the master's announce timer. It means that it is time to
> transmit an announce message.

Great, then this is also a good sign. From what I can see in the code,
port_tx_announce() is called.

>From log presented in previous mail I can now conclude that master
keeps broadcasting "announce" and "sync" messages.

Can somebody please confirm that this is normal behavior, and that
these log actually does not represent any error (abnormal state) on
master side?


On the slave side, I have an evident error :

root@slave:~/linuxptp# ./ptp4l -S -i wlan0 -m -l9 -s
ptp4l[7264.414]: port 1: get_ts_info not supported
ptp4l[7264.424]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[7264.425]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[7264.772]: port 1: setting asCapable
ptp4l[7264.773]: port 1: new foreign master deadbe.fffe.ef0000-1
ptp4l[7270.424]: port 1: announce timeout
ptp4l[7270.711]: selected best master clock deadbe.fffe.ef0000
ptp4l[7270.711]: foreign master not using PTP timescale
ptp4l[7270.711]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[7271.892]: port 1: delay timeout
ptp4l[7271.894]: poll tx timestamp failed: Success
ptp4l[7271.894]: port 1: send delay request failed
ptp4l[7271.894]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[7271.896]: waiting 2^{4} seconds to clear fault on port 0

Is there any hints how this delay failure should be examined ? Looking
at this code in port_delay_request() :
cnt = transport_send(p->trp, &p->fda, 1, msg, pdulen, &msg->hwts);
	if (cnt <= 0) {
		pr_err("port %hu: send delay request failed", portnum(p));
		goto out;
	}
it does not give too much information why sending this message fails.

Secondly, I am seeing again "poll tx timestamp failed: Success",
although I have added skb_tx_timestamp(skb); to the wireless driver.
This seemd to work well on master side, so master stopped complain. I
am not sure why on the slave side I am facing the same error, while
using the same driver with tx_timestamp added.

Best regards,
Drasko

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

[Drasko D. <dra...@gm...>]

Hi Richard,

On Fri, May 31, 2013 at 4:05 PM, Richard Cochran
<ric...@gm...> wrote:
> On Fri, May 31, 2013 at 02:36:49PM +0200, Drasko DRASKOVIC wrote:
>>
>> I do not have IEEE 802.1AS-2011 at my disposal right now.
>
> FYI, it is a free download at:
>
>   http://standards.ieee.org/getieee802/download/802.1AS-2011.pdf

Thanks a lot for this link !

I did not know that this standard is freely downloadable. This will help a lot.

BR,
Drasko

Re: [Linuxptp-users] How to use DEBUG = -DDEBUG

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

On Fri, May 31, 2013 at 02:42:39PM +0200, Drasko DRASKOVIC wrote:
> Hi all,
> I know that -l9 command line switch gives a verbose output.
> 
> Still, I have been wondering what is DEBUG flag in Makefile used for
> and how to enable debugging messages?

The DEBUG makefile variable can be used for adding extra CFLAGS, like
'-g' for debug symbols.
 
> I tried with DEBUG = -DDEBUG, but I did not noticed change.

That is because there is no #ifdef DEBUG anywhere in the code.

And, seriously, you could find that out for yourself by looking.

Richard

Re: [Linuxptp-users] asCapable and FD_MANNO_TIMER questions

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

On Fri, May 31, 2013 at 02:31:27PM +0200, Drasko DRASKOVIC wrote:

> 1) What is does exactly  exectly asCapable flasg represent?

This is explained in 802.1AS.

> 2) I can see that tx announce timeouts because of FD_MANNO_TIMER event
> in FSM. Any ideas why this is happening and where to look?

This is the master's announce timer. It means that it is time to
transmit an announce message.

HTH,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

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

On Fri, May 31, 2013 at 02:36:49PM +0200, Drasko DRASKOVIC wrote:
> 
> I do not have IEEE 802.1AS-2011 at my disposal right now.

FYI, it is a free download at:

  http://standards.ieee.org/getieee802/download/802.1AS-2011.pdf

Thanks,
Richard

[Linuxptp-users] How to use DEBUG = -DDEBUG

[Drasko D. <dra...@gm...>]

Hi all,
I know that -l9 command line switch gives a verbose output.

Still, I have been wondering what is DEBUG flag in Makefile used for
and how to enable debugging messages?

I tried with DEBUG = -DDEBUG, but I did not noticed change.

Best regards,
Drasko

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

[Drasko D. <dra...@gm...>]

Hi Richard,

On Fri, May 31, 2013 at 12:42 PM, Richard Cochran
<ric...@gm...> wrote:
> On Fri, May 31, 2013 at 11:00:48AM +0200, Drasko DRASKOVIC wrote:
>>
>> However, I will have only WiFi connection in the future, so I am
>> trying to set-up similar thing (with performance penalty off course),
>> to see how far I can go with this method.
>
> As someone mentioned in another email, you should definitely take a
> look at IEEE 802.1AS-2011, chapter 12, which specifies a way to run
> gPTP over 802.11.

I do not have IEEE 802.1AS-2011 at my disposal right now. However, I
am still far away from dealing with PTP algorithms, as I can not have
a basic communication and message exchange.

There seems to be no timestamping support for wireless devices in
Linux, and without it I can not progress in playing with standard, as
I have first to make ptp4l work (exchange messages). So far it just
timeouts on TX (as I described on previous e-mail).

Once I have basic communication and some kind of synchronization (no
matter how imprecise it will be), I will start to improve results. So
far I am still having problems with basic set-up.

Best regards,
Drasko

[Linuxptp-users] asCapable and FD_MANNO_TIMER questions

[Drasko D. <dra...@gm...>]

Hi all,
I tried to add some logs for debugging. on master side I have following :

root@master:/linux-ptp# ./ptp4l -S -i wlan0 -m -l9
ptp4l[62586.626]: port 1: get_ts_info not supported
ptp4l[62586.630]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[62586.630]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[62592.630]: port 1: announce timeout
ptp4l[62592.630]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[62593.630]: port 1: master sync timeout
ptp4l[62593.630]: port 1: setting asCapable
ptp4l[62594.630]: port 1: master tx announce timeout
ptp4l[62594.631]: port 1: master sync timeout
ptp4l[62595.631]: port 1: master sync timeout
ptp4l[62596.631]: port 1: master tx announce timeout
ptp4l[62596.631]: port 1: master sync timeout
ptp4l[62597.631]: port 1: master sync timeout


At this point I am wondering :
1) What is does exactly  exectly asCapable flasg represent?
2) I can see that tx announce timeouts because of FD_MANNO_TIMER event
in FSM. Any ideas why this is happening and where to look?


Best regards,
Drasko

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

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

On Fri, May 31, 2013 at 11:00:48AM +0200, Drasko DRASKOVIC wrote:
> 
> However, I will have only WiFi connection in the future, so I am
> trying to set-up similar thing (with performance penalty off course),
> to see how far I can go with this method.

As someone mentioned in another email, you should definitely take a
look at IEEE 802.1AS-2011, chapter 12, which specifies a way to run
gPTP over 802.11.

And if you make any progress on this, please do tell us about it.

Thanks,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

[Drasko D. <dra...@gm...>]

On Thu, May 30, 2013 at 10:10 PM, Keller, Jacob E
<jac...@in...> wrote:
>> -----Original Message-----
>> From: Richard Cochran [mailto:ric...@gm...]
>> Sent: Thursday, May 30, 2013 10:54 AM
>> To: Drasko DRASKOVIC
>> Cc: lin...@li...
>> Subject: Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l
>>
>> On Thu, May 30, 2013 at 07:34:45PM +0200, Drasko DRASKOVIC wrote:
>> >
>> > What is :
>> > ptp4l[234.056]: poll tx timestamp failed: No such file or directory
>> > ptp4l[234.056]: port 1: send delay request failed
>> >
>> >
>> > and how is it different than :
>> > ptp4l[106753.952]: poll tx timestamp failed: Success
>> > ptp4l[106753.952]: port 1: send sync failed
>> > ptp4l[106753.952]: port 1: MASTER to FAULTY on FAULT_DETECTED
>> (FT_UNSPECIFIED)
>> >
>> > that I was seeing on MASTER side before skb_tx_timestamp(skb) was
>> > inserted in the driver ?
>>
>> I guess that the wireless stack returns ENOENT because it doesn't have
>> an error queue for the time stamps, or something like that.
>>
>> HTH,
>> Richard
>>
>
> Yes, this is most likely the reason, but I also don't know for sure..
>
> Drasko,
>
> There are a lot of issues with enabling timestamping in the wireless devices. The framework which exists for Ethernet does not necessarily translate to wireless, and it would require a lot more work to enable it. Neither myself or Richard currently has the time, hardware, or experience to really debug this. This is really beyond the scope of the linuxptp mailing lists, as ptp4l is primarily designed with Ethernet in mind.
>
> I am not sure where best to make a thread where you could get the help you need....
>
> - Jake

Hello Richard, Jake,
I understand that these questions are beyond the scope of this dev
list and I will switch to users list instead (did not saw it before).

I tried first using linux-ptp with ethernet, just to check out how it
works and understand how to set-up environment. Pandaboard uses
smsc95xx ETH driver
(http://lxr.free-electrons.com/source/drivers/net/usb/smsc95xx.c),
which seems to have implemented SW timestamping and ptp4l gives quite
good performance (20 - 40 uS clock offsets measured with scope).

However, I will have only WiFi connection in the future, so I am
trying to set-up similar thing (with performance penalty off course),
to see how far I can go with this method.

As I mentioned before, Pandaboard uses this WiFi driver :
https://github.com/garwedgess/ti-wlan/tree/master/compat-wireless-wl12xx/drivers/net/wireless/wl12xx,
and I just inserted  skb_tx_timestamp(skb); inside of
wl1271_prepare_tx_frame() here
https://github.com/garwedgess/ti-wlan/blob/master/compat-wireless-wl12xx/drivers/net/wireless/wl12xx/tx.c#L443.
This does not seem to work quite well, so I will proceed with my
debugging and will keep you informed on users list.

Thank you again for your help.

Best regards,
Drasko

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Thursday, May 30, 2013 10:54 AM
> To: Drasko DRASKOVIC
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l
> 
> On Thu, May 30, 2013 at 07:34:45PM +0200, Drasko DRASKOVIC wrote:
> >
> > What is :
> > ptp4l[234.056]: poll tx timestamp failed: No such file or directory
> > ptp4l[234.056]: port 1: send delay request failed
> >
> >
> > and how is it different than :
> > ptp4l[106753.952]: poll tx timestamp failed: Success
> > ptp4l[106753.952]: port 1: send sync failed
> > ptp4l[106753.952]: port 1: MASTER to FAULTY on FAULT_DETECTED
> (FT_UNSPECIFIED)
> >
> > that I was seeing on MASTER side before skb_tx_timestamp(skb) was
> > inserted in the driver ?
> 
> I guess that the wireless stack returns ENOENT because it doesn't have
> an error queue for the time stamps, or something like that.
> 
> HTH,
> Richard
> 

Yes, this is most likely the reason, but I also don't know for sure..

Drasko,

There are a lot of issues with enabling timestamping in the wireless devices. The framework which exists for Ethernet does not necessarily translate to wireless, and it would require a lot more work to enable it. Neither myself or Richard currently has the time, hardware, or experience to really debug this. This is really beyond the scope of the linuxptp mailing lists, as ptp4l is primarily designed with Ethernet in mind.

I am not sure where best to make a thread where you could get the help you need....

- Jake

Re: [Linuxptp-users] ptp4l use case

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

On Thu, May 30, 2013 at 06:25:18PM +0200, Drasko DRASKOVIC wrote:
> Hi all,
> cam somebody please clarify me some ptp4l usage.
> 
> I am using two pandaboards, one should be clock master to the other
> and my need is to have a minimal clock offset between them.
> 
> I am starting on master (server) side :
> root@panda_master:/linux-ptp# ./ptp4l -S -i eth0 -m -l5
> ptp4l[109238.352]: port 1: get_ts_info not supported
> ptp4l[109238.355]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[109238.356]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[109244.355]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> 
> and on slave (client) side :
> 
> root@speaker:/linux-ptp# ./ptp4l -S -i eth0 -s -m -l5
> ptp4l[109513.813]: port 1: get_ts_info not supported
> ptp4l[109513.817]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[109513.817]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[109514.583]: port 1: new foreign master 0e1851.fffe.028b34-1
> ptp4l[109518.583]: selected best master clock 0e1851.fffe.028b34
> ptp4l[109518.583]: foreign master not using PTP timescale
> ptp4l[109518.583]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[109521.607]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED

After this, you should see a one line synchronization report every
second, but only at log level 6 (LOG_INFO). You said, '-l5'.

> Can somebody please give me information what does "UNCALIBRATED" and
> "RS_SLAVE" means. Can you please clarify this line :
> ptp4l[109521.607]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED

These refer to the state machine from the IEEE 1588 standard. The
message shows state transitions and the event that triggered them. In
this case, "RS_SLAVE" means that the result of the Best Master Clock
algorithm was "recommended state slave".
 
> Is there a way to get some more log messages, and to see timestamps
> sent/received for further debugging and examination ?

To see all of the available messages, use:  ptpt4l -l9

HTH,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] Debugging ptp4l

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

On Thu, May 30, 2013 at 07:34:45PM +0200, Drasko DRASKOVIC wrote:
> 
> What is :
> ptp4l[234.056]: poll tx timestamp failed: No such file or directory
> ptp4l[234.056]: port 1: send delay request failed
> 
> 
> and how is it different than :
> ptp4l[106753.952]: poll tx timestamp failed: Success
> ptp4l[106753.952]: port 1: send sync failed
> ptp4l[106753.952]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
> 
> that I was seeing on MASTER side before skb_tx_timestamp(skb) was
> inserted in the driver ?

I guess that the wireless stack returns ENOENT because it doesn't have
an error queue for the time stamps, or something like that.

HTH,
Richard

[Linuxptp-users] ptp4l use case

[Drasko D. <dra...@gm...>]

Hi all,
cam somebody please clarify me some ptp4l usage.

I am using two pandaboards, one should be clock master to the other
and my need is to have a minimal clock offset between them.

I am starting on master (server) side :
root@panda_master:/linux-ptp# ./ptp4l -S -i eth0 -m -l5
ptp4l[109238.352]: port 1: get_ts_info not supported
ptp4l[109238.355]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[109238.356]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[109244.355]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

and on slave (client) side :

root@speaker:/linux-ptp# ./ptp4l -S -i eth0 -s -m -l5
ptp4l[109513.813]: port 1: get_ts_info not supported
ptp4l[109513.817]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[109513.817]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[109514.583]: port 1: new foreign master 0e1851.fffe.028b34-1
ptp4l[109518.583]: selected best master clock 0e1851.fffe.028b34
ptp4l[109518.583]: foreign master not using PTP timescale
ptp4l[109518.583]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[109521.607]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED


Can somebody please give me information what does "UNCALIBRATED" and
"RS_SLAVE" means. Can you please clarify this line :
ptp4l[109521.607]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED

Is there a way to get some more log messages, and to see timestamps
sent/received for further debugging and examination ?

Kind regards,
Drasko

Re: [Linuxptp-users] Synchronization problem

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

Thank you for your answers!

Regards

William


-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: 29 May 2013 19:34
To: Ledda William EXT
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Synchronization problem

William,

You can configure the clock reset behavior using the 'pi_offset_const'
option in the config file. The default of zero means never reset, but you can set it to 1.0 second, for example, in order to let the servo jump the clock to the new offset.

HTH,
Richard

Re: [Linuxptp-users] Synchronization problem

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

> -----Original Message-----
> From: Ledda William EXT [mailto:Wil...@it...]
> Sent: Wednesday, May 29, 2013 8:32 AM
> To: lin...@li...
> Subject: [Linuxptp-users] Synchronization problem
> 
> Hi all,
> I have encountered a strange behaviour using ptp4l. I have a system
> with Linux RH 6.4 and I'm using the package included in the Red Hat 6.4
> distribution (linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64). To synch
> the system time I use a motherboard with a Broadcom chipset that
> support only SW timestamp. It's ok, and I'm able to synch the system
> clock with our GMC with ptp4l.
> 
> Today I was trying to make a trivial but very important test for our
> purposes: with the system clock already synch with the GMC I have tried
> to change the date of the system to discover how much time ptp4l takes
> to reset the system clock to the right time. The result is not good, since
> the time is never re-synchronized. If I stop the ptp4l and I restart it the
> system is synchronized again.
> 
> I attach two files:
> 
> - Ptp4l-sync: system time bad -> system time synchronize
> - Ptp4l-not-synch: system synch -> system time force to be bad. After
> about five minutes the system is not syched.
> 
> Regards
> 
> William
> 

In case Richard's explanation doesn't have enough detail, I can explain what is going on. PTP4l's default setting for the servo means it will never use clock jumping no matter how large the offset is. This occurs because you actually normally do not ever want large clock jumps and really only want to use small corrections of clock speed to synch. But that takes a very long time if you do something like move the date, since at most you can correct about half a second per every second you run.

If you modify the config parameter like Richard suggested, then you can configure the servo to reset once there is an offset larger than that value in seconds. This should solve the issue for you, as it enables the servo to perform a jump again if the clock is ever off by that large of an offset.

- Jake

Re: [Linuxptp-users] Synchronization problem

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

William,

You can configure the clock reset behavior using the 'pi_offset_const'
option in the config file. The default of zero means never reset, but
you can set it to 1.0 second, for example, in order to let the servo
jump the clock to the new offset.

HTH,
Richard

[Linuxptp-users] Synchronization problem

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

Hi all, 
I have encountered a strange behaviour using ptp4l. I have a system with Linux RH 6.4 and I'm using the package included in the Red Hat 6.4 distribution (linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64). To synch the system time I use a motherboard with a Broadcom chipset that support only SW timestamp. It's ok, and I'm able to synch the system clock with our GMC with ptp4l. 

Today I was trying to make a trivial but very important test for our purposes: with the system clock already synch with the GMC I have tried to change the date of the system to discover how much time ptp4l takes to reset the system clock to the right time. The result is not good, since the time is never re-synchronized. If I stop the ptp4l and I restart it the system is synchronized again.

I attach two files:

- Ptp4l-sync: system time bad -> system time synchronize
- Ptp4l-not-synch: system synch -> system time force to be bad. After about five minutes the system is not syched.

Regards

William

Re: [Linuxptp-users] Output of ptp4l

[Adrian K. <ad...@dr...>]

On Thu, May 16, 2013 at 02:20:28PM +0200, Richard Cochran wrote:

> > How about copy&pasting this to README.org?
> 
> I think it is about time to start a Users Manual, with tutorials of the
> most common use cases.
> 
> Also, should I activate the SF wiki?

Make this a file inside the git repo. This way, you can leverage the
community to contribute improvements and later share parts of said
manual with related projects like gptp (where applicable).




Cheers

-- 
mail: ad...@th...  	http://adi.thur.de	PGP/GPG: key via keyserver

Re: [Linuxptp-users] Output of ptp4l

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

On Thu, May 16, 2013 at 12:45:25PM +0200, Adrian Knoth wrote:
> How about copy&pasting this to README.org?

I think it is about time to start a Users Manual, with tutorials of the
most common use cases.

Also, should I activate the SF wiki?

Thanks,
Richard