Re: [Linuxptp-users] Bad message error

[Richard Cochran]

On Tue, Feb 06, 2018 at 06:20:59PM +0200, Yan Yankovskyi via Linuxptp-users 
wrote:
> I have a configuration with a PC running Ubuntu and a board running Linux.

By "board running Linux" you mean a custom embedded design, don't you?
Or what do you mean?

> ethtool reports that the board doesn't support SOF_TIMESTAMPING_TX_SOFTWARE,

Then you are out of luck.

> and I disabled ethtool check as mentioned in this post
> http://linuxptp-users.narkive.com/Q6DUVkta/using-ptp4l-on-vlan-interfaces#post7

That thread is out of date.  The topic was running PTP over a VLAN
interface.  This is now fully supported by the Linux kernel.

> . Now if the board behaves as a master, I see correct log on the PC. But
> when I try use slave-only mode on the board, it says "port 1: bad message"
> all the time. I found out that error detects in the "suffix_post_recv"
> function ("msg.c" file). len variable is always equal to 6, but tlv->length
> variable is taking for example the following values: 210, 20250, 50666,
> 18066, and so on. Such values lead to failing either on (tlv->length % 2)
> or on (tlv->length > len) check, and I'm gerring -EBADMSG error. I would be
> thankful if anyone could explain what do such values mean and what can be
> the cause.

Looks like the endianness of the value is wrong.

HTH,
Richard




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

[Linuxptp-users] Bad message error

[Yan Yankovskyi via Linuxptp-users]

Hello,

I have a configuration with a PC running Ubuntu and a board running Linux.
ethtool reports that the board doesn't support SOF_TIMESTAMPING_TX_SOFTWARE,
and I disabled ethtool check as mentioned in this post
http://linuxptp-users.narkive.com/Q6DUVkta/using-ptp4l-on-vlan-interfaces#post7
. Now if the board behaves as a master, I see correct log on the PC. But
when I try use slave-only mode on the board, it says "port 1: bad message"
all the time. I found out that error detects in the "suffix_post_recv"
function ("msg.c" file). len variable is always equal to 6, but tlv->length
variable is taking for example the following values: 210, 20250, 50666,
18066, and so on. Such values lead to failing either on (tlv->length % 2)
or on (tlv->length > len) check, and I'm gerring -EBADMSG error. I would be
thankful if anyone could explain what do such values mean and what can be
the cause. Please correct if I'm using wrong mailing list.


-- 
Best regards,

Yan Yankovskyi | Junior Software Engineer, Ukraine
GlobalLogic
M  +380.95.049.64.73 <+380950496473>   Skype huandesale

www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Reordering of follow up and the next sync message

[Mikael Arvids]

Hi Richard,

Thank you for your quick response! Yes, I will investigate the delayed follow 
up packet.

>From the pcap files recorded with tcpdump I can see that the delta time 
>between the sync and fup is ~50us on the master and ~120ms on the slave. The 
>master and slave are connected directly (phy-to-phy) so there is no bridge in 
>between and there is no other traffic on that link.

Thanks again,
Mikael

-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com] 
Sent: den 6 februari 2018 12:36
To: Mikael Arvids 
Cc: linuxptp-users@lists.sourceforge.net
Subject: Re: [Linuxptp-users] Reordering of follow up and the next sync message

On Tue, Feb 06, 2018 at 10:26:34AM +, Mikael Arvids wrote:
> Looking at the code (process_sync, process_follow_up and port_syfusfm) it 
> seems that the intention is to handle the case when a follow up is processed 
> before the corresponding sync, not when the next sync is received before the 
> follow up. Is this a known issue and has anyone made any fix for this?

It is not an issue, known or unknown.  This is the design of the protocol.  
Once a new Sync message has been received, the servo's deadline has been 
missed, and it is too late to do anything with the previous Sync message.

You should find out why your Follow-Up messages are being delayed for so long.  
In the example you gave, the Fup comes one whole period (125
ms) later than expected.

Thanks,
Richard



***
Consider the environment before printing this message.

To read the Companies' Information and Confidentiality Notice, follow this link:
https://www.autoliv.com/Pages/disclaimer.aspx
***


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Reordering of follow up and the next sync message

[Richard Cochran]

On Tue, Feb 06, 2018 at 10:26:34AM +, Mikael Arvids wrote:
> Looking at the code (process_sync, process_follow_up and port_syfusfm) it 
> seems that the intention is to handle the case when a follow up is processed 
> before the corresponding sync, not when the next sync is received before the 
> follow up. Is this a known issue and has anyone made any fix for this?

It is not an issue, known or unknown.  This is the design of the
protocol.  Once a new Sync message has been received, the servo's
deadline has been missed, and it is too late to do anything with the
previous Sync message.

You should find out why your Follow-Up messages are being delayed for
so long.  In the example you gave, the Fup comes one whole period (125
ms) later than expected.

Thanks,
Richard




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

[Linuxptp-users] Reordering of follow up and the next sync message

[Mikael Arvids]

Hi,

We are currently using LinuxPTP on an embedded linux platform (ARMv8) and are 
experiencing some problems with dropped sync seemingly due to packet reordering.

I have traced the sync and follow up messages and I see that sometimes a follow 
up message and the next sync message are reordered, resulting in the processing 
of two sync messages before the follow up is processed. When this occurs the 
sync timer expires sometimes (not always), as seen in the below trace.

ptp4l[66088.453]: delay   filtered859   raw868
ptp4l[66088.563]: process_sync: seqnum=63375 ts=332240.686307221
ptp4l[66088.563]: process_follow_up: seqnum=63375 ts=332240.686306278
ptp4l[66088.688]: process_sync: seqnum=63376 ts=332240.811907459
ptp4l[66088.688]: process_follow_up: seqnum=63376 ts=332240.811906550
ptp4l[66088.813]: process_sync: seqnum=63377 ts=332240.936953726
ptp4l[66088.814]: process_follow_up: seqnum=63377 ts=332240.936952818
ptp4l[66088.938]: process_sync: seqnum=63378 ts=332241.061994001
ptp4l[66088.939]: process_follow_up: seqnum=63378 ts=332241.061993078
ptp4l[66088.939]: rms   59 max   84 freq   +565 +/-  42 delay   859 +/-   0
ptp4l[66089.063]: process_sync: seqnum=63379 ts=332241.187008817
ptp4l[66089.189]: process_sync: seqnum=63380 ts=332241.312630776
ptp4l[66089.189]: process_follow_up: seqnum=63379 ts=332241.187007894
ptp4l[66089.189]: process_follow_up: seqnum=63380 ts=332241.312629830
ptp4l[66089.314]: process_sync: seqnum=63381 ts=332241.437660268
ptp4l[66089.439]: port 1: rx sync timeout

Looking at the code (process_sync, process_follow_up and port_syfusfm) it seems 
that the intention is to handle the case when a follow up is processed before 
the corresponding sync, not when the next sync is received before the follow 
up. Is this a known issue and has anyone made any fix for this?

Best regards,
Mikael Arvids

***
Consider the environment before printing this message.

To read the Companies' Information and Confidentiality Notice, follow this link:
https://www.autoliv.com/Pages/disclaimer.aspx
***
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users