Re: [Linuxptp-devel] [PATCH v4 06/11] Prepare clock based storage of up to four time zones.

[Geva, Erez]

On Sat, 2023-01-28 at 14:43 -0800, Richard Cochran wrote:
> Signed-off-by: Richard Cochran 
> ---
>  clock.c | 19 ---
>  tz.h    | 26 ++
>  2 files changed, 42 insertions(+), 3 deletions(-)
>  create mode 100644 tz.h
> 
> diff --git a/clock.c b/clock.c
> index 134c7c3..767599b 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -42,6 +42,7 @@
>  #include "rtnl.h"
>  #include "tlv.h"
>  #include "tsproc.h"
> +#include "tz.h"
>  #include "uds.h"
>  #include "util.h"
>  
> @@ -79,6 +80,15 @@ struct clock_subscriber {
> time_t expiration;
>  };
>  
> +struct time_zone {
> +   bool enabled;
> +   int32_t current_offset;
> +   int32_t jump_seconds;
> +   uint16_t next_jump_msb;
> +   uint32_t next_jump_lsb;
> +   struct static_ptp_text display_name;
> +};
> +
>  struct clock {
> enum clock_type type;
> struct config *config;
> @@ -137,6 +147,7 @@ struct clock {
> struct monitor *slave_event_monitor;
> int step_window_counter;
> int step_window;
> +   struct time_zone tz[MAX_TIME_ZONES];
>  };
>  
>  struct clock the_clock;
> @@ -894,19 +905,17 @@ int clock_required_modes(struct clock *c)
>  struct clock *clock_create(enum clock_type type, struct config
> *config,
>    const char *phc_device)
>  {
> +   int conf_phc_index, i, max_adj = 0, phc_index, required_modes
> = 0, sfl, sw_ts;
> enum servo_type servo = config_get_int(config, NULL,
> "clock_servo");
> char ts_label[IF_NAMESIZE], phc[32], *tmp;
> enum timestamp_type timestamping;
> -   int phc_index, conf_phc_index, required_modes = 0;
> struct clock *c = _clock;
> -   int max_adj = 0, sw_ts;
> const char *uds_ifname;
> double fadj = 0.0;
> struct port *p;
> unsigned char oui[OUI_LEN];
> struct interface *iface;
> struct timespec ts;
> -   int sfl;
>  
> clock_gettime(CLOCK_REALTIME, );
> srandom(ts.tv_sec ^ ts.tv_nsec);
> @@ -1201,6 +1210,10 @@ struct clock *clock_create(enum clock_type
> type, struct config *config,
> c->dad.pds.observedParentClockPhaseChangeRate    =
> 0x7fff;
> c->dad.ptl = c->ptl;
>  
> +   for (i = 0; i < MAX_TIME_ZONES; i++) {
> +   c->tz[i].display_name.max_symbols =
> MAX_TZ_DISPLAY_NAME;
> +   }
> +
> clock_sync_interval(c, 0);
>  
> LIST_INIT(>subscribers);
> diff --git a/tz.h b/tz.h
> new file mode 100644
> index 000..986f976
> --- /dev/null
> +++ b/tz.h
> @@ -0,0 +1,26 @@
> +/**
> + * @file tz.h
> + * @brief Implements time zone constants.
> + * @note Copyright (C) 2021 Richard Cochran <
> richardcoch...@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as published
> by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along
> + * with this program; if not, write to the Free Software Foundation,
> Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */

Perhaps we can use SPDX, like the Linux kernel do?
https://www.kernel.org/doc/html/latest/process/license-rules.html
https://spdx.dev/


> +#ifndef HAVE_TZ_H
> +#define HAVE_TZ_H
> +
> +#define MAX_TZ_DISPLAY_NAME10
> +#define MAX_TIME_ZONES 4
> +
> +#endif

Erez


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v4 05/11] tlv: Encode and decode alternate time offset indicator TLVs.

[Geva, Erez]

On Sat, 2023-01-28 at 14:43 -0800, Richard Cochran wrote:
> Signed-off-by: Richard Cochran 
> ---
>  tlv.c | 58
> ++
>  tlv.h | 26 ++
>  2 files changed, 84 insertions(+)
> 
> diff --git a/tlv.c b/tlv.c
> index 2e421ed..212414f 100644
> --- a/tlv.c
> +++ b/tlv.c
> @@ -77,6 +77,22 @@ static uint16_t flip16(void *p)
> return v;
>  }
>  
> +static void host2net32_unaligned(void *p)
> +{
> +   int32_t v;
> +   memcpy(, p, sizeof(v));
> +   v = htonl(v);
> +   memcpy(p, , sizeof(v));
> +}
> +
> +static void net2host32_unaligned(void *p)
> +{
> +   int32_t v;
> +   memcpy(, p, sizeof(v));
> +   v = ntohl(v);
> +   memcpy(p, , sizeof(v));
> +}
> +
>  static int64_t host2net64_unaligned(void *p)
>  {
> int64_t v;
> @@ -111,6 +127,43 @@ static bool tlv_array_invalid(struct TLV *tlv,
> size_t base_size, size_t item_siz
> return (tlv->length == expected_length) ? false : true;
>  }
>  
> +static int alttime_offset_post_recv(struct tlv_extra *extra)
> +{
> +   struct TLV *tlv = extra->tlv;
> +   struct alternate_time_offset_indicator_tlv *atoi =
> +   (struct alternate_time_offset_indicator_tlv *) tlv;
> +
> +   if (tlv->length < sizeof(struct
> alternate_time_offset_indicator_tlv) +
> +   atoi->displayName.length - sizeof(struct TLV)) {
> +   return -EBADMSG;
> +   }
> +
> +   NTOHS(atoi->type);
> +   NTOHS(atoi->length);
> +   /* Message alignment broken by design. */
> +   net2host32_unaligned(>currentOffset);
> +   net2host32_unaligned(>jumpSeconds);
> +   flip16(>timeOfNextJump.seconds_msb);
> +   net2host32_unaligned(>timeOfNextJump.seconds_lsb);
> +
> +   return 0;
> +}
> +
> +static void alttime_offset_pre_send(struct tlv_extra *extra)
> +{
> +   struct alternate_time_offset_indicator_tlv *atoi;
> +
> +   atoi = (struct alternate_time_offset_indicator_tlv *) extra-
> >tlv;
> +
> +   HTONS(atoi->type);
> +   HTONS(atoi->length);
> +   /* Message alignment broken by design. */
> +   host2net32_unaligned(>currentOffset);
> +   host2net32_unaligned(>jumpSeconds);
> +   flip16(>timeOfNextJump.seconds_msb);
> +   host2net32_unaligned(>timeOfNextJump.seconds_lsb);
> +}
> +
>  static int mgt_post_recv(struct management_tlv *m, uint16_t
> data_len,
>  struct tlv_extra *extra)
>  {
> @@ -1035,6 +1088,8 @@ int tlv_post_recv(struct tlv_extra *extra)
> }
> break;
> case TLV_ALTERNATE_TIME_OFFSET_INDICATOR:
> +   result = alttime_offset_post_recv(extra);
> +   break;
> case TLV_AUTHENTICATION_2008:
> case TLV_AUTHENTICATION_CHALLENGE:
> case TLV_SECURITY_ASSOCIATION_UPDATE:
> @@ -1098,7 +1153,10 @@ void tlv_pre_send(struct TLV *tlv, struct
> tlv_extra *extra)
> unicast_negotiation_pre_send(tlv);
> break;
> case TLV_PATH_TRACE:
> +   break;
> case TLV_ALTERNATE_TIME_OFFSET_INDICATOR:
> +   alttime_offset_pre_send(extra);
> +   break;
> case TLV_AUTHENTICATION_2008:
> case TLV_AUTHENTICATION_CHALLENGE:
> case TLV_SECURITY_ASSOCIATION_UPDATE:
> diff --git a/tlv.h b/tlv.h
> index 3dbce4f..a1a7dbc 100644
> --- a/tlv.h
> +++ b/tlv.h
> @@ -175,6 +175,32 @@ struct grant_unicast_xmit_tlv {
> uint8_t flags;
>  } PACKED;
>  
> +struct alternate_time_offset_indicator_tlv {
> +   Enumeration16   type;
> +   UInteger16  length;
> +   UInteger8   keyField;
> +   /* Message alignment broken by design. */
> +   Integer32   currentOffset;
> +   Integer32   jumpSeconds;
> +   struct {
> +   uint16_t   seconds_msb; /* 16 bits + */
> +   uint32_t   seconds_lsb; /* 32 bits = 48 bits*/
> +   } PACKED timeOfNextJump;
> +   struct PTPText  displayName;
> +} PACKED;
> +
> +struct alternate_time_offset_properties {
> +   UInteger8   keyField;
> +   /* Message alignment broken by design. */
> +   Integer32   currentOffset;
> +   Integer32   jumpSeconds;
> +   struct {
> +   uint16_t   seconds_msb; /* 16 bits + */
> +   uint32_t   seconds_lsb; /* 32 bits = 48 bits*/
> +   } PACKED timeOfNextJump;
> +   uint8_t pad;
> +} PACKED;
> +
>  struct management_tlv {
> Enumeration16 type;
> UInteger16    length;

I understand the idea in general.
And I understand the files in the TLVs are unaligned.
But Does htonl() and ntohl() have problem with alignment?
Or the point was using pointers?

Please add a short explanation for the solution.
The explanation on "alignment break by design" is very clear :-)

Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net

Re: [Linuxptp-devel] [PATCH v3 4/4] [Interface Rate TLV] adding delay asymmetry calculation

[Geva, Erez]

On Tue, 2022-12-13 at 10:56 +0530, Devasish Dey wrote:
> +   /* Megabits per secon converted to attoseconds per bit. */
> +   return 1ULL/ iface->if_info.speed;
Performing division in running is not a very good idea.
It is better to perform the division when updating the speed and store
it in if_info.

I agree with Miroslav, calculation is better, I did not suggest using hard 
coded values, so not need to defend.
I simply suggest to move the calculation to where you set "if_info.speed".
So instead of calculate it every cycle, we only calculate when speed is changed.
Division is expensive (unless it is a left shift).
I usually compare new speed with old speed before calculate, if the speed is 
the same, so is the bit time :-)


Are you sure we need attoseconds (10^-18), we usually uses nanoseconds
(10^-9). I would except a better resolution, but that much?
Please explain your choosing.

> +}

[Devasish]:  The initial changes were with hardcoded values for the speed to 
avoid the calculation.
Miroslav suggested this way to have clean code.



Yes the calculation is based on attoseconds and not nanoseconds This is as per 
standard G.8275.2
From G.8275.2 (06/2021)


The linuxptp is mainly implement IEEE.
That does not means we can not support or use ITU standards,
but if you do, please add a comment with reference.
This applies as well as to choosing attoseconds.


"
interfaceBitPeriod (Uinteger64)
The period of 1-bit of the transmitting PTP timestamp interface, excluding line 
encoding.
The value is encoded as an unsigned integer in units of attoseconds (10–18 s) 
to accommodate interface bit periods less than 1 ns."

Thanks,
Devasish.

On Fri, 9 Dec 2022 at 18:08, Geva, Erez 
mailto:erez.geva@siemens.com>> wrote:
On Wed, 2022-12-07 at 17:34 +0530, SyncMonk Technologies wrote:
> Delay asymmetry calculation based on the PTP port interface speed of
> master obtained from TLV and the slave interface rate obtained by
> ethtool.
>
> v3: updating network/host byte order handling.
> v1: initial commit
>
> Signed-off-by: Greg Armstrong 
> mailto:greg.armstrong...@renesas.com>>
> Signed-off-by: Leon Goldin 
> mailto:leon.goldin...@renesas.com>>
> Signed-off-by: Devasish Dey 
> mailto:devasish@syncmonk.net>>
> Signed-off-by: Vipin Sharma 
> mailto:vipin.sha...@syncmonk.net>>
> ---
>  interface.c   | 10 ++
>  interface.h   |  7 +++
>  port_private.h|  1 +
>  port_signaling.c  | 39 ---
>  ptp4l.8   |  7 +++
>  tlv.c | 29 +
>  unicast_service.c | 32 
>  7 files changed, 122 insertions(+), 3 deletions(-)
>
> diff --git a/interface.c b/interface.c
> index 3157e8c..02d530e 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -94,3 +94,13 @@ int interface_get_vclock(struct interface *iface)
>  {
> return iface->vclock;
>  }
> +
> +uint64_t interface_bitperiod(struct interface *iface)
> +{
> +   if (!iface->if_info.valid)
> +   return 0;
> +
> +   /* Megabits per secon converted to attoseconds per bit. */
> +   return 1ULL/ iface->if_info.speed;
Performing division in running is not a very good idea.
It is better to perform the division when updating the speed and store
it in if_info.

Are you sure we need attoseconds (10^-18), we usually uses nanoseconds
(10^-9). I would except a better resolution, but that much?
Please explain your choosing.

> +}
> +
> diff --git a/interface.h b/interface.h
> index f4b9545..7c9a6bd 100644
> --- a/interface.h
> +++ b/interface.h
> @@ -113,4 +113,11 @@ void interface_set_vclock(struct interface
> *iface, int vclock);
>   */
>  int interface_get_vclock(struct interface *iface);
>
> +/**
> + * Obtains the interface bit period based on the speed.
Perhaps: "Obtains bit period based on interface speed."

> + * @param iface  The interface of interest.
We must be interesting "Pointer to the interface" can be suffiecnt :-)

> + * @return   if valid speed return interface bitperiod in atto
> seconds.
No need to make the return complicated, make it simple
 "return interface bit period in attoseconds".
We know functions handle errors.

> + */
> +uint64_t interface_bitperiod(struct interface *iface);
> +
>  #endif
> diff --git a/port_private.h b/port_private.h
> index d6487eb..6ad4af8 100644
> --- a/port_private.h
> +++ b/port_private.h
> @@ -146,6 +146,7 @@ struct port {
> UInteger8   delay_response_counter;
> UInteger8   delay_response_timeout;
> booliface_rate_tlv;
> +   Integer64   portAsymmetry;
> s

Re: [Linuxptp-devel] [PATCH v3 1/4] [Interface Rate TLV] function to support get interface speed via ethtool

[Geva, Erez]

On Tue, 2022-12-13 at 10:39 +0530, Devasish Dey wrote:
> +   goto failed;
> +   }

I think it is better to merge this ioctl and the socket creation with
sk_get_ts_info().
No reason for duplication.
You can use a static function or inline one.

> +
> +   if (ecmd.req.link_mode_masks_nwords >= 0 ||
> +   ecmd.req.cmd != ETHTOOL_GLINKSETTINGS) {
> +   return 1;
> +   }

[Devasish]: This can be done.

> +   /* clear data and ensure it is not marked valid */
> +   memset(if_info, 0, sizeof(struct sk_if_info));
> +   return -1;

You need to close the socket!
[Devasish]: Noted. Will be updated in the next patch.

> +struct sk_if_info {
> +   bool valid;
It is better not to use bool in a structure, as the size is usually
int, i.e. 64 bits to hold 1 bit.

[Devasish]: Earlier we had it as an integer. We can update it to uint8_t as 
well. But Richard suggested updating it to Boolean.
So, leaving this to Richard.

Good point, we can define a Boolean type using uint8_t for structures use.
But we can leave this decision to Richard.


> +   int speed;
What are the units here?
Old systems use 32 bits, if you measure in bits per second, the maximum
is 4 GB.
It is better to use uint64_t and use 1 mbps as units.
[Devasish]: It is the same as the speed in ethtool_link_settings which is a 
uint32_t variable and it is in Mbps.
Will change it to uint32_t and update the comments.

We do not have to follow the kernel ioctl type for speed, they tend to change 
them from time to time.
Probably, someone in the past choose 'int' as he did not predict future speed 
will pass 31 bits (int is signed).
And also the use of uintNN_t was not so common than.
But as sk.c is our internal layer, it can translate from kernel units and types 
to our application units and types.
You do provide internal structure and do not use the kernel one :-)
So if in the future the kernel will use a new ioctl  for speed as int will be 
too small, we can retain out internal interface.
This is my opinion, but you can defer.


Thanks,
Devasish.



Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v3 4/4] [Interface Rate TLV] adding delay asymmetry calculation

[Geva, Erez]

On Tue, 2022-12-13 at 17:27 +0100, Erez Geva wrote:
On Tue, 2022-12-13 at 10:56 +0530, Devasish Dey wrote:
> +   /* Megabits per secon converted to attoseconds per bit. */
> +   return 1ULL/ iface->if_info.speed;
Performing division in running is not a very good idea.
It is better to perform the division when updating the speed and store
it in if_info.

I agree with Miroslav, calculation is better, I did not suggest using hard 
coded values, so not need to defend.
I simply suggest to move the calculation to where you set "if_info.speed".
So instead of calculate it every cycle, we only calculate when speed is changed.
Division is expensive (unless it is a left shift).
I usually compare new speed with old speed before calculate, if the speed is 
the same, so is the bit time :-)


Are you sure we need attoseconds (10^-18), we usually uses nanoseconds
(10^-9). I would except a better resolution, but that much?
Please explain your choosing.

> +}

[Devasish]:  The initial changes were with hardcoded values for the speed to 
avoid the calculation.
Miroslav suggested this way to have clean code.



Yes the calculation is based on attoseconds and not nanoseconds This is as per 
standard G.8275.2
From G.8275.2 (06/2021)


The linuxptp is mainly implement IEEE.
That does not means we can not support or use ITU standards,
but if you do, please add a comment with reference.
This applies as well as to choosing attoseconds.


This comment is also valid for the 'Uinteger64' type, as it is not currently 
used by IEEE,
 please add a comment it is used for ITU standard parameters.
If future IEEE will use the Uinteger64 too, we can remove the comment.


"
interfaceBitPeriod (Uinteger64)
The period of 1-bit of the transmitting PTP timestamp interface, excluding line 
encoding.
The value is encoded as an unsigned integer in units of attoseconds (10–18 s) 
to accommodate interface bit periods less than 1 ns."

Thanks,
Devasish.


Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v3 1/4] [Interface Rate TLV] function to support get interface speed via ethtool

[Geva, Erez]

On Tue, 2022-12-13 at 17:39 +0100, Erez Geva wrote:
On Tue, 2022-12-13 at 10:39 +0530, Devasish Dey wrote:
> +   goto failed;
> +   }

I think it is better to merge this ioctl and the socket creation with
sk_get_ts_info().
No reason for duplication.
You can use a static function or inline one.

> +
> +   if (ecmd.req.link_mode_masks_nwords >= 0 ||
> +   ecmd.req.cmd != ETHTOOL_GLINKSETTINGS) {
> +   return 1;
> +   }

[Devasish]: This can be done.

> +   /* clear data and ensure it is not marked valid */
> +   memset(if_info, 0, sizeof(struct sk_if_info));
> +   return -1;

You need to close the socket!
[Devasish]: Noted. Will be updated in the next patch.

> +struct sk_if_info {
> +   bool valid;
It is better not to use bool in a structure, as the size is usually
int, i.e. 64 bits to hold 1 bit.

[Devasish]: Earlier we had it as an integer. We can update it to uint8_t as 
well. But Richard suggested updating it to Boolean.
So, leaving this to Richard.

Good point, we can define a Boolean type using uint8_t for structures use.
But we can leave this decision to Richard.


> +   int speed;
What are the units here?
Old systems use 32 bits, if you measure in bits per second, the maximum
is 4 GB.
It is better to use uint64_t and use 1 mbps as units.
[Devasish]: It is the same as the speed in ethtool_link_settings which is a 
uint32_t variable and it is in Mbps.
Will change it to uint32_t and update the comments.

We do not have to follow the kernel ioctl type for speed, they tend to change 
them from time to time.
Probably, someone in the past choose 'int' as he did not predict future speed 
will pass 31 bits (int is signed).
And also the use of uintNN_t was not so common than.
But as sk.c is our internal layer, it can translate from kernel units and types 
to our application units and types.
You do provide internal structure and do not use the kernel one :-)
So if in the future the kernel will use a new ioctl  for speed as int will be 
too small, we can retain out internal interface.
This is my opinion, but you can defer.

Sorry, I miss reading your answer properly, please disregard this part.


Erez



Thanks,
Devasish.



Erez






___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v3 4/4] [Interface Rate TLV] adding delay asymmetry calculation

[Geva, Erez]

On Wed, 2022-12-07 at 17:34 +0530, SyncMonk Technologies wrote:
> Delay asymmetry calculation based on the PTP port interface speed of
> master obtained from TLV and the slave interface rate obtained by
> ethtool.
> 
> v3: updating network/host byte order handling.
> v1: initial commit
> 
> Signed-off-by: Greg Armstrong 
> Signed-off-by: Leon Goldin 
> Signed-off-by: Devasish Dey 
> Signed-off-by: Vipin Sharma 
> ---
>  interface.c   | 10 ++
>  interface.h   |  7 +++
>  port_private.h    |  1 +
>  port_signaling.c  | 39 ---
>  ptp4l.8   |  7 +++
>  tlv.c | 29 +
>  unicast_service.c | 32 
>  7 files changed, 122 insertions(+), 3 deletions(-)
> 
> diff --git a/interface.c b/interface.c
> index 3157e8c..02d530e 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -94,3 +94,13 @@ int interface_get_vclock(struct interface *iface)
>  {
> return iface->vclock;
>  }
> +
> +uint64_t interface_bitperiod(struct interface *iface)
> +{
> +   if (!iface->if_info.valid)
> +   return 0;
> +
> +   /* Megabits per secon converted to attoseconds per bit. */
> +   return 1ULL/ iface->if_info.speed;
Performing division in running is not a very good idea.
It is better to perform the division when updating the speed and store
it in if_info.

Are you sure we need attoseconds (10^-18), we usually uses nanoseconds
(10^-9). I would except a better resolution, but that much?
Please explain your choosing.

> +}
> +
> diff --git a/interface.h b/interface.h
> index f4b9545..7c9a6bd 100644
> --- a/interface.h
> +++ b/interface.h
> @@ -113,4 +113,11 @@ void interface_set_vclock(struct interface
> *iface, int vclock);
>   */
>  int interface_get_vclock(struct interface *iface);
>  
> +/**
> + * Obtains the interface bit period based on the speed.
Perhaps: "Obtains bit period based on interface speed."

> + * @param iface  The interface of interest.
We must be interesting "Pointer to the interface" can be suffiecnt :-)

> + * @return   if valid speed return interface bitperiod in atto
> seconds.
No need to make the return complicated, make it simple
 "return interface bit period in attoseconds".
We know functions handle errors. 

> + */
> +uint64_t interface_bitperiod(struct interface *iface);
> +
>  #endif
> diff --git a/port_private.h b/port_private.h
> index d6487eb..6ad4af8 100644
> --- a/port_private.h
> +++ b/port_private.h
> @@ -146,6 +146,7 @@ struct port {
> UInteger8   delay_response_counter;
> UInteger8   delay_response_timeout;
> bool    iface_rate_tlv;
> +   Integer64   portAsymmetry;
> struct PortStats    stats;
> struct PortServiceStats    service_stats;
> /* foreignMasterDS */
> diff --git a/port_signaling.c b/port_signaling.c
> index ed217c0..75a0689 100644
> --- a/port_signaling.c
> +++ b/port_signaling.c
> @@ -103,10 +103,37 @@ static int process_interval_request(struct port
> *p,
> return 0;
>  }
>  
> +static int process_interface_rate(struct port *p,
> + struct msg_interface_rate_tlv *r)
> +{
> +   Integer64 delayAsymmetry;
> +   double    nsDelay;
> +   Integer64 slaveBitPeriod;
> +   Integer64 masterBitPeriod;
> +
> +   if (p->iface_rate_tlv && interface_ifinfo_valid(p->iface)) {
> +   slaveBitPeriod = interface_bitperiod(p->iface);
> +   masterBitPeriod = r->interfaceBitPeriod;
> +
> +   /* Delay Asymmetry Calculation */
> +   nsDelay = (masterBitPeriod - slaveBitPeriod) / (2 *
> 1.0e9);
> +   delayAsymmetry =
> +   (r->numberOfBitsAfterTimestamp - r-
> >numberOfBitsBeforeTimestamp)  * nsDelay;
> +
> +   if (delayAsymmetry != p->portAsymmetry) {
> +   p->asymmetry += ((delayAsymmetry - p-
> >portAsymmetry) << 16);
> +   p->portAsymmetry = delayAsymmetry;
> +   }
> +   }
> +   return 0;
> +}
> +
>  int process_signaling(struct port *p, struct ptp_message *m)
>  {
> struct tlv_extra *extra;
> +   struct organization_tlv *org;
> struct msg_interval_req_tlv *r;
> +   struct msg_interface_rate_tlv *rate;
> int err = 0, result;
>  
> switch (p->state) {
> @@ -160,11 +187,17 @@ int process_signaling(struct port *p, struct
> ptp_message *m)
> break;
>  
> case TLV_ORGANIZATION_EXTENSION:
> -   r = (struct msg_interval_req_tlv *) extra-
> >tlv;
> +   org = (struct organization_tlv *)extra->tlv;
>  
> -   if (0 == memcmp(r->id, ieee8021_id,
> sizeof(ieee8021_id)) &&
> -   r->subtype[0] == 0 && r->subtype[1] == 0
> && r->subtype[2] == 2)
> +   if (0 == memcmp(org->id, 

Re: [Linuxptp-devel] [PATCH v3 3/4] [Interface Rate TLV] organization TLV support for interface rate

[Geva, Erez]

On Wed, 2022-12-07 at 17:34 +0530, SyncMonk Technologies wrote:
> adding interface rate TLV as defined by ITU-T G.8275.2 Annex D to
> enable master to communicate PTP port interface rate to slave.
> 
> Signed-off-by: Greg Armstrong 
> Signed-off-by: Leon Goldin 
> Signed-off-by: Devasish Dey 
> Signed-off-by: Vipin Sharma 
> ---
>  config.c   |  1 +
>  pdt.h  |  1 +
>  port.c |  1 +
>  port_private.h |  1 +
>  tlv.c  |  1 +
>  tlv.h  | 14 ++
>  6 files changed, 19 insertions(+)
> 
> diff --git a/config.c b/config.c
> index 08e3346..2fa95fc 100644
> --- a/config.c
> +++ b/config.c
> @@ -267,6 +267,7 @@ struct config_item config_tab[] = {
> PORT_ITEM_INT("inhibit_delay_req", 0, 0, 1),
> PORT_ITEM_INT("inhibit_multicast_service", 0, 0, 1),
> GLOB_ITEM_INT("initial_delay", 0, 0, INT_MAX),
> +   PORT_ITEM_INT("interface_rate_tlv", 0, 0, 1),
> GLOB_ITEM_INT("kernel_leap", 1, 0, 1),
> GLOB_ITEM_STR("leapfile", NULL),
> PORT_ITEM_INT("logAnnounceInterval", 1, INT8_MIN, INT8_MAX),
> diff --git a/pdt.h b/pdt.h
> index e46b218..1ad23d4 100644
> --- a/pdt.h
> +++ b/pdt.h
> @@ -39,6 +39,7 @@ typedef uint16_t  UInteger16;
>  typedef int32_t   Integer32;
>  typedef uint32_t  UInteger32;
>  typedef int64_t   Integer64;
> +typedef uint64_t  UInteger64;
IEEE 1588-2019 only define Integer64, but not UInteger64.
Not sure why, but probably there is no UInteger64 in IEEE standard.
Are you using UInteger64 for a standard parameter/variables?

>  typedef uint8_t   Octet;
>  
>  #endif
> diff --git a/port.c b/port.c
> index 7fd50dd..85cfa4a 100644
> --- a/port.c
> +++ b/port.c
> @@ -1854,6 +1854,7 @@ int port_initialize(struct port *p)
> p->neighborPropDelayThresh = config_get_int(cfg, p->name,
> "neighborPropDelayThresh");
> p->min_neighbor_prop_delay = config_get_int(cfg, p->name,
> "min_neighbor_prop_delay");
> p->delay_response_timeout  = config_get_int(cfg, p->name,
> "delay_response_timeout");
> +   p->iface_rate_tlv  = config_get_int(cfg, p->name,
> "interface_rate_tlv");
>  
> if (config_get_int(cfg, p->name, "asCapable") ==
> AS_CAPABLE_TRUE) {
> p->asCapable = ALWAYS_CAPABLE;
> diff --git a/port_private.h b/port_private.h
> index d27dceb..d6487eb 100644
> --- a/port_private.h
> +++ b/port_private.h
> @@ -145,6 +145,7 @@ struct port {
> UInteger8   versionNumber; /* UInteger4 */
> UInteger8   delay_response_counter;
> UInteger8   delay_response_timeout;
> +   bool    iface_rate_tlv;
Again, using bool in structure is unwise.
Better use uint8_t and not UInteger8, so we now it is not standard type
and with a comment saying it holds a boolean value.

> struct PortStats    stats;
> struct PortServiceStats    service_stats;
> /* foreignMasterDS */
> diff --git a/tlv.c b/tlv.c
> index 1c13460..35bee4f 100644
> --- a/tlv.c
> +++ b/tlv.c
> @@ -35,6 +35,7 @@
> (tlv->length < sizeof(struct type) - sizeof(struct TLV))
>  
>  uint8_t ieee8021_id[3] = { IEEE_802_1_COMMITTEE };
> +uint8_t itu_t_id[3] = { ITU_T_COMMITTEE };
>  
>  static TAILQ_HEAD(tlv_pool, tlv_extra) tlv_pool =
> TAILQ_HEAD_INITIALIZER(tlv_pool);
> diff --git a/tlv.h b/tlv.h
> index 8966696..ec22e2f 100644
> --- a/tlv.h
> +++ b/tlv.h
> @@ -395,6 +395,20 @@ struct tlv_extra {
> };
>  };
>  
> +/* Organizationally Unique Identifiers */
> +#define ITU_T_COMMITTEE 0x00, 0x19, 0xA7
> +extern uint8_t itu_t_id[3];
> +
> +struct msg_interface_rate_tlv {
> +   Enumeration16 type;
> +   UInteger16    length;
> +   Octet id[3];
> +   Octet subtype[3];
> +   UInteger64    interfaceBitPeriod;
> +   UInteger16    numberOfBitsBeforeTimestamp;
> +   UInteger16    numberOfBitsAfterTimestamp;
> +} PACKED;
> +
>  /**
>   * Allocates a new tlv_extra structure.
>   * @return  Pointer to a new structure on success or NULL otherwise.


Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v3 1/4] [Interface Rate TLV] function to support get interface speed via ethtool

[Geva, Erez]

On Wed, 2022-12-07 at 17:34 +0530, SyncMonk Technologies wrote:
> When master and slave instance interacting with each other operating
> at different interface speed, delay assymetry needs to be compensated
> as described in G.8271 appendix V.
> 
> In this patch we are adding changes to get the interface speed using
> ethtool.
> 
> v1: initial commit.
> v2: updating comments and data types.
> v3: updating Boolean data type to bool from 
> ---
>  sk.c | 71
> 
>  sk.h | 19 
>  2 files changed, 90 insertions(+)
> 
> diff --git a/sk.c b/sk.c
> index d27abff..1d1a656 100644
> --- a/sk.c
> +++ b/sk.c
> @@ -205,6 +205,77 @@ failed:
> return -1;
>  }
>  
> +int sk_get_if_info(const char *name, struct sk_if_info *if_info)
> +{
> +#ifdef ETHTOOL_GLINKSETTINGS
> +   struct ifreq ifr;
> +   int fd, err;
> +
> +   struct {
> +   struct ethtool_link_settings req;
> +   /*
> +    * link_mode_data consists of supported[],
> advertising[],
> +    * lp_advertising[] with size up to 127 each.
> +    * The actual size is provided by the kernel.
> +    */
> +   __u32 link_mode_data[3 * 127];
> +   } ecmd;
> +
> +   memset(, 0, sizeof(ifr));
> +   memset(, 0, sizeof(ecmd));
> +
> +   fd = socket(AF_INET, SOCK_DGRAM, 0);
> +   if (fd < 0) {
> +   goto failed;
> +   }
> +
> +   ecmd.req.cmd = ETHTOOL_GLINKSETTINGS;
> +
> +   strncpy(ifr.ifr_name, name, IFNAMSIZ - 1);
> +   ifr.ifr_data = (char *) 
> +
> +   /* Handshake with kernel to determine number of words for
> link
> +    * mode bitmaps. When requested number of bitmap words is not
> +    * the one expected by kernel, the latter returns the integer
> +    * opposite of what it is expecting. We request length 0
> below
> +    * (aka. invalid bitmap length) to get this info.
> +    */
> +   err = ioctl(fd, SIOCETHTOOL, );
> +   if (err < 0) {
> +   pr_err("ioctl SIOCETHTOOL failed: %m");
> +   close(fd);
> +   goto failed;
> +   }

I think it is better to merge this ioctl and the socket creation with
sk_get_ts_info().
No reason for duplication.
You can use a static function or inline one.

> +
> +   if (ecmd.req.link_mode_masks_nwords >= 0 ||
> +   ecmd.req.cmd != ETHTOOL_GLINKSETTINGS) {
> +   return 1;
> +   }
> +   ecmd.req.link_mode_masks_nwords = -
> ecmd.req.link_mode_masks_nwords;
> +
> +   err = ioctl(fd, SIOCETHTOOL, );
> +   if (err < 0) {
> +   pr_err("ioctl SIOCETHTOOL failed: %m");
> +   close(fd);
> +   goto failed;
> +   }
> +
> +   close(fd);
> +
> +   /* copy the necessary data to sk_info */
> +   memset(if_info, 0, sizeof(struct sk_if_info));
> +   if_info->valid = 1;
> +   if_info->speed = ecmd.req.speed;
> +
> +   return 0;
> +failed:
> +#endif
> +   /* clear data and ensure it is not marked valid */
> +   memset(if_info, 0, sizeof(struct sk_if_info));
> +   return -1;

You need to close the socket!

> +}
> +
> +
>  static int sk_interface_guidaddr(const char *name, unsigned char
> *guid)
>  {
> char file_name[64], buf[64], addr[8];
> diff --git a/sk.h b/sk.h
> index 486dbc4..4cee3d7 100644
> --- a/sk.h
> +++ b/sk.h
> @@ -20,6 +20,7 @@
>  #ifndef HAVE_SK_H
>  #define HAVE_SK_H
>  
> +#include 
>  #include "address.h"
>  #include "transport.h"
>  
> @@ -49,6 +50,16 @@ struct sk_ts_info {
> unsigned int rx_filters;
>  };
>  
> +/**
> + * Contains interface information returned by theGLINKSETTINGS
> ioctl.
> + * @valid:    set to non-zero when the info struct contains
> valid data.
> + * @speed:    interface speed.
> + */
> +struct sk_if_info {
> +   bool valid;
It is better not to use bool in a structure, as the size is usually
int, i.e. 64 bits to hold 1 bit.

> +   int speed;
What are the units here?
Old systems use 32 bits, if you measure in bits per second, the maximum
is 4 GB.
It is better to use uint64_t and use 1 mbps as units.

> +};
> +
>  /**
>   * Obtains a socket suitable for use with sk_interface_index().
>   * @return  An open socket on success, -1 otherwise.
> @@ -78,6 +89,14 @@ int sk_general_init(int fd);
>   */
>  int sk_get_ts_info(const char *name, struct sk_ts_info *sk_info);
>  
> +/**
> + * Obtain supporte interface information
> + * @param name The name of the interface
> + * @param info  Struct containing obtained interface
> information.
> + * @return  zero on success, negative on failure.
> + */
> +int sk_get_if_info(const char *name, struct sk_if_info *sk_info);
> +
>  /**
>   * Obtain the MAC address of a network interface.
>   * @param name  The name of the interface


Erez


___
Linuxptp-devel mailing list

Re: [Linuxptp-devel] [PATCH 1/1] clock: Fix stale clock parent pid usage after best master change

[Geva, Erez]

On Mon, 2022-12-05 at 12:52 -0500, vincent.cheng...@renesas.com wrote:
> On Mon, Dec 05, 2022 at 02:44:07AM EST, Geva, Erez wrote:
> > On Fri, 2022-12-02 at 15:33 -0500,
> > vincent.cheng...@renesas.com wrote:
> > > From: Vincent Cheng 
> > > 
> > > In handle_state_decision_event(), the update of the clock's
> > > parent
> > > pid after
> > > best master change is non-deterministic. It depends on the port
> > > processing
> > > order and bmc_state_decision() results.
> > > 
> > > +static void clock_update_parent_identity(struct clock *c)
> > > +{
> > > +   struct parentDS *pds = >dad.pds;
> > > +
> > > +   if (c->best) {
> > > +   pds->parentPortIdentity = c->best-
> > > >dataset.sender;
> > > +   } else {
> > > +   pds->parentPortIdentity.clockIdentity = c-
> > > > dds.clockIdentity;
> > > +   pds->parentPortIdentity.portNumber    = 0;
> > 
> > Why is the port 0?
> > It make sense that defaultDS do not have port as we work in the
> > context
> > of the clock.
> > Is it make sense to use port ID here?
> 
> I would like to say it is port 0 because I consulted 1588-2019.pdf
> and found the
> requirement in "Table 30 - Updates for state decision code M1 and
> M2".
> 
>   parentDS.clockIdentity member set to the value of
> defaultDS.clockIdentity field.
>   parentDS.parentPortIdentity.portNumber member is 0
> 
> However, realistically speaking, I copied the logic from
> clock_update_grandmaster()
> and clock_update_slave() first and then looked it up afterwards.

Make sense, please live a comment on the value assignment :-)

Something like ~ "follow IEEE table 30 updates for M1".
No need for a long one, just a short reference.

Erez

> 
> > 
> > 
> > > +   }
> > > +}
> > > +
> > >  static int clock_utc_correct(struct clock *c, tmv_t ingress)
> > >  {
> > > struct timespec offset;
> > > @@ -2015,6 +2027,8 @@ static void
> > > handle_state_decision_event(struct
> > > clock *c)
> > > c->best = best;
> > > c->best_id = best_id;
> > >  
> > > +   clock_update_parent_identity(c);
> > > +
> > > LIST_FOREACH(piter, >ports, list) {
> > > enum port_state ps;
> > > enum fsm_event event;
> > 
> > 
> > P.S.
> > All patches should be on top of master, no need to comment on
> > obvious.
> 
> Ok, will leave out commit next time if it's not needed. Thanks.
> 
> Vincent

-- 
Erez Geva
Siemens AG
www.siemens.com

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use PTP_CLOCK_GETCAPS2 ioctl if available

[Geva, Erez]

On Wed, 2022-12-07 at 06:59 -0800, Richard Cochran wrote:
> On Thu, Nov 17, 2022 at 02:15:23PM -0800, Jacob Keller wrote:
> > On 11/17/2022 1:34 PM, Geva, Erez wrote:
> 
> > > The problem is the fallback works only on build.
> > > But if the build system is newer than the running system, the
> > > fallback
> > > will fail, as you will use the PTP_CLOCK_GETCAPS2 which does not
> > > exist
> > > on the running old system.
> > > 
> > 
> > Fair. We likely have the same problem with some of the other "2"
> > ioctls,
> > since they're handled in a similar way. I think we do the Right(TM)
> > thing
> > for the sysoff.c where we probe the kernel at run-time. This could
> > be done
> > here but is probably not really worth it considering that
> > PTP_CLOCK_GETCAPS
> > functions the same way as PTP_CLOCK_GETCAPS2 for all kernels I
> > checked... So
> > I guess this is somewhat less likely.
> 
> Jacob, do you want to have phc_ctl fall back to PTP_CLOCK_GETCAPS at
> run time if PTP_CLOCK_GETCAPS2 fails?

We can use run-time fallback.
But personalty, I do not think it worth it.
Using PTP_CLOCK_GETCAPS2 is only done for one new field in a debug
tool.
We can simply wait till PTP_CLOCK_GETCAPS become obsolete or we have a
new PTP_CLOCK_GETCAPS3 to handle.

> 
> > I'm not sure if our other PTP ioctls are checked properly like this
> > at run
> > time...
> 
> Maybe, but only because of sloppiness.  Better to support older
> kernels at run time, as this is more user friendly.
> 
> Working on embedded systems over the years, I've have often been that
> user, and, believe me, it is super annoying when the latest greatest
> App isn't backwards compatible.

My view too :-)

> 
> Thanks,
> Richard


Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/1] clock: Fix stale clock parent pid usage after best master change

[Geva, Erez]

On Fri, 2022-12-02 at 15:33 -0500, vincent.cheng...@renesas.com wrote:
> From: Vincent Cheng 
> 
> In handle_state_decision_event(), the update of the clock's parent
> pid after
> best master change is non-deterministic. It depends on the port
> processing
> order and bmc_state_decision() results.
> 
> Subsequent call to unicast_client_state_changed() via port_dispatch()
> may use
> stale parent pid and place UC FSM in wrong state.
> 
> 
> Signed-off-by: Vincent Cheng 
> ---
>  clock.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/clock.c b/clock.c
> index 8177e77..55ca8d3 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -709,6 +709,18 @@ static void clock_update_slave(struct clock *c)
> clock_update_time_properties(c, tds);
>  }
>  
> +static void clock_update_parent_identity(struct clock *c)
> +{
> +   struct parentDS *pds = >dad.pds;
> +
> +   if (c->best) {
> +   pds->parentPortIdentity = c->best->dataset.sender;
> +   } else {
> +   pds->parentPortIdentity.clockIdentity = c-
> >dds.clockIdentity;
> +   pds->parentPortIdentity.portNumber    = 0;

Why is the port 0?
It make sense that defaultDS do not have port as we work in the context
of the clock.
Is it make sense to use port ID here?


> +   }
> +}
> +
>  static int clock_utc_correct(struct clock *c, tmv_t ingress)
>  {
> struct timespec offset;
> @@ -2015,6 +2027,8 @@ static void handle_state_decision_event(struct
> clock *c)
> c->best = best;
> c->best_id = best_id;
>  
> +   clock_update_parent_identity(c);
> +
> LIST_FOREACH(piter, >ports, list) {
> enum port_state ps;
> enum fsm_event event;


P.S.
All patches should be on top of master, no need to comment on obvious.
The rest of the explantation is perfect :-)

Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use PTP_CLOCK_GETCAPS2 ioctl if available

[Geva, Erez]

On Thu, 2022-11-17 at 18:27 +, Keller, Jacob E wrote:
> 
> 
> > -Original Message-
> > From: Geva, Erez 
> > Sent: Thursday, November 17, 2022 9:13 AM
> > To: Keller, Jacob E ; linuxptp-
> > de...@lists.sourceforge.net
> > Subject: Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use
> > PTP_CLOCK_GETCAPS2
> > ioctl if available
> > 
> > On Tue, 2022-11-15 at 16:43 -0800, Jacob Keller wrote:
> > > The PTP_CLOCK_GETCAPS2 ioctl is provided by kernel as a
> > > replacement
> > > for the
> > > original PTP_CLOCK_GETCAPS ioctl. This was done in order to
> > > provide
> > > ioctls
> > > which guarantee reserved fields are properly initialized. In
> > > practice
> > > the
> > > PTP_CLOCK_GETCAPS2 and PTP_CLOCK_GETCAPS both behave identically
> > > since
> > 
> > Exactly, that is why I send a patch to add the new 'adjust_phase'
> > in
> > do_caps(), without changing the ioctl itself :-)
> > 
> > 
> 
> The reason PTP_CLOCK_GETCAPS2 was created was around the same time as
> the other ioctls were fixed to properly a) validate reserved fields
> and b) ensure that all reported reserved fields were zeroed.
> 
> Functionally its 100% identical to PTP_CLOCK_GETCAPS because this
> ioctl already did the right thing.
> 
> The reason I propose switching to PTP_CLOCK_GETCAPS2 over
> PTP_CLOCK_GETCAPS is because it reduces cognitive burden to REMEMBER
> that the old PTP_CLOCK_GETCAPS is ok. All I remembered was "the non-2
> ioctls might be broken and not receive new features".
> 
> > > PTP_CLOCK_GETCAPS always zeroed the caps structure. However, it
> > > is
> > > good
> > > practice to use the newer version consistently.
> > 
> > But, it can also breaks when using the new linuxptp version build
> > on
> > new  machine, but used with old kernel.
> > It may be reasonable in few years, when these old kernels becomes
> > obsolete.
> 
> This uses a fallback to PTP_CLOCK_GETCAPS if PTP_CLOCK_GETCAPS2 is
> not found.

The problem is the fallback works only on build.
But if the build system is newer than the running system, the fallback
will fail, as you will use the PTP_CLOCK_GETCAPS2 which does not exist
on the running old system.

If I may, this is the classic gap, Hardware companies fail to
understand.

Erez

> 
> > But since the new PTP_CLOCK_GETCAPS2 was introduce in 2019, I think
> > we
> > should wait with it.
> > As not everyone build linuxptp, most users use pre-build.
> > 
> > 
> > > 
> > > Signed-off-by: Jacob Keller 
> > > ---
> > > Technically this is identical in current kernels, both ioctls
> > > return
> > > exactly
> > > the same conent.. I still think its better to use the '2'
> > > variants in
> > > principle that developer doesn't have to remember "is this
> > > variant ok
> > > to get
> > > all the new features going forward?"
> > 
> > There are more 12 bytes in the reserve.
> > I guess once we pass them, we would need a non-backward flag, but
> > till
> > then, I think we can keep using the PTP_CLOCK_GETCAPS flag, and
> > leave
> > the new flags in do_caps().
> > 
> 
> The only motiviation for this patch is consistency in using the "2"
> style ioctls across ptp4l, because it makes it less likely someone
> will use the non-2 version of an ioctl that actually does have
> behavioral differences in the future. 
> 
> Thanks,
> Jake
> 
> > Erez
> > 
> > > 
> > >  missing.h | 7 +++
> > >  phc_ctl.c | 2 +-
> > >  2 files changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/missing.h b/missing.h
> > > index 79a87d425993..41427d3a38b2 100644
> > > --- a/missing.h
> > > +++ b/missing.h
> > > @@ -98,6 +98,13 @@ enum {
> > >  #define PTP_PEROUT_REQUEST2 PTP_PEROUT_REQUEST
> > >  #endif
> > > 
> > > +#ifdef PTP_CLOCK_GETCAPS2
> > > +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS2
> > failed:
> > > %m"
> > > +#else
> > > +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS
> > > failed:
> > > %m"
> > > +#define PTP_CLOCK_GETCAPS2 PTP_CLOCK_GETCAPS
> > > +#endif
> > > +
> > >  #if LINUX_VERSION_CODE < KERNEL_VERSION(5,8,0)
> > > 
> > >  /* from upcoming Linux kernel version 5.8 */
> > > diff --git a/phc_ctl.c b/phc_ctl.c
> > > index 6a5c2f43d7c9..17a615f8aae6 100644
> > > --- a/phc_ctl.c
> > > +++ b/phc_ctl.c
> > > @@ -288,7 +288,7 @@ static int do_caps(clockid_t clkid, int cmdc,
> > > char *cmdv[])
> > > return 0;
> > > }
> > > 
> > > -   if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS,
> > > )) {
> > > +   if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS2,
> > > )) {
> > > pr_err("get capabilities failed: %s",
> > > strerror(errno));
> > > return -1;
> 


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] bmc: Fix PortId comparison

[Geva, Erez]

On Mon, 2022-11-14 at 14:25 +0100, Luigi Mantellini wrote:
> The PortId is defined as a couple of ClockId (an 8-bytes opaque) and
> the PortNumber (UInterger16).
> In order to correctly handle the PortId endianess, the comparison has
> been split in the ClockIds comparison (using memcmp) and PortNumber
> comparison.

You code do not solve any endianess issue.
The clock ID is byte stream.
And port number is 16 bits, it require converting from network order to
host order, which you do not need here. Becuase port ID are already in
the same endian here.

As struct PortIdentity is defined as "PACKED", it should not have any
pad that may cause the memory compare to fail. Of having different
values in the pad.


So memcmp and your "portid_cmp" should give the same result.

I would suggest to replace the memcmp and "portid_cmp" with existing
pid_eq(const struct PortIdentity *a, const struct PortIdentity *b)


And debug and find the real reason you have the bug.
And than send a real bug fix :-)


Erez




> ---
>  bmc.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/bmc.c b/bmc.c
> index 6ac7aa0..ebc0789 100644
> --- a/bmc.c
> +++ b/bmc.c
> @@ -21,6 +21,17 @@
>  #include "bmc.h"
>  #include "ds.h"
>  
> +static int portid_cmp(struct PortIdentity *a, struct PortIdentity
> *b)
> +{
> +   int diff = memcmp(>clockIdentity, >clockIdentity,
> sizeof(a->clockIdentity));
> +
> +   if (diff == 0) {
> +   diff = a->portNumber - b->portNumber;
> +   }
> +
> +   return diff;
> +}
> +
>  int dscmp2(struct dataset *a, struct dataset *b)
>  {
> int diff;
> @@ -35,7 +46,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
>  * standard, since there is nothing we can do about it
> anyway.
>  */
> if (A < B) {
> -   diff = memcmp(>receiver, >sender, sizeof(b-
> >receiver));
> +   diff = portid_cmp(>receiver, >sender);
> if (diff < 0)
> return A_BETTER;
> if (diff > 0)
> @@ -44,7 +55,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> return 0;
> }
> if (A > B) {
> -   diff = memcmp(>receiver, >sender, sizeof(a-
> >receiver));
> +   diff = portid_cmp(>receiver, >sender);
> if (diff < 0)
> return B_BETTER;
> if (diff > 0)
> @@ -53,7 +64,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> return 0;
> }
>  
> -   diff = memcmp(>sender, >sender, sizeof(a->sender));
> +   diff = portid_cmp(>sender, >sender);
> if (diff < 0)
> return A_BETTER_TOPO;
> if (diff > 0)


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] remove C99 style loop variable declarations

[Geva, Erez]

On Thu, 2022-11-17 at 08:02 +, Magnus Armholt via Linuxptp-devel
wrote:
> Nothing to complain about the patch, thanks for looking after the
> code base!
> 
> > LinuxPTP source still prefers to keep with the GNU C89 convention
> > of
> > variables being at the top of the function. Newer versions of GCC
> > have
> > begun defaulting to a newer C standard, which explains how these
> > slipped in.
> > Note that directly enforcing "-std=c89" does not work because we
> > rely on
> > some GNU extensions of C89.
> 
> Has there been any discussion about this topic? If it is hard to
> verify the code, then these
> mistakes will keep on slipping in. Is there a script or ReadMe
> somewhere, listing the needed
> compiler flags to be used in order to use the "correct" C89?
> 
> C89 is now > 30y old, any plans when to move to a more modern
> version?

It is the standard, not the compiler.
As it may, that I might prefer differently.

It does make sense to use old standard with new compilers.
New compilers and new libc support old standards.
No reason to update standard for them.
The standard is more for developers convenient.
And in case we want to use new functionality added in new standard.

> 
> Linux is from time to time dropping support for old things, 

Linux uses and relys on GNU extensions.
As much as I appropriate Linux and Linus, their approach is not the
holly grill.
Richard may differ.

I do not object to use a newer standard or stay with the old one,
 as long as we are coherent.

> so although being a project that try to support as many devices as
> possible, it is possible

As the newest compilers support old standard.
And new compilers can compile to very old devices.
I do not see any connection between old devices and old standard.
They are not a reason to select standard.

As long as you can update linuxptp, you can probably update the libc.
If you can't, than no reason to update linuxptp either.

> to move to more modern versions, if it is announced in time and in
> accordance with a plan.


> 
> BR,
> Magnus Armholt
> 
> 
> 
> 
> 
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7C8b9983f7486248beb86308dac8771ed9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638042711193699884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Kq2Tj%2FHyfp5x5fj8qFsLcuoUozMtBY9ZiLS%2FtT9mnv0%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/2] phc_ctl: explicitly check for adjust_phase definition

[Geva, Erez]

On Tue, 2022-11-15 at 16:43 -0800, Jacob Keller wrote:
> The PTP_CLOCK_GETCAPS ioctl call in phc_ctl has a conditional check
> for
> whether to report the caps.adjust_phase bit. This is always set for
> both
> PTP_CLOCK_GETCAPS and PTP_CLOCK_GETCAPS2, and was always zero before
> the
> bit was moved from being reserved to indicate the adjust_phase.
> 
> In some sense if we lack PTP_CLOCK_GETCAPS2 we know the kernel won't
> report
> adjust_phase, but in reality such kernel versions did not have
> adjust_phase at all.
> 
> There's no reason to make this check against PTP_CLOCK_GETCAPS2.
> Instead,
> scan the ptp_clock.h header file and check if we have adjust_phase
> support.
> Use this new flag instead of PTP_CLOCK_GETCAPS2.
> 
> Signed-off-by: Jacob Keller 
> ---
> Checking against PTP_CLOCK_GETCAPS2 is wrong because this is not when
> the
> adjust_phase was actually introduced. A direct check against whats in
> the
> header is more accurate.


This make sense.
Thanks for the correction :-)

> 
>  incdefs.sh | 5 +
>  phc_ctl.c  | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/incdefs.sh b/incdefs.sh
> index 21333e5109e9..a9e94f777f6b 100755
> --- a/incdefs.sh
> +++ b/incdefs.sh
> @@ -63,6 +63,7 @@ kernel_flags()
>  {
> prefix=""
> tstamp=/usr/include/linux/net_tstamp.h
> +   ptp_clock=/usr/include/linux/ptp_clock.h

Is that catch if using kernel headers?
The location in the current kernel is
/include/uapi/linux/ptp_clock.h

I see you add in the same way, perhaps we need to update the script?


>  
> if [ "x$KBUILD_OUTPUT" != "x" ]; then
> # With KBUILD_OUTPUT set, we are building against
> @@ -90,6 +91,10 @@ kernel_flags()
> if grep -q SOF_TIMESTAMPING_BIND_PHC ${prefix}${tstamp}; then
> printf " -DHAVE_VCLOCKS"
> fi
> +
> +   if grep -q adjust_phase ${prefix}${ptp_clock}; then
> +   printf " -DHAVE_PTP_CAPS_ADJUST_PHASE"
> +   fi
>  }
>  
>  flags="$(user_flags)$(kernel_flags)"
> diff --git a/phc_ctl.c b/phc_ctl.c
> index 92e597c40a23..6a5c2f43d7c9 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -311,7 +311,7 @@ static int do_caps(clockid_t clkid, int cmdc,
> char *cmdv[])
> caps.n_pins,
> caps.pps ? "has" : "doesn't have",
> caps.cross_timestamping ? "has" : "doesn't have",
> -   #ifdef PTP_CLOCK_GETCAPS2
> +   #ifdef HAVE_PTP_CAPS_ADJUST_PHASE
> caps.adjust_phase ? "has" : "doesn't have"
> #else
> "no information regarding"


Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 0/1] Configurable VLAN tags for Ethernet

[Geva, Erez]

On Thu, 2022-11-17 at 13:43 +0200, Magnus Armholt wrote:
> Add possibility to configure VLAN tags for ethernet.
> 
> We mainly use PTP in slave mode so this has been developed
> primarly for the sync request. 
> The raw_send function is used by a lot of functionality, so input 
> on what we could have missed (especially from master point of view)
> is appreciated.

The idea is nice.
I personally in favour of more options of using VLANs.

If you add an option for using VLAN out of band (instead of using Linux
VLANs interfaces), it should be complete. i.e. you should implement the
receive side.

You can filter the received packets using a kernel BPF filter, to
filter only the wanted VLAN id and PTP packets.

Erez


> 
> Mika Paulamäki (1):
>   Add configurable VLAN tags for Ethernet
> 
>  config.c |  3 +++
>  raw.c    | 47 +++
>  2 files changed, 42 insertions(+), 8 deletions(-)
> 


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use PTP_CLOCK_GETCAPS2 ioctl if available

[Geva, Erez]

On Tue, 2022-11-15 at 16:43 -0800, Jacob Keller wrote:
> The PTP_CLOCK_GETCAPS2 ioctl is provided by kernel as a replacement
> for the
> original PTP_CLOCK_GETCAPS ioctl. This was done in order to provide
> ioctls
> which guarantee reserved fields are properly initialized. In practice
> the
> PTP_CLOCK_GETCAPS2 and PTP_CLOCK_GETCAPS both behave identically
> since

Exactly, that is why I send a patch to add the new 'adjust_phase' in
do_caps(), without changing the ioctl itself :-)


> PTP_CLOCK_GETCAPS always zeroed the caps structure. However, it is
> good
> practice to use the newer version consistently.

But, it can also breaks when using the new linuxptp version build on
new  machine, but used with old kernel.
It may be reasonable in few years, when these old kernels becomes
obsolete.
But since the new PTP_CLOCK_GETCAPS2 was introduce in 2019, I think we
should wait with it.
As not everyone build linuxptp, most users use pre-build.


> 
> Signed-off-by: Jacob Keller 
> ---
> Technically this is identical in current kernels, both ioctls return
> exactly
> the same conent.. I still think its better to use the '2' variants in
> principle that developer doesn't have to remember "is this variant ok
> to get
> all the new features going forward?"

There are more 12 bytes in the reserve.
I guess once we pass them, we would need a non-backward flag, but till
then, I think we can keep using the PTP_CLOCK_GETCAPS flag, and leave
the new flags in do_caps().

Erez

> 
>  missing.h | 7 +++
>  phc_ctl.c | 2 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/missing.h b/missing.h
> index 79a87d425993..41427d3a38b2 100644
> --- a/missing.h
> +++ b/missing.h
> @@ -98,6 +98,13 @@ enum {
>  #define PTP_PEROUT_REQUEST2 PTP_PEROUT_REQUEST
>  #endif
>  
> +#ifdef PTP_CLOCK_GETCAPS2
> +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS2 failed:
> %m"
> +#else
> +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS failed:
> %m"
> +#define PTP_CLOCK_GETCAPS2 PTP_CLOCK_GETCAPS
> +#endif
> +
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(5,8,0)
>  
>  /* from upcoming Linux kernel version 5.8 */
> diff --git a/phc_ctl.c b/phc_ctl.c
> index 6a5c2f43d7c9..17a615f8aae6 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -288,7 +288,7 @@ static int do_caps(clockid_t clkid, int cmdc,
> char *cmdv[])
> return 0;
> }
>  
> -   if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS, )) {
> +   if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS2, )) {
> pr_err("get capabilities failed: %s",
> strerror(errno));
> return -1;


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 0/5] *** Add support for configurable data set members in ptp4l ***

[Geva, Erez]

Hi,

Personally I am in favour of more management messages.

But:

We did not add the option to set masterOnly and slaveOnly, as the ptp4l do not 
support setting them in run time.
A restart is needed for these flags, making the set useless.
If you do manage to change the masterOnly and slaveOnly on run-time, we would 
be very glad, but please verify, before patching.
We did not forget to write the set, we did read the standard 

As for domain number, in addition to support, change on run time.
There is the carpet effect, as the management protocol relay on domain number 
to communicate with the ptp4l.
Changing on run time might cause us to loos the management communication with 
the ptp4l itself, in case we are unaware
 someone else might change the domain number, the management interface is 
insecure.
So, perhaps it is better to leave the set disabled in any case.

As for announceReceiptTimeout, not sure why we did not add set, perhaps the 
same run time issue, worth testing.

As for maxStepsRemoved, in general It look a good idea, though I wonder, why 
did IEEE did not define a standard management TLV for it?
We need to test it in run-time before we add a management set, the get you can 
add in any case.

Erez


-Original Message-
From: izunna.otiji...@renesas.com  
Sent: Wednesday, 2 November 2022 22:33
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH 0/5] *** Add support for configurable data set 
members in ptp4l ***

From: Izunna Otiji 

*** The IEEE 1588 standard describes a SET action for the PTP management 
message, however, ptp4l is missing the implementation of some of these SET 
actions. This patch adds the SET action for the following configurable dataset 
members, as needed by the ITU-T Telecom Profiles (G.8265.1, G.8275.1, G.8275.2):

defaultDS.domainNumber  (managementId DOMAIN)
defaultDS.slaveOnly (managementId SLAVE_ONLY)
defaultDS.maxStepsRemoved   (*new* managementId 
MAX_STEPS_REMOVED_NP (0xC00A))

portDS.announceReceiptTimeout   (managementId ANNOUNCE_RECEIPT_TIMEOUT)
portDS.masterOnly   (managementId MASTER_ONLY) ***

Izunna Otiji (5):
  ptp4l: Add SET for defaultDS.domainNumber
  ptp4l: Add SET for defaultDS.slaveOnly
  ptp4l: Add SET for portDS.announceReceiptTimeout
  ptp4l: Add SET for portDS.masterOnly
  ptp4l: Add SET for defaultDS.maxStepsRemoved

 clock.c  | 26 ++
 pmc.c|  5 +
 pmc_common.c | 15 +++
 port.c   | 11 +++
 tlv.h|  1 +
 5 files changed, 54 insertions(+), 4 deletions(-)

-- 
2.37.2


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7Ca4ddbe4285454cb2efc508dabd1a27de%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638030217279130687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=z9H3UuewDspsHkb8iIquQl0gjGrM3VNPbcgeVoRmH%2Bo%3Dreserved=0

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] phc_ctl: add pin_cfg command to display pin functions

[Geva, Erez]

Already have it in
https://github.com/erezgeva/libptpmgmt/blob/master/src/ptp.h

Erez 

-Original Message-
From: Miroslav Lichvar  
Sent: Thursday, 27 October 2022 17:00
To: Jacob Keller 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] phc_ctl: add pin_cfg command to display 
pin functions

On Thu, Oct 27, 2022 at 03:32:48AM -0700, Jacob Keller wrote:
> Add a new function to phc_ctl to display the devices pin configuration 
> data. First, obtain the device capabilities to determine the number of 
> pins. Then, for each pin, print the name, function, and channel 
> information.

Nice feature. In a quick test, it printed the state correctly after setting it 
with "testptp -L".

Do you plan to add also pin_set?

--
Miroslav Lichvar



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7C251d114a1038480f9d8c08dab82c36a2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638024797280276161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Mmcyv9SWoG8j5HkvEwD%2F7wADQXidByNzHOAdNqX36wc%3Dreserved=0

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Fixed time of generic ts2phc master

[Geva, Erez]

Hi,

I think we should put a comment there.
It does looks buzzard to see ' ts->tv_nsec = ntx.time.tv_usec'.
Though this is how 'ADJ_NANO' works 

Erez

-Original Message-
From: Miroslav Lichvar  
Sent: Monday, 26 September 2022 10:57
To: j.raczynski 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Fixed time of generic ts2phc master

On Mon, Sep 26, 2022 at 09:53:34AM +0200, j.raczynski wrote:
> Fixed incorrect conversion of units from [us] to [ns] when polling PPS 
> time from generic master in ts2phc program.

> --- a/ts2phc_generic_pps_source.c
> +++ b/ts2phc_generic_pps_source.c
> @@ -42,7 +42,7 @@ static int ts2phc_generic_pps_source_getppstime(struct 
> ts2phc_pps_source *src,
>   return -1;
>   }
>   ts->tv_sec  = ntx.time.tv_sec + ntx.tai;
> - ts->tv_nsec = ntx.time.tv_usec;
> + ts->tv_nsec = ntx.time.tv_usec * 1000;

There is ADJ_NANO passed to the adjtimex call few lines above this, so it 
should be in nanoseconds, even though it says tv_usec.

Did you see a bug, or was this just a review?

--
Miroslav Lichvar



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7C8613f4fd91564ec8914908da9f9d4e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637997795218339465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5yiVNbmFsS555g6rs4q1KmRfQI5yNq3XhoeAjWCl2Lc%3Dreserved=0

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/4] [Interface Rate TLV] function to support get interface speed via ethtool

[Geva, Erez]

Looking in the kernel code.

The link mode mask are mandatory for the get_link_ksettings() call-back, the 
driver is require to fill them.

The size is fixed to __ETHTOOL_LINK_MODE_MASK_NU32.

>From kernel net/ethtool/ioctl.c: 
>https://elixir.bootlin.com/linux/latest/source/net/ethtool/ioctl.c#L536

if (__ETHTOOL_LINK_MODE_MASK_NU32 != link_ksettings.base.link_mode_masks_nwords)
link_ksettings.base.link_mode_masks_nwords = 
-((s8)__ETHTOOL_LINK_MODE_MASK_NU32);
return  0;  // without information

link_ksettings.base.link_mode_masks_nwords = __ETHTOOL_LINK_MODE_MASK_NU32);
Call driver get_link_ksettings() and fill the link setting + link mode arrays.
Return 0;

As  __ETHTOOL_LINK_MODE_MASK_NU32 = 
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
And __ETHTOOL_LINK_MODE_MASK_ NBITS is defined in ethtool.h

We can start
ecmd.req.link_mode_masks_nwords = ceil(__ETHTOOL_LINK_MODE_MASK_NU32/32)

And check if the first return ecmd.req.link_mode_masks_nwords is negative, than 
we need a second call.
But if ecmd.req.link_mode_masks_nwords is positive. Than we should have the 
proper speed: ecmd.req.speed.

Please add a remark that the link_mode_data array contain 3 arrays: 
supported[], advertising[], lp_advertising[]

Another, good to know, the speed can be find in the sysfs:
/sys/class/net//speed
Though, the sysfs is not mandatory, and could be mount in a different mount 
point.

Erez


From: Devasish Dey 
Sent: Tuesday, 26 July 2022 18:38
To: Erez 
Cc: Leon Goldin ; 
linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 1/4] [Interface Rate TLV] function to 
support get interface speed via ethtool

Hi Erez,


> I am confused.
> Why do you ask for the link_mode_data, if you do not use it?
> Wouldn't the ethtool_link_settings contain all the information we need here?

Unfortunately, the ioctl call returns speed as 0 with ethtool_link_settings. So 
we had to use ecmd.

Thanks,
Devasish Dey
SyncMonk Technologies,
www.syncmonk.net

On Tue, 26 Jul 2022 at 18:38, Erez 
mailto:erezge...@gmail.com>> wrote:


On Tue, 26 Jul 2022 at 14:27, SyncMonk Technologies 
mailto:servi...@syncmonk.net>> wrote:
When master and slave instance interacting with each other operating
at different interface speed, delay assymetry needs to be compensated
as described in G.8271 appendix V.

In this patch we are adding changes to get the interface speed using
ethtool.

Signed-off-by: Greg Armstrong 
mailto:greg.armstrong...@renesas.com>>
Signed-off-by: Leon Goldin 
mailto:leon.goldin...@renesas.com>>
Signed-off-by: Devasish Dey 
mailto:devasish@syncmonk.net>>
Signed-off-by: Vipin Sharma 
mailto:vipin.sha...@syncmonk.net>>
---
 sk.c | 65 
 sk.h | 18 +
 2 files changed, 83 insertions(+)

diff --git a/sk.c b/sk.c
index 80075be..7df14db 100644
--- a/sk.c
+++ b/sk.c
@@ -205,6 +205,71 @@ failed:
return -1;
 }

+int sk_get_if_info(const char *name, struct sk_if_info *if_info)
+{
+#ifdef ETHTOOL_GLINKSETTINGS
+   struct ifreq ifr;
+   int fd, err;
+
+   struct {
+   struct ethtool_link_settings req;
+   __u32 link_mode_data[3 * 127];

Although __ETHTOOL_LINK_MODE_MASK_NBITS = 92.
I understand you roundup to 0x7f, for future use.

Please add a proper remark about `link_mode_data` size.
Say it consists of supported[], advertising[], lp_advertising[] with size up to 
127 ech.
The actual size is provided by the kernel.


+   } ecmd;
+
+   memset(, 0, sizeof(ifr));
+   memset(, 0, sizeof(ecmd));

Though sk_get_ts_info() uses the same order.
The memset can be after calling socket, in case of error.

+
+   fd = socket(AF_INET, SOCK_DGRAM, 0);
+   if (fd < 0) {
+   goto failed;
+   }
+
+   ecmd.req.cmd = ETHTOOL_GLINKSETTINGS;
+
+   strncpy(ifr.ifr_name, name, IFNAMSIZ - 1);
+   ifr.ifr_data = (char *) 
+
+   /* Handshake with kernel to determine number of words for link
+* mode bitmaps. When requested number of bitmap words is not
+* the one expected by kernel, the latter returns the integer
+* opposite of what it is expecting. We request length 0 below
+* (aka. invalid bitmap length) to get this info.
+*/
+   err = ioctl(fd, SIOCETHTOOL, );
+   if (err < 0) {
+   pr_err("ioctl SIOCETHTOOL failed: %m");
+   close(fd);
+   goto failed;
+   }
+
+   if (ecmd.req.link_mode_masks_nwords >= 0 ||
+   ecmd.req.cmd != ETHTOOL_GLINKSETTINGS) {
+   

Re: [Linuxptp-devel] [PATCH] sk.c: Unreachable switch case TS_SOFTWARE

[Geva, Erez]

Hi,

I think the "if (type != TS_SOFTWARE" is wrong.
The "type" only refer to TX.
But hwts_init() also set the RX.
So no reason to skip it.
Setting to TS_SOFTWARE means no TX hardware time stamp.

I wonder how we miss it?
Probably in refactoring of the code.
Or is it is a quick work-around?

Erez

-Original Message-
From: Siddharth Vadapalli via Linuxptp-devel 
 
Sent: Thursday, 21 July 2022 11:41
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] sk.c: Unreachable switch case TS_SOFTWARE

Remove the unreachable switch case TS_SOFTWARE.

Signed-off-by: Siddharth Vadapalli 
---
 sk.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sk.c b/sk.c
index b55d6b5..a49bcf4 100644
--- a/sk.c
+++ b/sk.c
@@ -477,9 +477,6 @@ int sk_timestamping_init(int fd, const char *device, enum 
timestamp_type type,
if (type != TS_SOFTWARE) {
filter1 = HWTSTAMP_FILTER_PTP_V2_EVENT;
switch (type) {
-   case TS_SOFTWARE:
-   tx_type = HWTSTAMP_TX_OFF;
-   break;
case TS_HARDWARE:
case TS_LEGACY_HW:
tx_type = HWTSTAMP_TX_ON;
-- 
2.37.1



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7Cd073e44825024b89f07a08da6aff5b2c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637939942226521495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=w%2FXpp9A%2BWyUdvaAjtzqqLLc7kvmX69bvsky9bteKQcg%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Power profile support in ptp4l

[Geva, Erez]

You can find it in the archive

https://sourceforge.net/p/linuxptp/mailman/linuxptp-devel/

See:
[PATCH RFC v3 00/10] Profile support for IEEE C37.238-2011 and IEEE C37.238-2017
10 patches
https://sourceforge.net/p/linuxptp/mailman/linuxptp-devel/?viewmonth=202111=9

Erez


From: Vijay Khurdiya 
Sent: Friday, 15 April 2022 17:04
To: Richard Cochran 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Power profile support in ptp4l

Thanks for the update.
Could you please send a patch.Please let me know a tentative plan for releasing 
4.0. I would like to test & give feedback.

Thanks

On Fri, Apr 8, 2022 at 10:11 PM Richard Cochran 
mailto:richardcoch...@gmail.com>> wrote:
On Fri, Apr 08, 2022 at 05:46:16PM +0530, Vijay Khurdiya wrote:
> Hi,
>
> I would like to know any ptp4l version support for Power Profile or any
> work available to check for power profile.

I posted a patch set earlier.

There was some review/feedback that I will address, post again, and
soon it will be merged.

Also, I'm planning release 4.0 which will include power profile.

Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add non-portable management option to query the servo state (via SERVO_STATE_NP).

[Geva, Erez]

Your Python skills exceeds mine 

https://github.com/erezgeva/libpmc/blob/master/sample/sync_watch.py
https://sourceforge.net/p/libpmc/code/ci/master/tree/sample/sync_watch.py

I see you calculate "PtpSyncQuality".
A way users can determine whether the PTP state is stable.
Excellent!

Thanks for sharing
Erez

-Original Message-
From: Martin Pecka  
Sent: Monday, 28 March 2022 23:11
To: Richard Cochran ; Geva, Erez (ext) (DI PA DCP R 
3) 
Cc: Miroslav Lichvar ; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Add non-portable management option to 
query the servo state (via SERVO_STATE_NP).

Here is my bit regarding the sync estimator using libpmc written in 
Python: https://github.com/erezgeva/libpmc/pull/4 .



smime.p7s
Description: S/MIME cryptographic signature
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add non-portable management option to query the servo state (via SERVO_STATE_NP).

[Geva, Erez]

Hi,

What do you think of:
https://sourceforge.net/p/libpmc/code/ci/master/tree/sample/sync.pl
https://github.com/erezgeva/libpmc/blob/master/sample/sync.pl

I wrote it in Perl, but can easily translate to C++ or other scripts languages.

Erez


-Original Message-
From: Richard Cochran  
Sent: Thursday, 17 March 2022 21:48
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: Miroslav Lichvar ; Martin Pecka 
; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Add non-portable management option to 
query the servo state (via SERVO_STATE_NP).

On Thu, Mar 17, 2022 at 10:16:03AM +, Geva, Erez wrote:
> There is no generic sync.
> 
> So each user need to define a 'sync' that match to its system needs.

A user-defined sync service could be based off of your pmc lib.
Maybe that would be the place to have one or two examples?

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/1] Fix management TLV print.

[Geva, Erez]

I know,

Yet the actualTableSize variable exist in 4 standard TABLE TLVs, although we do 
not support them yet.
I guess that is why Alexander Bulimov pick that name.
If I would name the variable, I would probably pick some thing different like 
"number of records",
 as size might be misleading. Size could also means total size in octets for 
example.

As for the structure name been different.
In print the name 'clockQuality'  follow the IEEE standard style.
Yet the variable 'clock_quality'  follow Linux coding style.
So, I do not suggest something different from what Alexander Bulimov did by 
himself.

I do not see any connection between the variable name, which should follow the 
Linux coding style,
 and the print name that should follow the IEEE standard.

Alexander also forget to add UNICAST_MASTER_TABLE_NP to pmc_tlv_datalen().
Not blame him in anyway. But unimportant staff like that does tend to slip. 

Personally, I would also use UInteger16 for type, but I am not that picky as 
for internal.
But as for external representation, I would prefer to be more compliant with 
IEEE standard.
Not because IEEE standard is better, just because it is the standard we try to 
keep.

I think it may by a good practice to use the same 'actualTableSize' for all 
future tables, for consistency.

Anyway, if you wish me to update the patch and send a second version, I would 
gladly do.

Thanks
   Erez

-Original Message-
From: Richard Cochran  
Sent: Tuesday, 22 March 2022 19:54
To: Erez 
Cc: Geva, Erez (ext) (DI PA DCP R 3) ; 
linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 1/1] Fix management TLV print.

On Tue, Mar 22, 2022 at 12:54:55PM +0100, Erez wrote:
> As actualTableSize name comes from the IEEE standard.

UNICAST_MASTER_TABLE_NP is a custom creation, not in the standard at all.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add non-portable management option to query the servo state (via SERVO_STATE_NP).

[Geva, Erez]

I think Richard is correct.

The sync state depends on your system.
On my setting a 'sync' is when the correction is bellow 100 nanoseconds, when 
it is usually bellow 10 nanoseconds and I except to have it stable for 5 
seconds long.

There is no generic sync.

So each user need to define a 'sync' that match to its system needs.

Erez


-Original Message-
From: Miroslav Lichvar  
Sent: Thursday, 17 March 2022 08:52
To: Martin Pecka 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Add non-portable management option to 
query the servo state (via SERVO_STATE_NP).

On Wed, Mar 16, 2022 at 11:55:27PM +0100, Martin Pecka wrote:
> > People naively want a simple Boolean flag.  However, the reality is 
> > that there is no simple answer to the question, is my computer 
> > synchronized.
> Well, that is actually what people expect from a time sync daemon. 
> Chrony has it (* or + in `chronyc sources`),

* or + only tells you whether a time source is selected for synchronization, 
nothing about the clock actually being synchronized, no matter what definition 
you have for that. It's a common misconception. In PTP that would be a port 
being in the slave state.

On systemd-based distributions there is a "time-sync" target, after which can 
be ordered start of services that require "synchronized"
clock. With the chrony-wait service, the time-sync target is reached when the 
reported remaining correction of the clock is less than 100 milliseconds.

With ptp4l or phc2sys, you would just wait for the first non-zero offset 
smaller than some value (e.g. 1000 nanoseconds).

> systemd has it ("System clock synchronized: yes" in timedatectl)

'yes' is reported by timedatectl when the maxerror value of the system clock 
(from adjtimex() or ntp_gettime()) is smaller than 16 seconds.
That normally happens on the first update of the clock. timedated/ctl doesn't 
know what is actually controlling the clock. This works even with ptp4l (if SW 
timestamping) and phc2sys.

--
Miroslav Lichvar



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Cb56d74cf8ed34f330f8208da07eba198%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637831005855295321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BzjBaUTSdCiE%2BrRyKIjAfNuID%2Be8GTZcFtvtXiwDVzk%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add UNICAST_MASTER_TABLE_NP management TLV

[Geva, Erez]

Hi,

The standard define:
UNICAST_MASTER_TABLE
ACCEPTABLE_MASTER_TABLE
And some more tables.

Why do we need a new private management TLV and not use the standard TLVs?

Not against adding new management TLV, if we have good reason for.
Nor do I think the standard is better.
But it seems we skip adding the standard ones and jump directly to private 
management TLV.
I think it is better to start with the standard TLVs and add the private for 
missing or important information.

Erez

-Original Message-
From: Alexander Bulimov via Linuxptp-devel 
 
Sent: Tuesday, 15 February 2022 19:56
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] Add UNICAST_MASTER_TABLE_NP management TLV

This change adds new UNICAST_MASTER_TABLE_NP management TLV that exposes table 
with details of each gm: identity, IP address, state, if it's selected as best 
master, and information from the latest Announce msg that is used in BMCA 
algorithm:
ClockQuality and Priorities.

The inspiration was `chronyc sources` command that provides great insights into 
the state of NTP client. Here we tried to provide something similar, but for 
unicast PTP client.

Justification: we operate unicast PTPv2 in datacenters, and each client has 
multiple unicast GMs set up in the config.

First, it quickly became clear that we need a way to map the GM identity from 
PARENT_DATA_SET or TIME_STATUS_NP TLVs to the actual IP.

Next we realized the need to be able to inspect the full unicast master table 
along with GM states and preferably Announce information, to quickly debug 
potential issues and better understand why the particular GM was selected as 
best master.

The 1588-2019 standard doesn't provide any real means to inspect the active 
unicast master table. UNICAST_MASTER_TABLE TLV is pretty useless as described 
in the standard, and with linuxptp it can be effectively replaced by `cat 
/etc/ptp4l.conf`.

Here is the example output that hopefully shows the usefullness of new TLV: we 
can instantly see that ptp4l coudn't even talk to some of the GMs.

  ./pmc -u -b 0  'GET UNICAST_MASTER_TABLE_NP'
  sending: GET UNICAST_MASTER_TABLE_NP
  4857dd.fffe.0e91da-1 seq 0 RESPONSE MANAGEMENT 
MID_UNICAST_MASTER_TABLE_NP
  actualTableSize 9
  BM  identity address  
  state clockClass clockQuality offsetScaledLogVariance p1  p2
  no  b8cef6.fffe.7349d4-1 2401:db00:2515:f001:face:0:2a3:0 
  HAVE_ANN  6  0x21 0x59e0  128 128
  yes b8cef6.fffe.0210e4-1 2401:db00:2515:f001:face:0:3d1:0 
  HAVE_SYDY 6  0x21 0x59e0  128 128
  no  b8cef6.fffe.057e20-1 2401:db00:2515:f001:face:0:3fa:0 
  HAVE_ANN  6  0x21 0x59e0  128 128
  no  b8cef6.fffe.7349dc-1 2401:db00:2515:f001:face:0:da:0  
  HAVE_ANN  6  0x21 0x59e0  128 128
  no  ff..ff-65535 2401:db00:2515:f002:face:0:11b:0 
  WAIT  0  0x00 0x  0   0
  no  b8cef6.fffe.7349c4-1 2401:db00:2515:f002:face:0:1ec:0 
  HAVE_ANN  6  0x21 0x59e0  128 128
  no  ff..ff-65535 2401:db00:2515:f002:face:0:94:0  
  WAIT  0  0x00 0x  0   0
  no  ff..ff-65535 192.168.0.1  
  WAIT  0  0x00 0x  0   0
  no  b8cef6.fffe.7349c8-1 2401:db00:2515:f002:face:0:b7:0  
  HAVE_ANN  6  0x21 0x59e0  128 128

I realize that this is can be controversial (for one, no other PMC command 
provides table-like output), so I'm happy to hear your suggestion.

Signed-off-by: Alexander Bulimov 
---
 ddt.h| 10 +
 pmc.c| 40 ++
 pmc_common.c |  1 +
 port.c   | 61 ++--
 tlv.c| 52 
 tlv.h|  6 ++
 util.c   | 16 ++
 util.h   |  3 +++
 8 files changed, 182 insertions(+), 7 deletions(-)

diff --git a/ddt.h b/ddt.h
index ef30f73..7a95344 100644
--- a/ddt.h
+++ b/ddt.h
@@ -120,4 +120,14 @@ struct PortServiceStats {
uint64_t followup_mismatch;
 };
 
+struct UnicastMasterEntry {
+   uint8_t selected;
+   Enumeration8portState;
+   struct PortIdentity portIdentity;
+   struct ClockQuality clockQuality;
+   UInteger8   priority1;
+   UInteger8   priority2;
+   struct PortAddress  address;
+} PACKED;
+
 #endif
diff --git a/pmc.c b/pmc.c
index 2e5e93e..577e479 100644
--- a/pmc.c
+++ b/pmc.c
@@ -88,6 +88,24 @@ static void pmc_show_rx_sync_timing(struct 

Re: [Linuxptp-devel] [PATCH] Add PORT_SERVICE_STATS_NP management TLV

[Geva, Erez]

You can add a management set/command operation of the PORT_SERVICE_STATS_NP 
management TLV.

Erez


-Original Message-
From: Dale Smith  
Sent: Tuesday, 25 January 2022 23:05
To: Alexander Bulimov 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Add PORT_SERVICE_STATS_NP management TLV

On 1/25/22, Alexander Bulimov via Linuxptp-devel 
 >

+struct PortServiceStats {
> + uint64_t announce_timeout;
> + uint64_t sync_timeout;
> + uint64_t delay_timeout;
> + uint64_t unicast_service_timeout;
> + uint64_t unicast_request_timeout;
> + uint64_t master_announce_timeout;
> + uint64_t master_sync_timeout;
> + uint64_t qualification_timeout;
> + uint64_t sync_mismatch;
> + uint64_t followup_mismatch;
> +};

> --- a/port_private.h
> +++ b/port_private.h
> @@ -146,6 +146,7 @@ struct port {
>   UInteger8   delay_response_counter;
>   UInteger8   delay_response_timeout;
>   struct PortStatsstats;
> + struct PortServiceStatsservice_stats;
>   /* foreignMasterDS */
>   LIST_HEAD(fm, foreign_clock) foreign_masters;
>   /* TC book keeping */

I don't see a way to reset/clear these counters.  Should there be?  It will 
take a while to overflow 64 bits, so it probably isn't needed?

Just kind of curious.

-Dale


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C1a60b8fdad1848e29abd08d9e04ecb53%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637787451294474760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=tJ3Rxk2FQCnQE71d6p4a3ImO0WInnw16ItRxOYNFPqQ%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/7] Support for virtual clocks

[Geva, Erez]

Hi,

When we would use multiple PHC per interface (or per bridge/switch).
How can we defer a real PHC from virtual PHC?
Would not it be easier to simply call then multiple PHC and use the index 
regardless if it is virtual or not.

As for the PORT_PROPERTIES_NP. It is a port TLV not a clock TLV. 
I think it is better to add a new TLV and not break backward compatible of 
PORT_PROPERTIES_NP.
A patch like that was rejected 2 month ago.

Erez


-Original Message-
From: Miroslav Lichvar  
Sent: Thursday, 13 January 2022 16:55
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH RFC 0/7] Support for virtual clocks

With recent kernels it is possible to create virtual PHCs running on top of a 
free-running PHC by writing to /sys/class/ptp/ptp?/n_vclocks. If supported in 
linuxptp, it would allow users to run multiple ptp4l instance with hardware 
timestamping on one interface, e.g. in different domains for better resiliency, 
or separate instances for different unicast servers.

The kernel support was added in 5.14, but there were some bugs fixed recently, 
so 5.17-rc1 or later is recommended for testing.

The 1st patch is a bug fix required by the second patch.
The 2nd patch adds detection of virtual clocks via ethtool netlink.

The 3rd-5th patch add support to ptp4l. The PHC index of the virtual clock 
needs to be specified in the configuration.

The 6th and 7th patch add support to phc2sys. The PORT_PROPERTIES_NP message is 
extended with the PHC index. The command is available only on the UDS port, but 
I'm not sure if an incompatible change like this is acceptable. The alternative 
would be to add a new command specifically for the index.

My plan is to add support also to timemaster to detect the kernel support, 
automatically create virtual clocks for interfaces specified in multiple 
domains (where previously some instances had to use SW timestamping), and pass 
the correct PHC indexes to the ptp4l instances. 


Miroslav Lichvar (7):
  rtnl: Fix rtnl_rtattr_parse() to process max attribute.
  rtnl: Add function to detect virtual clocks.
  Add support for binding sockets to virtual clocks.
  config: Add port-specific phc_index option.
  port: Check for virtual clocks.
  tlv: Add PHC index to PORT_PROPERTIES_NP.
  phc2sys: Use PHC index from PORT_PROPERTIES_NP.

 clock.c |  6 +++-
 config.c|  1 +
 incdefs.sh  |  4 +++
 interface.c | 12 
 interface.h | 14 +
 missing.h   | 11 +++
 phc2sys.c   | 42 +++---
 pmc_agent.c |  3 +-
 pmc_agent.h |  4 ++-
 port.c  | 16 +++---
 ptp4l.8 |  8 +
 raw.c   |  3 +-
 rtnl.c  | 87 +++--
 rtnl.h  |  9 ++
 sk.c| 11 +--
 sk.h|  3 +-
 tlv.c   |  2 ++
 tlv.h   |  1 +
 udp.c   |  3 +-
 udp6.c  |  3 +-
 20 files changed, 211 insertions(+), 32 deletions(-)

--
2.33.1



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Ccf6f6ea49816434c66dd08d9d6ade80f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637776864684717246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=yt2%2FX%2BRyNF2oiO80Jxy8cGQ%2Fezs3AVpMmFQUWmSEuB4%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] linuxptp performance hit

[Geva, Erez]

Hi,

I like your patch.
You follow PRINT_RL, good thinking.

I want to recommend:

  1.  You need to commit the changes locally. You need to sign the patches.
And create patches for send with “git format-patch  
--cover-letter”.
You need to fill the cover letter “patch” manually.
The cover letter “patch” is a general message and a summery of the patch series.
A single patch need a cover letter “patch” too.
On a second version or higher use the version ‘-v’ flag, i.e.  “git 
format-patch  -v2 --cover-letter”.
You can use the ‘-o’ output flag to place the patches in a different folder.
  2.  The patches, including the cover letter “patch” need to pass the Linux 
kernel scripts/checkpatch.pl.
  3.  You need to send the patch series with the cover letter using “git 
send-email”.

Regarding the patch itself.
Why not using a global for level, so we can skip the function call?
I would use an inline function in the print header for better reading.
Simply move print_get_level()to header and make it inline and make print_level 
a global.

The rate_limited function call a syscall function, clock_gettime().
So making the function inline would not help much.

Anyhow, the pl_xxx are rarely used, while pr_xxx is everywhere.
linuxptp (master)$ grep '\
Sent: Friday, 17 December 2021 15:27
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] linuxptp performance hit

My apologies, I didn't submit a clean patch.
Probably this submission will clear it.
Thanks.

diff --git a/print.h b/print.h
index 1723d8a..7e765da 100644
--- a/print.h
+++ b/print.h
@@ -38,14 +38,32 @@ void print_set_syslog(int value);
 void print_set_level(int level);
 void print_set_verbose(int value);

-#define pr_emerg(x...)   print(LOG_EMERG, x)
-#define pr_alert(x...)   print(LOG_ALERT, x)
-#define pr_crit(x...)print(LOG_CRIT, x)
-#define pr_err(x...) print(LOG_ERR, x)
-#define pr_warning(x...) print(LOG_WARNING, x)
-#define pr_notice(x...)  print(LOG_NOTICE, x)
-#define pr_info(x...)print(LOG_INFO, x)
-#define pr_debug(x...)   print(LOG_DEBUG, x)
+  /*
+   * Better check print log level before execution of print itself.
+   * Otherwise all arguments are evaluated and slow down the system.
+   * e.g.   in 'unicast_service.c' unicast_service_clients()
+   *pid2str() is the killer
+   *   pr_debug("%s wants 0x%x", pid2str(>portIdentity),
+   *client->message_types);
+   */
+
+  extern
+  int print_get_level( void);
+
+  #define PRINT_CL(l, x...) /* PRINT Check Level */\
+   do {\
+   if ( print_get_level() >= l)\
+   print(l, x);\
+   } while (0)
+
+  #define pr_emerg(x...)   PRINT_CL(LOG_EMERG, x)
+  #define pr_alert(x...)   PRINT_CL(LOG_ALERT, x)
+  #define pr_crit(x...)PRINT_CL(LOG_CRIT, x)
+  #define pr_err(x...) PRINT_CL(LOG_ERR, x)
+  #define pr_warning(x...) PRINT_CL(LOG_WARNING, x)
+  #define pr_notice(x...)  PRINT_CL(LOG_NOTICE, x)
+  #define pr_info(x...)PRINT_CL(LOG_INFO, x)
+  #define pr_debug(x...)   PRINT_CL(LOG_DEBUG, x)

 #define PRINT_RL(l, i, x...) \
do { \

diff --git a/print.c b/print.c
index c428895..bf70aca 100644
--- a/print.c
+++ b/print.c
@@ -50,6 +50,11 @@ void print_set_level(int level)
print_level = level;
 }

+int print_get_level( void)
+{
+   return print_level;
+}
+
 void print_set_verbose(int value)
 {
verbose = value ? 1 : 0;


Kosta
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Inconsistent remote timestamps in the P2P mode

[Geva, Erez]

Is the new IEEE Std 1588-2019 have any updates on that?



-Original Message-
From: Methlal Pallewatta  
Sent: Friday, 19 November 2021 12:17
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] Inconsistent remote timestamps in the P2P mode

Hi all,

In the section 6.6.4 (page 35) of the IEEE Std 1588-2008 the following is 
stated about the port 2 in the P2P mode.

Port-2 either:
1. returns the difference between the timestamps t2 and t3 in the Pdelay_Resp 
message 2. returns the difference between the timestamps t2 and t3 in a 
Pdelay_Resp_Follow_Up message 3. returns the timestamps t2 and t3 in the 
Pdelay_Resp and Pdelay_Resp_Follow_Up messages, respectively

I found that the IXIA master that I used was using option 2 and was not sending 
the actual timestamp t2 but sending out 0 instead. At the same time the Syncs 
were the actual timestamp as the originTimestamp. This makes it impossible to 
use the two remote timestamp values together to compute the delay using 
get_raw_delay() in tsproc_update_offset(). To workaround this I am using the 
following patch. (BTW, t2 corresponds to
t4 in the tsproc structure). Instead of calling get_raw_delay() I am using the 
previous value of it. There could be better solutions for this but this is for 
the review of my initial solution.

Thanks,

Methlal

diff --git a/tsproc.c b/tsproc.c
index a871049..8f0376a 100644
--- a/tsproc.c
+++ b/tsproc.c
@@ -43,6 +43,9 @@ struct tsproc {
     tmv_t filtered_delay;
     int filtered_delay_valid;

+   /* Last raw delay */
+   tmv_t last_raw_delay;
+
     /* Delay filter */
     struct filter *delay_filter;
  };
@@ -155,6 +158,7 @@ int tsproc_update_delay(struct tsproc *tsp, tmv_t 
*delay)
     raw_delay = get_raw_delay(tsp);
     tsp->filtered_delay = filter_sample(tsp->delay_filter, raw_delay);
     tsp->filtered_delay_valid = 1;
+   tsp->last_raw_delay = raw_delay;

     pr_debug("delay   filtered %10" PRId64 "   raw %10" PRId64,
  tmv_to_nanoseconds(tsp->filtered_delay),
@@ -197,14 +201,22 @@ int tsproc_update_offset(struct tsproc *tsp, tmv_t 
*offset, double *weight)
     if (tmv_is_zero(tsp->t3)) {
     return -1;
     }
-   raw_delay = get_raw_delay(tsp);
+   if (tmv_is_zero(tsp->t4)) { /* Special p2p case */
+   raw_delay = tsp->last_raw_delay;
+   } else {
+   raw_delay = get_raw_delay(tsp);
+   }
     delay = raw_delay;
     break;
     case TSPROC_FILTER_WEIGHT:
     if (tmv_is_zero(tsp->t3) || !tsp->filtered_delay_valid) {
     return -1;
     }
-   raw_delay = get_raw_delay(tsp);
+   if (tmv_is_zero(tsp->t4)) { /* Special p2p case */
+   raw_delay = tsp->last_raw_delay;
+   } else {
+   raw_delay = get_raw_delay(tsp);
+   }
     delay = tsp->filtered_delay;
     break;
     }
@@ -233,6 +245,7 @@ void tsproc_reset(struct tsproc *tsp, int full)
     tsp->t2 = tmv_zero();
     tsp->t3 = tmv_zero();
     tsp->t4 = tmv_zero();
+   tsp->last_raw_delay = tmv_zero();

     if (full) {
     tsp->clock_rate_ratio = 1.0;



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C4bafb02e20484f4a60db08d9ab511167%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637729187197167401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vmM%2FduipXZ8p2CEUCCE06rIUKVc%2B38dl37XO1yxzvu8%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] util: don't error out in posix_clock_open() if we can't determine PHC index

[Geva, Erez]

Do you mean?
https://pubs.opengroup.org/onlinepubs/009696799/functions/realpath.html
https://man7.org/linux/man-pages/man3/realpath.3p.html
https://man7.org/linux/man-pages/man3/realpath.3.html

-Original Message-
From: Richard Cochran  
Sent: Wednesday, 17 November 2021 05:23
To: Keller, Jacob E 
Cc: linuxptp-devel@lists.sourceforge.net; Ed Branch 
Subject: Re: [Linuxptp-devel] [PATCH] util: don't error out in 
posix_clock_open() if we can't determine PHC index

On Tue, Nov 16, 2021 at 10:09:59PM +, Keller, Jacob E wrote:
> Is it possible for us to resolve symlinks ourselves before attempting to 
> check its index value? That would be an added convenience for users.

Hm, is there a unix/stdlib C API for realpath?

If so, then yes.

(I haven't heard of such an API.)

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C43612f87a8f44034b17508d9a9824e9c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637727199964074616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ml3ts%2BuweHdldzu2MPKUNRiAOsyGjC1tTMYorx3rIz8%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait for a local or remote clock to synchronize

[Geva, Erez]

Sorry the script is part of propriety application of Siemens.

Users can use the test scripts in the http://libpmc.sf.net/ 

They can easily adopt it into their application in C, C++, python, Lua, Perl, 
ruby and TCL.
C simply need a "wrapper" to C++.

What I do in my script is very simple.
I send 3 GETs for PORT_DATA_SET, PARENT_DATA_SET, CURRENT_DATA_SET.
When receiving the reply in my main "poll", I process them and 
 get the portState, peerMeanPathDelay from PORT_DATA_SET, gmIdentity from 
PARENT_DATA_SET and master_offset from CURRENT_DATA_SET.
I then decide if port is synchronise or not based on these values.

Erez

-Original Message-
From: Richard Cochran  
Sent: Monday, 15 November 2021 14:43
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: Vladimir Oltean ; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait 
for a local or remote clock to synchronize

On Fri, Oct 15, 2021 at 10:48:28PM +, Geva, Erez wrote:

> Although, I am not oppose your patch. I just find it useless, as I perform 
> the same result in a Perl script.
> And with a much higher flexibility and a better performance.

Can you share the equivalent script?

It would be interesting to compare the two...

Thanks,
Richard



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the ALTERNATE_TIME_OFFSET_PROPERTIES management message.

[Geva, Erez]

I notice that 32 bits are 136 years.

But as IEEE defined it as 48 bits. 
And we try to make the ptp4l compliance with IEEE.

In the same manner that we add zero pad to management GET message, since IEEE 
recommends.

I think, we need to support 48 bits in ptp4l and display the proper value in 
PMC.

I do agree that setting the value by PMC is not necessary.
And I doubt if any one really need these extra 16 bits.

As I am sure no one really needs the GET message data filled with zeros.

Erez

-Original Message-
From: Richard Cochran  
Sent: Wednesday, 10 November 2021 15:52
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the 
ALTERNATE_TIME_OFFSET_PROPERTIES management message.

On Wed, Nov 10, 2021 at 08:57:35AM +, Geva, Erez wrote:
> Hi,
> 
> According to IEEE 1588 timeOfNextJump is 48 bits.
> The alternate_time_offset_properties structure reserve the full 48 bits.
> The pre and the post function do full handle.
> But the rest handle only the low 32 bits.
> 
> I can understand the PMC set use 32 bits only, but the rest?

The resolution of timeOfNextJump is one second.  Twenty five bits of seconds is 
more then enough for a time zone change one year out.

32 bits allows time zone change 136 years in the future.

Do we really need the high order bytes of the 48 bit field?

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the ALTERNATE_TIME_OFFSET_PROPERTIES management message.

[Geva, Erez]

Hi,

According to IEEE 1588 timeOfNextJump is 48 bits.
The alternate_time_offset_properties structure reserve the full 48 bits.
The pre and the post function do full handle.
But the rest handle only the low 32 bits.

I can understand the PMC set use 32 bits only, but the rest?

Erez

-Original Message-
From: Richard Cochran  
Sent: Tuesday, 9 November 2021 21:12
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the 
ALTERNATE_TIME_OFFSET_PROPERTIES management message.

Signed-off-by: Richard Cochran 
---
 clock.c  | 66 
 pmc.c| 13 +++
 pmc_common.c | 24 ++-
 tlv.c| 21 +
 util.h   |  7 ++
 5 files changed, 126 insertions(+), 5 deletions(-)

diff --git a/clock.c b/clock.c
index b5b729a..1e3ff3e 100644
--- a/clock.c
+++ b/clock.c
@@ -156,6 +156,32 @@ static int clock_resize_pollfd(struct clock *c, int 
new_nports);  static void clock_remove_port(struct clock *c, struct port *p);  
static void clock_stats_display(struct clock_stats *s);
 
+uint8_t clock_alttime_offset_get_key(struct ptp_message *req) {
+   struct management_tlv_datum *mtd;
+   struct management_tlv *mgt =
+   (struct management_tlv *) req->management.suffix;
+
+   /*
+* The data field of incoming management request messages is
+* normally ignored.  Indeed it can even be empty.  However
+* the ALTERNATE_TIME_OFFSET requests are exceptional because
+* the key field selects one of the configured time zones.
+*
+* Provide the first time zone for an empty GET, and validate
+* the length of the request when non-empty.
+*/
+   if (mgt->length == sizeof(mgt->id)) {
+   return 0;
+   }
+   if (mgt->length < sizeof(mgt->id) + sizeof(*mtd)) {
+   return MAX_TIME_ZONES;
+   }
+   mtd = (struct management_tlv_datum *) mgt->data;
+
+   return mtd->val;
+}
+
 static void remove_subscriber(struct clock_subscriber *s)  {
LIST_REMOVE(s, list);
@@ -353,6 +379,7 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
  struct ptp_message *req,
  struct ptp_message *rsp, int id)  {
+   struct alternate_time_offset_properties *atop;
struct grandmaster_settings_np *gsn;
struct management_tlv_datum *mtd;
struct subscribe_events_np *sen;
@@ -362,6 +389,7 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
struct PTPText *text;
uint16_t duration;
int datalen = 0;
+   uint8_t key;
 
extra = tlv_extra_alloc();
if (!extra) {
@@ -432,6 +460,22 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
mtd->val = c->tds.flags & PTP_TIMESCALE;
datalen = sizeof(*mtd);
break;
+   case MID_ALTERNATE_TIME_OFFSET_PROPERTIES:
+   key = clock_alttime_offset_get_key(req);
+   if (key >= MAX_TIME_ZONES) {
+   break;
+   }
+   atop = (struct alternate_time_offset_properties *) tlv->data;
+   atop->keyField = key;
+   /* Message alignment broken by design. */
+   memcpy(>currentOffset, >tz[key].current_offset,
+  sizeof(atop->currentOffset));
+   memcpy(>jumpSeconds, >tz[key].jump_seconds,
+  sizeof(atop->jumpSeconds));
+   memcpy(>timeOfNextJump.seconds_lsb, >tz[key].next_jump,
+  sizeof(atop->timeOfNextJump.seconds_lsb));
+   datalen = sizeof(*atop);
+   break;
case MID_TIME_STATUS_NP:
tsn = (struct time_status_np *) tlv->data;
tsn->master_offset = tmv_to_nanoseconds(c->master_offset);
@@ -510,11 +554,12 @@ static int clock_management_get_response(struct clock *c, 
struct port *p,  static int clock_management_set(struct clock *c, struct port 
*p,
int id, struct ptp_message *req, int *changed)  
{
-   int respond = 0;
-   struct management_tlv *tlv;
-   struct management_tlv_datum *mtd;
+   struct alternate_time_offset_properties *atop;
struct grandmaster_settings_np *gsn;
+   struct management_tlv_datum *mtd;
struct subscribe_events_np *sen;
+   struct management_tlv *tlv;
+   int key, respond = 0;
 
tlv = (struct management_tlv *) req->management.suffix;
 
@@ -531,6 +576,20 @@ static int clock_management_set(struct clock *c, struct 
port *p,
*changed = 1;
respond = 1;
break;
+   case MID_ALTERNATE_TIME_OFFSET_PROPERTIES:
+   atop = (struct alternate_time_offset_properties *) tlv->data;
+   key = 

Re: [Linuxptp-devel] [PATCH] Set grandmasterIdentity to localClockIdentity

[Geva, Erez]

Hi,

You wrote "gmPresent" set to false.
In this mail you show that "gmPresent" is true.

I did not check the patch.
Only ask to write a more understandable and comprehensive explanation for the 
patch.
Explanation that describe the issue/bug/problem properly, and how is your patch 
fix the problem.

This is the first step before we actually read and check the patch itself.

I did not say there is no problem, or that the patch is incorrect.

We simply ask questions politely in the hope you get the hint.

Erez


-Original Message-
From: Joanna Yurdal  
Sent: Monday, 8 November 2021 10:44
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Set grandmasterIdentity to 
localClockIdentity

Without the proposed patch the result of pmc "get time_status" when lost 
synchronization with external GM shows:
 pmc -u -b 0  'get time_status' :
c86314.fffe.30006e-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP 
master_offset  192
ingress_time   0
cumulativeScaledRateOffset +0.0
scaledLastGmPhaseChange0
gmTimeBaseIndicator0
lastGmPhaseChange  0x'.
gmPresent  true
gmIdentity ec4670.fffe.00ee5f

while result of the "get port_data_set"  is:
c86314.fffe.30006e-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET 
portIdentityc86314.fffe.30006e-1
portState   LISTENING
logMinDelayReqInterval  1
peerMeanPathDelay   0
logAnnounceInterval 1
announceReceiptTimeout  3
logSyncInterval 0
delayMechanism  1
logMinPdelayReqInterval 0
versionNumber   2


After applying the patch the gmIdentity and gmPresent are the same as when 
issued right after ptp4l startup (before any synchronization with external GM) :
c86314.fffe.30006e-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP 
master_offset  126
ingress_time   0
cumulativeScaledRateOffset +0.0
scaledLastGmPhaseChange0
gmTimeBaseIndicator0
lastGmPhaseChange  0x'.
gmPresent  false
gmIdentity c86314.fffe.30006e


Actually it may also be relevant to reset master_offset on lost sync. Combined 
patch below:

--- a/clock.c   2021-11-08 10:41:45.027820026 +0100
+++ b/clock.c   2021-11-08 10:42:50.656801920 +0100
@@ -1994,6 +1994,7 @@
if (!tmv_is_zero(c->initial_delay))
tsproc_set_delay(c->tsproc, c->initial_delay);
c->ingress_ts = tmv_zero();
+   c->master_offset = tmv_zero();
c->path_delay = c->initial_delay;
c->master_local_rr = 1.0;
c->nrr = 1.0;
@@ -2001,6 +2002,7 @@
if (cid_eq(_id, >dds.clockIdentity)) {
pr_notice("selected local clock %s as best master",
cid2str(_id));
+   c->dad.pds.grandmasterIdentity = c->dds.clockIdentity;
} else {
pr_notice("selected best master clock %s",
cid2str(_id));








___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Set grandmasterIdentity to localClockIdentity

[Geva, Erez]

Hi,

I though gmPresent means an external clock, not own clock.

If the ptp4l looses sync, how can you have a grand master present?

Please explain.

Erez

-Original Message-
From: Joanna Yurdal  
Sent: Friday, 5 November 2021 12:04
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] Set grandmasterIdentity to localClockIdentity

When ptp4l looses synchronization with remote grandmaster and local clock is 
selected, pmc commands "get time_status" and "time_status_np"
will return "gmPresent" set to false, same way as before synchronizing with the 
remote grandmaster

Signed-off-by: Joanna Yurdal 
---
 clock.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/clock.c b/clock.c
index bbfd1a8..147bcb6 100644
--- a/clock.c
+++ b/clock.c
@@ -2001,6 +2001,7 @@ static void handle_state_decision_event(struct clock *c)
if (cid_eq(_id, >dds.clockIdentity)) {
pr_notice("selected local clock %s as best master",
cid2str(_id));
+   c->dad.pds.grandmasterIdentity = c->dds.clockIdentity;
} else {
pr_notice("selected best master clock %s",
cid2str(_id));
--
2.25.1



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Cce92cac7a2e54da1d0ee08d9a06a0f5a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637717200851549067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=C4Lklo7GuVxeZLz0e7zEqC1VaRehGgip4vUynjqLXyI%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [RFC PATCH 00/10] checksync: new program to wait for a local or remote clock to synchronize

[Geva, Erez]

Nice,

Your code is GPL,

So using your code does not helps, we can simply use linuxptp directly.

We can not integrate your code in to our application without GPL our code,
 or we need to use it through bash script/system and parse the result.

Why bother?

Enjoy coding
  Erez

P.S.
We have nothing against GPL. I use GPL and LGPL gladly and I like to share code 
freely.
But sometimes we need to write systems with code that uses a different licence.
This is the reason for LGPL and libraries.


-Original Message-
From: Vladimir Oltean  
Sent: Thursday, 4 November 2021 13:33
To: Richard Cochran 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [RFC PATCH 00/10] checksync: new program to wait 
for a local or remote clock to synchronize

On Tue, Nov 02, 2021 at 01:34:01AM +0200, Vladimir Oltean wrote:
> On Mon, Nov 01, 2021 at 03:56:38AM -0700, Richard Cochran wrote:
> > On Mon, Nov 01, 2021 at 11:19:15AM +0200, Vladimir Oltean wrote:
> > 
> > > For what it's worth, I have solved both my problems (checking 
> > > ptp4l sync and phc2sys sync) through alternative methods,
> > 
> > How did you do it?
> 
> For checking ptp4l sync I wrote my own PTP management message handling 
> over the local AF_UNIX socket and I am querying the CURRENT_DATA_SET.
> For checking phc2sys sync I shamelessly stole the relevant logic from 
> phc2sys (read_phc/sysoff_measure), including the various 
> PTP_SYS_OFFSET_* ioctls, and I am just calculating the PHC's offset to 
> CLOCK_REALTIME.
> 
> So both of these are local. Then I created some communication protocol 
> in my application (sender and receiver roles) so that the sender 
> queries the receiver about its local sync data, and then has the logic 
> necessary to figure out whether now is a good time to send or not.

Since it's GPL code that I shamelessly stole, it might be nice to also share 
the source code here (in case somebody else looking to solve the same problem 
wants to shamelessly steal mine):
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvladimiroltean%2Ftsn-scripts%2Ftree%2Fmaster%2Fisochrondata=04%7C01%7Cerez.geva.ext%40siemens.com%7Cffd2683ba41b4ddbf35a08d99f8f9a63%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637716261386237517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CkoZGsSdTa7zi93%2FvKmdq%2FYW40sw0eOuNaQgqUteewU%3Dreserved=0
The relevant files are ptpmon.c (for ptp4l monitoring) and sysmon.c (for 
phc2sys monitoring).


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Cffd2683ba41b4ddbf35a08d99f8f9a63%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637716261386247510%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ik80X7%2BZoRxah2yKcF%2Bp2poc3QZCn%2B4yAoheiDlXmaU%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Signed-off-by: Vladimir Nosikov

[Geva, Erez]

Looking on tlv.h
The next TLV is C007

The TLV should be named "MID_TIME_INACCURACY_NP"
The "_NP" implies it is LinuxPTP TLV and not a standard one.

The place you add the TLV in tlv.h looks OK.
As for the rest, I did not check.
Richard except the TLV handling be sorted by the TLV value per function/block.

Would be nice to add a short explanation why we need the propose management TLV 
in the patch letter.
Specify standard is good, but we need more.
I personally, would use short comments in the code and put the long ones in the 
patch letter.
I think, the patch letter should cover all the changes you have in the patch 
with explanations, why we need then.

Third and last point. I see 3 different changes. I think you should use a patch 
series, with each change in a separate patch,
  so we can evaluate each change by itself.
As the patches are in a single patch series, they can rely on each other, in 
the order of the series.
i.e one patch for the new configuration parameters, second for the management 
TLV and the third for the TLV append in the follow up message.

Erez


-Original Message-
From: Носиков Владимир Алексеевич  
Sent: Tuesday, 2 November 2021 13:41
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Signed-off-by: Vladimir Nosikov 


Looks like I took a wrong range, sorry.

"This range is to be used for implementation-specific identifiers" C000 - DFFF

Any value from this range? Except ofc C000, C001, C003 and C006.
____
From: Geva, Erez 
Sent: Monday, November 1, 2021 9:48:30 PM
To: Носиков Владимир Алексеевич
Cc: linuxptp-devel@lists.sourceforge.net
Subject: RE: [Linuxptp-devel] [PATCH] Signed-off-by: Vladimir Nosikov 


Hi,

From IEEE 1588-2019:
"This range is to be assigned by an alternate PTP Profile"  E000 - FFFE

Can you provide the standard reference for this TLV?

Erez

-Original Message-
From: Vladimir Nosikov via Linuxptp-devel 
Sent: Monday, 1 November 2021 13:45
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] Signed-off-by: Vladimir Nosikov 


Appending IEEE_C37_238 TLV to IEEE C37.238 Announce message (clock's 
timeInaccuracy field is settable via the pmc).
---
 clock.c| 19 +++
 clock.h|  7 +++
 config.c   |  8 +++-
 pmc.c  |  6 ++
 pmc_common.c   | 14 ++
 port.c | 29 +
 port_private.h |  2 ++
 tlv.c  | 31 +++
 tlv.h  | 19 +++
 9 files changed, 134 insertions(+), 1 deletion(-)

diff --git a/clock.c b/clock.c
index bbfd1a8..7075721 100644
--- a/clock.c
+++ b/clock.c
@@ -114,6 +114,7 @@ struct clock {
int utc_offset;
int time_flags;  /* grand master role */
int time_source; /* grand master role */
+   UInteger32 timeInaccuracy; /* Power C37.238 Profile only */
UInteger8 clock_class_threshold;
UInteger8 max_steps_removed;
enum servo_state servo_state;
@@ -346,6 +347,7 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
struct grandmaster_settings_np *gsn;
struct management_tlv_datum *mtd;
struct subscribe_events_np *sen;
+   struct time_inaccuracy *ti;
struct management_tlv *tlv;
struct time_status_np *tsn;
struct tlv_extra *extra;
@@ -397,6 +399,11 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
mtd->val = c->dds.priority2;
datalen = sizeof(*mtd);
break;
+   case MID_TIME_INACCURACY:
+   ti = (struct time_inaccuracy *) tlv->data;
+   ti->val = c->timeInaccuracy;
+   datalen = sizeof(*ti);
+   break;
case MID_DOMAIN:
mtd = (struct management_tlv_datum *) tlv->data;
mtd->val = c->dds.domainNumber; @@ -505,6 +512,7 @@ static int 
clock_management_set(struct clock *c, struct port *p,
struct management_tlv_datum *mtd;
struct grandmaster_settings_np *gsn;
struct subscribe_events_np *sen;
+   struct time_inaccuracy *ti;

tlv = (struct management_tlv *) req->management.suffix;

@@ -521,6 +529,12 @@ static int clock_management_set(struct clock *c, struct 
port *p,
*changed = 1;
respond = 1;
break;
+   case MID_TIME_INACCURACY:
+   ti = (struct time_inaccuracy *) tlv->data;
+   c->timeInaccuracy = ti->val;
+   *changed = 1;
+   respond = 1;
+   break;
case MID_GRANDMASTER_SETTINGS_NP:
gsn = (struct grandmaster_settings_np *) tlv->data;
c->dds.clockQuality = gsn->clockQuality; @@ -800,6 +814,11 @@ 
stati

Re: [Linuxptp-devel] [PATCH] Signed-off-by: Vladimir Nosikov

[Geva, Erez]

Hi,

>From IEEE 1588-2019:
"This range is to be assigned by an alternate PTP Profile"  E000 - FFFE

Can you provide the standard reference for this TLV?

Erez

-Original Message-
From: Vladimir Nosikov via Linuxptp-devel 
 
Sent: Monday, 1 November 2021 13:45
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] Signed-off-by: Vladimir Nosikov 


Appending IEEE_C37_238 TLV to IEEE C37.238 Announce message (clock's 
timeInaccuracy field is settable via the pmc).
---
 clock.c| 19 +++
 clock.h|  7 +++
 config.c   |  8 +++-
 pmc.c  |  6 ++
 pmc_common.c   | 14 ++
 port.c | 29 +
 port_private.h |  2 ++
 tlv.c  | 31 +++
 tlv.h  | 19 +++
 9 files changed, 134 insertions(+), 1 deletion(-)

diff --git a/clock.c b/clock.c
index bbfd1a8..7075721 100644
--- a/clock.c
+++ b/clock.c
@@ -114,6 +114,7 @@ struct clock {
int utc_offset;
int time_flags;  /* grand master role */
int time_source; /* grand master role */
+   UInteger32 timeInaccuracy; /* Power C37.238 Profile only */
UInteger8 clock_class_threshold;
UInteger8 max_steps_removed;
enum servo_state servo_state;
@@ -346,6 +347,7 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
struct grandmaster_settings_np *gsn;
struct management_tlv_datum *mtd;
struct subscribe_events_np *sen;
+   struct time_inaccuracy *ti;
struct management_tlv *tlv;
struct time_status_np *tsn;
struct tlv_extra *extra;
@@ -397,6 +399,11 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
mtd->val = c->dds.priority2;
datalen = sizeof(*mtd);
break;
+   case MID_TIME_INACCURACY:
+   ti = (struct time_inaccuracy *) tlv->data;
+   ti->val = c->timeInaccuracy;
+   datalen = sizeof(*ti);
+   break;
case MID_DOMAIN:
mtd = (struct management_tlv_datum *) tlv->data;
mtd->val = c->dds.domainNumber;
@@ -505,6 +512,7 @@ static int clock_management_set(struct clock *c, struct 
port *p,
struct management_tlv_datum *mtd;
struct grandmaster_settings_np *gsn;
struct subscribe_events_np *sen;
+   struct time_inaccuracy *ti;
 
tlv = (struct management_tlv *) req->management.suffix;
 
@@ -521,6 +529,12 @@ static int clock_management_set(struct clock *c, struct 
port *p,
*changed = 1;
respond = 1;
break;
+   case MID_TIME_INACCURACY:
+   ti = (struct time_inaccuracy *) tlv->data;
+   c->timeInaccuracy = ti->val;
+   *changed = 1;
+   respond = 1;
+   break;
case MID_GRANDMASTER_SETTINGS_NP:
gsn = (struct grandmaster_settings_np *) tlv->data;
c->dds.clockQuality = gsn->clockQuality; @@ -800,6 +814,11 @@ 
static int forwarding(struct clock *c, struct port *p)
 
 /* public methods */
 
+UInteger32 clock_time_inaccuracy(struct clock *c) {
+   return c->timeInaccuracy;
+}
+
 UInteger8 clock_class(struct clock *c)
 {
return c->dds.clockQuality.clockClass; diff --git a/clock.h b/clock.h 
index 0534f21..b66e341 100644
--- a/clock.h
+++ b/clock.h
@@ -59,6 +59,13 @@ struct dataset *clock_best_foreign(struct clock *c);
  */
 struct port *clock_best_port(struct clock *c);
 
+/**
+ * Obtain the IEEE C37.238 timeInaccuracy attribute from a clock.
+ * @param c  The clock instance.
+ * @return   The value of the clock's time inaccuracy.
+ */
+UInteger32 clock_time_inaccuracy(struct clock *c);
+
 /**
  * Obtain the clockClass attribute from a clock.
  * @param c  The clock instance.
diff --git a/config.c b/config.c
index f3c52ba..814420b 100644
--- a/config.c
+++ b/config.c
@@ -242,7 +242,11 @@ struct config_item config_tab[] = {
PORT_ITEM_INT("delay_response_timeout", 0, 0, UINT8_MAX),
GLOB_ITEM_INT("dscp_event", 0, 0, 63),
GLOB_ITEM_INT("dscp_general", 0, 0, 63),
-   GLOB_ITEM_INT("domainNumber", 0, 0, 127),
+   /* IEEE Std C37.238-2017 5.4: The default configuration for the domain, 
defaultDS.domainNumber,
+* shall be 254. Implementation claiming conformance to this standard 
shall be able to configure
+* domain numbers of the range 0 to 127 and the single value 254.
+*/
+   GLOB_ITEM_INT("domainNumber", 0, 0, UINT8_MAX),
PORT_ITEM_INT("egressLatency", 0, INT_MIN, INT_MAX),
PORT_ITEM_INT("fault_badpeernet_interval", 16, INT32_MIN, INT32_MAX),
PORT_ITEM_INT("fault_reset_interval", 4, INT8_MIN, INT8_MAX), @@ -284,6 
+288,8 @@ struct config_item config_tab[] = {
PORT_ITEM_INT("operLogPdelayReqInterval", 0, INT8_MIN, INT8_MAX),

Re: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait for a local or remote clock to synchronize

[Geva, Erez]

Hi,

I add TCL wrapper to http://libpmc.sf.net/

TCL might be old, but yet it is fast.
Faster then Ruby, Perl, Python and even Lua

Enjoy
   Erez


debian@tsnlaptop:~/TSN/build/libpmc (master)$ ./testing.sh
 * build libpmc

real  0m0.989s
user  0m0.832s
sys   0m0.174s

* Create linuxptp.oRTVluCqPL with running linuxptp pmc

real  0m0.124s
user  0m0.016s
sys   0m0.010s

* Create libpmc.tool.8QJb7rZal3 with running libpmc

real  0m0.005s
user  0m0.001s
sys   0m0.006s

* We expect 'protocolAddress' and 'timeSource' difference
* Statistics may apprear

diff linuxptp.oRTVluCqPL libpmc.tool.8QJb7rZal3
<   protocolAddress   3 c4:7d:46:20:ac:ae
>   protocolAddress   IEEE_802_3 c4:7d:46:20:ac:ae
<   timeSource0xa0
>   timeSourceINTERNAL_OSCILLATOR
<   timeSource  0xa0
>   timeSource  INTERNAL_OSCILLATOR

=  Run perl  =

real  0m0.045s
user  0m0.037s
sys   0m0.008s

* We except real 'user desc' on '>'
< get user desc:
> get user desc: test123

=  Run ruby  =

real  0m0.091s
user  0m0.080s
sys   0m0.012s

=  Run lua  =

lua 5.1 

real  0m0.015s
user  0m0.012s
sys   0m0.004s

lua 5.2 

real  0m0.019s
user  0m0.009s
sys   0m0.011s

lua 5.3 

real  0m0.017s
user  0m0.018s
sys   0m0.000s

=  Run python  =

python3.9 

real  0m0.089s
user  0m0.046s
sys   0m0.012s

=  Run php  =

real  0m0.023s
user  0m0.013s
sys   0m0.011s

=  Run tcl  =

real  0m0.012s
user  0m0.007s
sys   0m0.007s
debian@tsnlaptop:~/TSN/build/libpmc (master)$




From: Erez 
Sent: Monday, 18 October 2021 10:32
To: Richard Cochran 
Cc: Geva, Erez (ext) (DI PA DCP R 3) ; 
linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait 
for a local or remote clock to synchronize



On Sat, 16 Oct 2021 at 16:46, Richard Cochran 
mailto:richardcoch...@gmail.com>> wrote:
On Fri, Oct 15, 2021 at 10:48:28PM +, Geva, Erez wrote:
> Regarding the "ugly scripting" of  pmc.
>
> I create the 
> http://libpmc.sf.net/<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibpmc.sf.net%2F=04%7C01%7Cerez.geva.ext%40siemens.com%7Cdef08208ec03621808d99211e156%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637701428500899042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=pShFZwUeGcRcnotI%2FOvoCjFZwRtAxPDGkzU7%2FIYsMIo%3D=0>
>  just to work around this issue.
>
> The libpmc provides a library with pmc tool capabilities, and wrapper for 
> scripting as Python, Lua and Perl.

I just took a look and saw the SWIG file.  Neat!  Now I can script pmc
using tcl/tk.  (Yes, that probably dates me, but still that is my
go-to scripting language when the task is too complex for bash).

Seems so, I will add Tcl/Tk.


> I think pmc is as a testing tool for the linuxptp project, but not a real 
> tool for users.

That is true, but people are still using it in production systems.
Hopefully your library will provide a more flexible way going forward.

Thanks,
Richard


Thanks Richard.

I wrote it for production.
It'll probably take time for people to learn about it.

Thanks
   Erez



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel=04%7C01%7Cerez.geva.ext%40siemens.com%7Cdef08208ec03621808d99211e156%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637701428500899042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=i12qNmtEp79LfETt9LDXWLtOdy3jwK3cy9HTXrXZank%3D=0>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait for a local or remote clock to synchronize

[Geva, Erez]

Regarding the "ugly scripting" of  pmc.

I create the http://libpmc.sf.net/ just to work around this issue.

The libpmc provides a library with pmc tool capabilities, and wrapper for 
scripting as Python, Lua and Perl.

I think pmc is as a testing tool for the linuxptp project, but not a real tool 
for users.

The libpmc also comes with a compatible pmc tool that runs much faster then the 
original.

Although, I am not oppose your patch. I just find it useless, as I perform the 
same result in a Perl script.
And with a much higher flexibility and a better performance.

You can use the libpmc, to write a tool like that in the script language you 
like.
And submit it as an example in the libpmc project.

Enjoy
   Erez

-Original Message-
From: Vladimir Oltean  
Sent: Wednesday, 13 October 2021 19:38
To: richardcoch...@gmail.com
Cc: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait for 
a local or remote clock to synchronize

In the spirit of UNIX where one program does one job and does it well (famous 
last words), there seems to be a need for a standalone binary that performs a 
very trivial task: wait until the PTP synchronization finishes*.

*The definition we choose for "finishing" is rather primitive: the offset to 
master is below a certain threshold. We make no guarantees that it may not rise 
above that threshold right after this program decides that the synchronization 
ended.

Fundamentally, this program works in the following way: it automates what you 
are able to do using the following command:

pmc -u -b 0 'GET TIME_STATUS_NP'
sending: GET TIME_STATUS_NP
a6f4af.fffe.fdfc73-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset  0  <- this is the 
interesting part
ingress_time   90010984167360
cumulativeScaledRateOffset +0.0
scaledLastGmPhaseChange0
gmTimeBaseIndicator0
lastGmPhaseChange  0x'.
gmPresent  true
gmIdentity 001f7b.fffe.630248

The program exits when the "master_offset" becomes <= the given threshold 
(passed via the "-x" option). The default value for the threshold is 0 ns.

but because scripting pmc is rather ugly (I'm not even sure if it was designed 
for that), we do it in a small C program.

Opening a PMC agent over the local UNIX domain socket will obviously only be 
able to reach the ports that are local to this system.
However, that creates a problem: we may have a back-to-back connection between 
a master and a slave, and we haven't turned off the BMCA, so we don't know 
beforehand if we're going to be master or slave. But nonetheless, we want to 
send some data once the link is synchronized (i.e. if we're the slave, wait 
until we're synchronized; if we're the master, it would be nice to check that 
the link partner is synchronized).

To support that use case, we actually need yet another PMC agent, this time one 
that subscribes for push notifications over the network.

So we create one PMC agent over UDS, and one PMC agent over the network for 
each local port, in case that port might become a master.

This new program needs the remote ptp4l instance to be run using 
"allow_remote_subscribers" set to 1. If that is turned off, it will work in a 
limited mode where it can only detect that the local system has finished sync, 
because the local port is a slave and no network agent is required for that.

There is one more important option to mention, "-i" for the designated 
interface. This option can be omitted, and when that happens, checksync will 
wait for all detected slave ports to finish sync. When "-i" is specified, it 
will wait for a single port to finish. Which port? see below.

The idea is that scripts should be able to do:

system-a $ ptp4l -i eth0 -2 -P allow_remote_subscriptions 1 & system-a $ 
checksync -i eth0 -m -2 -x 20 && echo "Clock A is synchronized"
system-b $ ptp4l -i eth1 -2 -P allow_remote_subscriptions 1 & system-b $ 
checksync -i eth1 -m -2 -x 20 && echo "Clock B is synchronized"

otherwise said, run exactly the same script on different systems.
However with PTP, one system may become master and the other may become slave, 
and therefore, one checksync instance will need to check the time status of the 
local system, and the other instance will need to check the time status of the 
remote system.

But we don't want to know the details of the remote system, nor do we want to 
log into it using ssh and run checksync there. For all we care, we should be 
able to run checksync on a port that is in the MASTER state, and it should 
figure out which remote ports to check.

So when "-i" is specified and that interface is a master port, we actually 
check the sync status of the remote ports attached to it.

[ note, we actually 

Re: [Linuxptp-devel] Porting ptp4l for custom timestamp hardware

[Geva, Erez]

Hi,

The linuxptp needs the driver to register to the PTP layer.

You may write a complete kernel driver, or a driver in kernel that register the 
PTP layer and communicate with the user space driver.

Good luck

Erez



-Original Message-
From: Richard Cochran  
Sent: Friday, 1 October 2021 15:43
To: Mohan K 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Porting ptp4l for custom timestamp hardware

On Fri, Oct 01, 2021 at 06:49:05PM +0530, Mohan K wrote:

> The driver for FPGA is in user-space and it is a memory mapped device.
> 
> Kindly throw some high-level inputs on how this porting can be achieved.


Write a proper kernel device driver.


Good luck,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Cd2dfb8dd799f4e05c02d08d984e19203%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637686926617857543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vYfzx4ScsV97bQHtcWjYuh2TSNW1PrLTUnCILvr53ac%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Porting ptp4l for custom timestamp hardware

[Geva, Erez]

You may do this too.

A legal point, As linuxptp is GPL, any changed code or code you link with it 
have to be GPL too!

And be published according to GPL.

Erez


From: Luigi 'Comio' Mantellini 
Sent: Friday, 1 October 2021 16:02
To: Richard Cochran 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Porting ptp4l for custom timestamp hardware

...or try to hack the raw transport (raw.c/raw.h)

good lock again,

ciao

lugi

Il giorno ven 1 ott 2021 alle ore 15:44 Richard Cochran 
mailto:richardcoch...@gmail.com>> ha scritto:
On Fri, Oct 01, 2021 at 06:49:05PM +0530, Mohan K wrote:

> The driver for FPGA is in user-space and it is a memory mapped device.
>
> Kindly throw some high-level inputs on how this porting can be achieved.


Write a proper kernel device driver.


Good luck,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


--
Luigi 'Comio' Mantellini
[cid:image001.gif@01D7B718.1F792490]My Professional 
Profile

"UNIX is very simple, it just needs a genius to understand its simplicity." 
[cit.]

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds.

[Geva, Erez]

Hi,

Entering the pmc tool interactive mode is simple.
Run the pmc tool without a management command.
For example:

Using direct mode:
# pmc -u -f /etc/linuxptp/ptp4l.conf 'get VERSION_NUMBER' 'get PRIORITY1'

Using interactive mode:
# pmc -u -f /etc/linuxptp/ptp4l.conf
Now you can enter:
get VERSION_NUMBER


Regarding the https://sf.net/projects/libpmc project.
It is a separate project, aim to provide a pmc library with LGPL licence. Sort 
of filling the gap.
Both the pmc tool and the libpmc uses standard IEEE 1558 management messages,
 and can be used with any IEEE 1558 entity that supports IEEE 1558 management 
messages.

:-)
Erez

-Original Message-
From: Eric Decker  
Sent: Thursday, 19 August 2021 04:56
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 

Subject: RE: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with 
corresponding requests on the UDS port, and always send with a unique sequence 
count from uds.

Hi Erez,

I thought it might be better to take this part of the conversation offline, but 
maybe it will benefit others.

How do you run pmc in interactive mode?  I do not see that in the documentation.

What is libpmc?  Is it a part of the standard Linux PTP distribution, or is it 
a supplement to it? Would others people be aware it is available?  I thought I 
reviewed all of the documentation and I never heard of it.

Thanks,

Eric Decker

-Original Message-
From: Geva, Erez 
Sent: Wednesday, August 18, 2021 8:37 PM
To: Eric Decker 
Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 

Subject: RE: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with 
corresponding requests on the UDS port, and always send with a unique sequence 
count from uds.

Hi,

Regarding:  "pmc executes as a new process each time it is called".  

1. No you can run the pmc tool in interactive mode. Then send new requests, 
line by line and with increasing the sequence ID.

2. You can use the libpmc library https://sf.net/projects/libpmc, The library 
allow you to set any sequence ID you wish.


I do not see why is that an issue for the ptp4l project.

Erez


-Original Message-
From: Eric Decker 
Sent: Wednesday, 18 August 2021 19:26
To: Richard Cochran 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with 
corresponding requests on the UDS port, and always send with a unique sequence 
count from uds.

Response below tagged as EDecker:

Eric Decker

-Original Message-
From: Richard Cochran 
Sent: Wednesday, August 18, 2021 12:23 PM
To: Eric Decker 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with 
corresponding requests on the UDS port, and always send with a unique sequence 
count from uds.

On Mon, Aug 16, 2021 at 03:38:21PM +, Eric Decker wrote:
> Subject: [PATCH] Only forward responses to UDS port with corresponding 
> requests on the UDS port, and always send management with a unique sequence 
> count from uds.

The subject line should be ONE sentence, please.
EDecker: It is one sentence.

> 
> 1.  Only forward responses to UDS port with a corresponding requests on 
> the UDS port.

This is one "issue", and you have a second issue, below.  That means you should 
make (at least) two patches that address the issues independently.
 
> When ptp4l is configured as a boundary clock and a host on ethernet is 
> issuing excessive management requests (a PTP monitoring tool) then the 
> requests get forwarded across the boundary clock and the subsequent 
> responses get forwarded to the UDS port.  The UDS code sends messages 
> to the uds address of the last process it received a message from.
> The phc2sys daemon is not expecting these responses which causes its 
> receive buffers to get full and then the ptp4l send buffers get full 
> which causes ptp4l to lock until phc2sys reads the messages from its 
> uds port.  ptp4l will lock until phc2sys reads messages from the uds 
> port which happens every 60sec.

So the proper fix would be to ensure the ptp4l's write() is non blocking.
EDecker: I wonder if that approach would have unexpected consequences.
 
> How the proposed solution fixes the problem:  
>
> Ptp4l will only forward ptp management response messages to the uds 
> port if it was requested by the uds port.  This will prevent the uds 
> port buffers from getting full and causing ptp4l to hang until the 
> buffers are read.

Actually, this is wrong.  Why?  Because the management scheme in 1588 is 
multicast on purpose.  All of the clients benefit from the replies.

For example, if a client wants to monitor CURRENT_DATA_SET periodically, it can 
set a timer.  If a reply from *another* client arrives before the timer 
expires, the client simply uses the information in the reply 

Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds.

[Geva, Erez]

Hi,

Regarding:  "pmc executes as a new process each time it is called".  

1. No you can run the pmc tool in interactive mode. Then send new requests, 
line by line and with increasing the sequence ID.

2. You can use the libpmc library https://sf.net/projects/libpmc/, The library 
allow you to set any sequence ID you wish.


I do not see why is that an issue for the ptp4l project.

Erez


-Original Message-
From: Eric Decker  
Sent: Wednesday, 18 August 2021 19:26
To: Richard Cochran 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with 
corresponding requests on the UDS port, and always send with a unique sequence 
count from uds.

Response below tagged as EDecker:

Eric Decker

-Original Message-
From: Richard Cochran 
Sent: Wednesday, August 18, 2021 12:23 PM
To: Eric Decker 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with 
corresponding requests on the UDS port, and always send with a unique sequence 
count from uds.

On Mon, Aug 16, 2021 at 03:38:21PM +, Eric Decker wrote:
> Subject: [PATCH] Only forward responses to UDS port with corresponding 
> requests on the UDS port, and always send management with a unique sequence 
> count from uds.

The subject line should be ONE sentence, please.
EDecker: It is one sentence.

> 
> 1.  Only forward responses to UDS port with a corresponding requests on 
> the UDS port.

This is one "issue", and you have a second issue, below.  That means you should 
make (at least) two patches that address the issues independently.
 
> When ptp4l is configured as a boundary clock and a host on ethernet is 
> issuing excessive management requests (a PTP monitoring tool) then the 
> requests get forwarded across the boundary clock and the subsequent 
> responses get forwarded to the UDS port.  The UDS code sends messages 
> to the uds address of the last process it received a message from.
> The phc2sys daemon is not expecting these responses which causes its 
> receive buffers to get full and then the ptp4l send buffers get full 
> which causes ptp4l to lock until phc2sys reads the messages from its 
> uds port.  ptp4l will lock until phc2sys reads messages from the uds 
> port which happens every 60sec.

So the proper fix would be to ensure the ptp4l's write() is non blocking.
EDecker: I wonder if that approach would have unexpected consequences.
 
> How the proposed solution fixes the problem:  
>
> Ptp4l will only forward ptp management response messages to the uds 
> port if it was requested by the uds port.  This will prevent the uds 
> port buffers from getting full and causing ptp4l to hang until the 
> buffers are read.

Actually, this is wrong.  Why?  Because the management scheme in 1588 is 
multicast on purpose.  All of the clients benefit from the replies.

For example, if a client wants to monitor CURRENT_DATA_SET periodically, it can 
set a timer.  If a reply from *another* client arrives before the timer 
expires, the client simply uses the information in the reply and resets the 
timer.  This scheme will reduce duplicated queries in the network.

So ptp4l must not filter the replies. 

EDecker: If a non-blocking write fixes the problem with no side effects then 
perhaps that is a better solution.  The use case I am using is requesting data 
using pmc.  A host attempting to access data using PMC will not benefit from 
another host having previously requested the same data.  How would the host 
requesting data using pmc know that ptp4l previously received a similar 
response, and how would it know how recently that response was received?

> 2.  PTP management messages originated from UDS (pmc) do not have the 
> correct source clock id,

I can't agree with this statement.  There is no such thing a "correct"
clockId.  They are arbitrary.
EDecker: I would expect the source clock ID of a management message to be the 
clock ID of the module which sent the message.

> and always have the same sequence count

untrue.  See line 540 of pmc_common.c:

msg->header.sequenceId = pmc->sequence_id++;


EDecker: The problem is pmc executes as a new process each time it is called.  
The sequence count sent from pmc to ptp4l is always the same (0 or 1), so ptp4l 
always sends management messages from pmc with the same sequence count.

> which prevents end nodes on ethernet from responding.

Why should that prevent nodes from responding?

EDecker: Some end nodes I work with monitor the sequence count to make sure it 
is not a duplicate or "malformed" packet and do not process the management 
message unless the sequence count is unique as compared to previous management 
messages from the same clock/module.

> Ptp4l will now maintain a static sequence count and send PTP 
> management messages using this sequence count so each PTP management 
> message will have a unique sequential sequence count.

ptp4l 

[Linuxptp-devel] process ID size in the pmc tool

[Geva, Erez]

Hi,

In pmc_create(...)

if (transport_type == TRANS_UDS) {
pmc->port_identity.portNumber = getpid();

When portNumber is UInteger16

However in new Linux systems, I notice that the process ID can be larger than 
16 bits.

Do you think we need to bitwise here with 0x?


With best regards,
Erez Geva

AURELLY TECHNOLOGIES GmbH
External service provider at Siemens AG
Digital Industries
Process Automation
Software House Nbg
DI PA DCP R 3
Gleiwitzer Str. 555
90475 Nuremberg, Germany
mailto:erez.geva@siemens.com
[cid:image001.png@01D793A0.0936DD80]
www.aurelly.com
CEO: Jens Stötzner, company's place of business: Nürnberg,
VAT identification: DE 255071685, Commercial register No.: HRB: 15550
[cid:image002.png@01D793A0.0936DD80] Please consider the environment before 
printing this email
Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 4/4] ts2phc: Add serial baudrate option

[Geva, Erez]

Hi,

Do you mean this one, page 20?
http://www.leapsecond.com/museum/z3801a/097-z3801-01-iss-1.pdf

Erez

-Original Message-
From: Richard Cochran  
Sent: Monday, 19 July 2021 04:13
To: Hal Murray 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 4/4] ts2phc: Add serial baudrate option

On Fri, May 14, 2021 at 10:16:02AM -0700, Hal Murray wrote:
> 
> > I did think of that, yet of the many serial devices I have used they 
> > have all been running with the setting 8/N/1 and no HW flow control.
> 
> The HP Z3801A is 19200 baud, 7 data bits, odd parity

Looks like it is configurable on that device?

8n1 is almost universally used.

We can add a second option if people really are stuck with non-configurable 
equipment.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C5ec82f622f0748b51e2d08d94a5ae1e0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637622576481447078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=XTst8hWxENV43ybSJo%2Bjg%2FvdL5jnf3HzhXS%2BlxkTp6U%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 4/4] ts2phc: Add serial baudrate option

[Geva, Erez]

This looks like a call to send the a patch with these options.

Richard, How do you think these options should be implemented?
A single enumerator, separate integer for each?

Erez

-Original Message-
From: Hal Murray  
Sent: Monday, 19 July 2021 12:39
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net; Hal Murray 
Subject: Re: [Linuxptp-devel] [PATCH 4/4] ts2phc: Add serial baudrate option


erez.geva@siemens.com said:
> Do you mean this one, page 20?
> http://www.leapsecond.com/museum/z3801a/097-z3801-01-iss-1.pdf


Yes, but look down on page 93 (or 5-3)

> Baud Rate:  19200--7 data bits, 1 start bit, 1 stop bit, odd parity 
> (fixed configuration).



--
These are my opinions.  I hate spam.





___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5

[Geva, Erez]

I do not see any connection of pmc poll time-out to ptp4l waiting for TX time 
stamp.

On my libpmc https://sf.net/p/libpmc I do not use any time out.
The libpmc pmc tools works better this way.

Erez

-Original Message-
From: Eric Decker  
Sent: Friday, 9 July 2021 00:28
To: Richard Cochran ; Miroslav Lichvar 

Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout 
to 5

If I recall correctly there is an unconditional 150ms delay in PMC which also 
uses poll().  That I why I asked the question.  The delay in PMC may be related 
to how the firmware is structured, not poll().  I am using Linux 4.xx.

Eric Decker

-Original Message-
From: Richard Cochran 
Sent: Thursday, July 8, 2021 1:42 PM
To: Miroslav Lichvar 
Cc: Eric Decker ; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout 
to 5

On Thu, Jul 08, 2021 at 01:10:08PM +0200, Miroslav Lichvar wrote:
> On Thu, Jul 08, 2021 at 01:37:38AM +, Eric Decker wrote:
> > If the timestamp is available in less than the timeout (5ms) will it still 
> > wait for the timeout, or continue processing after the timestamp is 
> > received?
> 
> The poll() call is waiting for the descriptor, so it should return as 
> soon as the timestamp is ready. The option sets the maximum time it 
> waits.

But on kernels older than (mumble) (3.5?) the code will sleep the entire 
period, then wake to read the time stamp.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C1d784133383c4cd4e2b408d9425fe84b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637613801951566481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9D4HZAuH9zExpzT86tfZjXtO4%2FQ%2B6ednYqty4SnbVAQ%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] Intel 210 to Intel 255

[Geva, Erez]

Hi,

I see an issue with the ptp4l using an Intel I210 connected back to back to an 
Intel i255.
I am not sure if the issue is Intel related or is it ptp4l.
Probably something wrong that I did.

I use a very simple configuration:
On client side:
[global]
delay_mechanism P2P
network_transport L2
time_stamping hardware
slaveOnly 1
priority1 255
priority2 255
hwts_filter full

On source side:
[global]
delay_mechanism P2P
network_transport L2
time_stamping hardware
slaveOnly 0
priority1 100
priority2 100
hwts_filter full

I get this message on client.
I tried to switch sides of source, client and have the same message, once on 
the I210 and once in the i255.

Jun  7 15:44:06 ipc01 ptp4l: [672.901] master offset177 s2 freq  -34616 
path delay   -10
Jun  7 15:44:06 ipc01 ptp4l: [673.434] port 1: FAULTY to LISTENING on 
INIT_COMPLETE
Jun  7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx timestamp
Jun  7 15:44:07 ipc01 ptp4l: [673.869] increasing tx_timestamp_timeout may 
correct this issue, but it is likely caused by a driver bug
Jun  7 15:44:07 ipc01 ptp4l: [673.869] port 1: send peer delay response failed

I use both interface with auto-negotiation

root@ipc01:~# ethtool -i enp8s0
driver: igb
version: 5.10.30-rt37-tsn3-rt-ipipe
...
root@ipc01:~# ethtool  enp8s0
Settings for enp8s0:
   Supported ports: [ TP ]
   Supported link modes:   10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Supported pause frame use: Symmetric
   Supports auto-negotiation: Yes
   Supported FEC modes: Not reported
   Advertised link modes:  10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Advertised pause frame use: Symmetric
   Advertised auto-negotiation: Yes
   Advertised FEC modes: Not reported
   Speed: 1000Mb/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 1
   Transceiver: internal
   Auto-negotiation: on
   MDI-X: on (auto)
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x0007 (7)
drv probe link
   Link detected: yes


root@ipc02:~# ethtool -i enp7s0
driver: igc
version: 5.10.30-rt37-tsn3-rt-ipipe
...
root@ipc02:~# ethtool enp7s0
Settings for enp7s0:
   Supported ports: [ ]
   Supported link modes:   10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   2500baseT/Full
   Supported pause frame use: Symmetric
   Supports auto-negotiation: Yes
   Supported FEC modes: Not reported
   Advertised link modes:  10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Advertised pause frame use: Symmetric
   Advertised auto-negotiation: Yes
   Advertised FEC modes: Not reported
   Speed: 1000Mb/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 0
   Transceiver: internal
   Auto-negotiation: on
   MDI-X: off (auto)
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x0007 (7)
drv probe link
   Link detected: yes

With best regards,
Erez Geva

AURELLY TECHNOLOGIES GmbH
External service provider at Siemens AG
Digital Industries
Process Automation
Software House Nbg
DI PA DCP R 3
Gleiwitzer Str. 555
90475 Nuremberg, Germany
mailto:erez.geva@siemens.com
[cid:image002.jpg@01D75BB6.5ED14EF0]
www.aurelly.com
CEO: Jens Stötzner, company's place of business: Nürnberg,
VAT identification: DE 255071685, Commercial register No.: HRB: 15550
[cid:image004.png@01D75BB6.5ED14EF0] Please consider the environment before 
printing this email
Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and clock

[Geva, Erez]

IEEE 1558 2019 does define Float64 that follow using the IEEE Std 754

As most hardware that runs Linux already use IEEE Std 754 (on hardware level or 
library level for hardware lacking floating point).

The Float64 match C float on most 64 bits machine.
You may need more code to ensure your C code uses proper 64 bits float.
I guess, this is why Richard avoid using it.

However Miroslav is right that you do need to change to network order.

Something like :

stats->freq_stats = __cpu_to_be64((uint64_t)(c->freq_stats));

And define
struct clock {
...
float freq_stats,
...
};

struct clock_stats_np_tlv {
...
uint64 freq_stats,
...
};

Or follow Miroslav advice and use integers only.

Erez

From: Tim Martin 
Sent: Thursday, 27 May 2021 18:52
To: Miroslav Lichvar 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and 
clock

Thanks Miroslav,

Thanks for the feedback.  Sure, I can make an update to send 
network(big)-endian fixed point instead of platform-endian floating point if 
the patch will otherwise be accepted, but need to resolve the feedback from 
Erez and Richard first.

Tim

From: Miroslav Lichvar mailto:mlich...@redhat.com>>
Date: Wednesday, May 26, 2021 at 4:45 AM
To: Tim Martin mailto:timot...@nvidia.com>>
Cc: 
linuxptp-devel@lists.sourceforge.net
 
mailto:linuxptp-devel@lists.sourceforge.net>>
Subject: Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and 
clock
External email: Use caution opening links or attachments


On Tue, May 25, 2021 at 08:28:34PM +, Tim Martin wrote:
> +struct clock_stats_np_tlv {
> + struct stats_result offset_stats;
> + struct stats_result freq_stats;
> + struct stats_result delay_stats;
> + uint8_t offset_freq_stats_valid;
> + uint8_t delay_stats_valid;
> +} PACKED;

Floating-point formats are not generally portable. In a network
protocol they need to be converted to something else. Some of the
implemented TLVs use fixed-point formats shifting by 32 or 41 bits. In
this case I think it might be ok to just use integer nanoseconds and
parts per billion.

--
Miroslav Lichvar
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and clock

[Geva, Erez]

Hi,

I would like to use this opportunity to promote the libpmc library.
https://sf.net/p/linuxptp/

The library provide the functionality of the pmc tool.
It comes with wrapping for python, Perl, Lua, php, ruby.

And runs more then 20 times faster then the original linuxptp pmc tool

Query a single line with all the management TLVs, result:

* Query using linuxptp pmc
real0m0.117s
user0m0.010s
sys 0m0.009s

 * Query using libpmc pmc tool
real0m0.005s
user0m0.004s
sys 0m0.002s

Using the library and subscribe to NOTIFY_TIME_SYNC.
You can construct the statistics you need, and in a very light way.

The full query line I use for the benchmark is
sudo pmc -u -f /etc/linuxptp/ptp4l.conf  "get ANNOUNCE_RECEIPT_TIMEOUT" "get 
CLOCK_ACCURACY" "get CLOCK_DESCRIPTION" "get CURRENT_DATA_SET" "get 
DEFAULT_DATA_SET" "get DELAY_MECHANISM" "get DOMAIN" "get 
LOG_ANNOUNCE_INTERVAL" "get LOG_MIN_PDELAY_REQ_INTERVAL" "get 
LOG_SYNC_INTERVAL" "get PARENT_DATA_SET" "get PRIORITY1" "get PRIORITY2" "get 
SLAVE_ONLY" "get TIMESCALE_PROPERTIES" "get TIME_PROPERTIES_DATA_SET" "get 
TRACEABILITY_PROPERTIES" "get USER_DESCRIPTION" "get VERSION_NUMBER" "get 
PORT_DATA_SET" "get TIME_STATUS_NP" "get GRANDMASTER_SETTINGS_NP" "get 
PORT_DATA_SET_NP" "get PORT_PROPERTIES_NP" "get PORT_STATS_NP" "get 
SUBSCRIBE_EVENTS_NP" "get SYNCHRONIZATION_UNCERTAIN_NP" "get MASTER_ONLY"


Enjoy
  Erez



-Original Message-
From: Richard Cochran  
Sent: Thursday, 27 May 2021 15:18
To: Tim Martin 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and 
clock

On Tue, May 25, 2021 at 08:28:34PM +, Tim Martin wrote:
> Currently there is no way to programmatically access statistics about 
> the clock frequency offset, time delay, or time offset (collectively, 
> the "clock_stats" metrics), except for parsing the ptp4l logs.  One 
> option for time offset would be to poll TLV_TIME_STATUS_NP in regular 
> intervals from a custom client, but that has the disadvantage of 
> either very high poll rates or missed updates which would affect the 
> statistics.

Not if you use the push method.

commit 6d7c090706e76af334185ffcec9cc56d0570e215
Author: Juergen Werner 
Date:   Wed Jan 20 20:11:34 2021 +0100

Implement push notification for TIME_STATUS_NP

Subscribers to NOTIFY_TIME_SYNC will be notified on every clock
synchronization.


Thanks,
Richard



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C4cafa709f6fc450b9bf808d92111eef3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637577183170988648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FCB9sCIZHMsI0Qk9WnHX6uC8aW7TKKrko5YwSmlK2Uo%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and clock

[Geva, Erez]

In IEEE 1588-2019
I see PARENT_DATA_SET with
- observedParentOffsetScaledLogVariance
- observedParentClockPhaseChangeRate

You use a natural statistics syntax.
Perhaps you may use a more coherent phrasing that match the standard.
May be something that match the performanceMonitoringDS, like 
- averageMasterSlaveDelay
- minMasterSlaveDelay
...

Erez

-Original Message-
From: Tim Martin  
Sent: Tuesday, 25 May 2021 22:29
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and 
clock

Currently there is no way to programmatically access statistics about the clock 
frequency offset, time delay, or time offset (collectively, the "clock_stats" 
metrics), except for parsing the ptp4l logs.  One option for time offset would 
be to poll TLV_TIME_STATUS_NP in regular intervals from a custom client, but 
that has the disadvantage of either very high poll rates or missed updates 
which would affect the statistics.

To address these issues, introduce a management mesage, CLOCK_STATS_NP, which 
reports the statistics that would be displayed in the ptp4l log file.  This 
fixes the above problem by allowing a custom client to poll CLOCK_STATS_NP at 
longer intervals without missing any updates.

Follow-up patches could then introduc knobs to configure the time over which 
CLOCK_STATS_NP integrates statistics, separate from any other tracking loop 
updates, which would allow even longer polling intervals.

Signed-off-by: Tim Martin 
---
 clock.c  | 50 ++
 pmc.c| 48 
 pmc_common.c |  1 +
 tlv.h| 10 ++
 4 files changed, 93 insertions(+), 16 deletions(-)

diff --git a/clock.c b/clock.c
index e545a9b..550d222 100644
--- a/clock.c
+++ b/clock.c
@@ -129,6 +129,9 @@ struct clock {
double nrr;
struct clock_description desc;
struct clock_stats stats;
+   struct stats_result offset_stats, freq_stats, delay_stats;
+   int offset_freq_stats_valid;
+   int delay_stats_valid;
int stats_interval;
struct clockcheck *sanity_check;
struct interface *uds_rw_if;
@@ -144,7 +147,7 @@ struct clock the_clock;  static void 
handle_state_decision_event(struct clock *c);  static int 
clock_resize_pollfd(struct clock *c, int new_nports);  static void 
clock_remove_port(struct clock *c, struct port *p); -static void 
clock_stats_display(struct clock_stats *s);
+static void clock_stats_display(struct clock *c);
 
 static void remove_subscriber(struct clock_subscriber *s)  { @@ -351,6 +354,7 
@@ static int clock_management_fill_response(struct clock *c, struct port *p,
struct tlv_extra *extra;
struct PTPText *text;
uint16_t duration;
+   struct clock_stats_np_tlv *stats;
int datalen = 0;
 
extra = tlv_extra_alloc();
@@ -462,6 +466,15 @@ static int clock_management_fill_response(struct clock *c, 
struct port *p,
mtd->val = c->local_sync_uncertain;
datalen = sizeof(*mtd);
break;
+   case TLV_CLOCK_STATS_NP:
+   stats = (struct clock_stats_np_tlv *) tlv->data;
+   stats->offset_stats = c->offset_stats;
+   stats->freq_stats = c->freq_stats;
+   stats->delay_stats = c->delay_stats;
+   stats->offset_freq_stats_valid = c->offset_freq_stats_valid;
+   stats->delay_stats_valid = c->delay_stats_valid;
+   datalen = sizeof(*stats);
+   break;
default:
/* The caller should *not* respond to this message. */
tlv_extra_recycle(extra);
@@ -544,7 +557,7 @@ static int clock_management_set(struct clock *c, struct 
port *p,
/* Display stats on change of local_sync_uncertain */
if (c->local_sync_uncertain != mtd->val
&& stats_get_num_values(c->stats.offset))
-   clock_stats_display(>stats);
+   clock_stats_display(c);
c->local_sync_uncertain = mtd->val;
respond = 1;
break;
@@ -556,38 +569,41 @@ static int clock_management_set(struct clock *c, struct 
port *p,
return respond ? 1 : 0;
 }
 
-static void clock_stats_update(struct clock_stats *s,
+static void clock_stats_update(struct clock *c,
   double offset, double freq)
 {
+   struct clock_stats *s = >stats;
stats_add_value(s->offset, offset);
stats_add_value(s->freq, freq);
 
if (stats_get_num_values(s->offset) < s->max_count)
return;
 
-   clock_stats_display(s);
+   clock_stats_display(c);
 }
 
-static void clock_stats_display(struct clock_stats *s)
+static void clock_stats_display(struct clock *c)
 {
-   struct stats_result offset_stats, freq_stats, 

Re: [Linuxptp-devel] [PATCH v3 1/1] Add master only management TLV

[Geva, Erez]

The value comes from configuration on start up.
Our configuration file is read only.

The patch only implement a read operation (GET).

Erez


From: luigi.mantell...@sm-optics.com 
Sent: Monday, 24 May 2021 08:53
To: linuxptp-devel@lists.sourceforge.net; Geva, Erez (ext) (DI PA DCP R 3) 

Subject: R: [Linuxptp-devel] [PATCH v3 1/1] Add master only management TLV

Dear Erez,
Dear All,

I think that the value should  be stored into config also, because after a 
fault the complete configuration is reloaded.

ciao

luigi




Luigi Mantellini
Senior Software Developer
Tel. (+39) 342 182 3893
luigi.mantell...@sm-optics.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fluigi.mantellini%40sm-optics.com%2F=04%7C01%7Cerez.geva.ext%40siemens.com%7C4a38427813cc4ecb904408d91e8089c6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637574359810160636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=6uKXmqFQcovr4ER6wBcgp60uQOruvzk2MxtN2lu%2FGeY%3D=0>

<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sm-optics.com%2F=04%7C01%7Cerez.geva.ext%40siemens.com%7C4a38427813cc4ecb904408d91e8089c6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637574359810170631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=fGz5tzKXZLDB5zUp7Q3SvwrJn91yoYiB0HIwoprxqNM%3D=0>
SM-Optics
SIAE Microelettronica Group
Via Michelangelo Buonarroti, 1
20093 Cologno Monzese, Milano
ITALY
Tel. (+39) 02 273 251
Fax (+39) 02 253 91585
https://www.sm-optics.com/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sm-optics.com%2F=04%7C01%7Cerez.geva.ext%40siemens.com%7C4a38427813cc4ecb904408d91e8089c6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637574359810170631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=fGz5tzKXZLDB5zUp7Q3SvwrJn91yoYiB0HIwoprxqNM%3D=0>

>>> Erez Geva mailto:erez.geva@siemens.com>> 
>>> 24/05/21 1.25 >>>
- Add support in the pmc tool
- Add the TLV in port module.

Signed-off-by: Erez Geva 
mailto:erez.geva@siemens.com>>
---
pmc.c | 5 +
pmc_common.c | 2 ++
port.c | 6 ++
3 files changed, 13 insertions(+)

diff --git a/pmc.c b/pmc.c
index a767c8a..00d6014 100644
--- a/pmc.c
+++ b/pmc.c
@@ -335,6 +335,11 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
fprintf(fp, "TIMESCALE_PROPERTIES "
IFMT "ptpTimescale %d", mtd->val & PTP_TIMESCALE ? 1 : 0);
break;
+case TLV_MASTER_ONLY:
+mtd = (struct management_tlv_datum *) mgt->data;
+fprintf(fp, "MASTER_ONLY "
+IFMT "masterOnly %d", mtd->val);
+break;
case TLV_TIME_STATUS_NP:
tsn = (struct time_status_np *) mgt->data;
fprintf(fp, "TIME_STATUS_NP "
diff --git a/pmc_common.c b/pmc_common.c
index c5cd992..101df55 100644
--- a/pmc_common.c
+++ b/pmc_common.c
@@ -104,6 +104,7 @@ struct management_id idtab[] = {
{ "ALTERNATE_TIME_OFFSET_NAME", TLV_ALTERNATE_TIME_OFFSET_NAME, 
not_supported },
{ "ALTERNATE_TIME_OFFSET_MAX_KEY", TLV_ALTERNATE_TIME_OFFSET_MAX_KEY, 
not_supported },
{ "ALTERNATE_TIME_OFFSET_PROPERTIES", TLV_ALTERNATE_TIME_OFFSET_PROPERTIES, 
not_supported },
+{ "MASTER_ONLY", TLV_MASTER_ONLY, do_get_action },
{ "TRANSPARENT_CLOCK_DEFAULT_DATA_SET", 
TLV_TRANSPARENT_CLOCK_DEFAULT_DATA_SET, not_supported },
{ "PRIMARY_DOMAIN", TLV_PRIMARY_DOMAIN, not_supported },
{ "TIME_STATUS_NP", TLV_TIME_STATUS_NP, do_get_action },
@@ -510,6 +511,7 @@ static int pmc_tlv_datalen(struct pmc *pmc, int id)
case TLV_CLOCK_ACCURACY:
case TLV_TRACEABILITY_PROPERTIES:
case TLV_TIMESCALE_PROPERTIES:
+case TLV_MASTER_ONLY:
len += sizeof(struct management_tlv_datum);
break;
case TLV_TIME_STATUS_NP:
diff --git a/port.c b/port.c
index 10bb9e1..250d46d 100644
--- a/port.c
+++ b/port.c
@@ -924,6 +924,11 @@ static int port_management_fill_response(struct port 
*target,
mtd->val = target->versionNumber;
datalen = sizeof(*mtd);
break;
+case TLV_MASTER_ONLY:
+mtd = (struct management_tlv_datum *) tlv->data;
+mtd->val = target->master_only;
+datalen = sizeof(*mtd);
+break;
case TLV_DELAY_MECHANISM:
mtd = (struct management_tlv_datum *) tlv->data;
if (target->delayMechanism)
@@ -2898,6 +2903,7 @@ int port_manage(struct port *p, struct port *ingress, 
struct ptp_message *msg)
case TLV_UNICAST_MASTER_MAX_TABLE_SIZE:
case TLV_ACCEPTABLE_MASTER_TABLE_ENABLED:
case TLV_ALTERNATE_MASTER:
+case TLV_MASTER_ONLY:
case TLV_TRANSPARENT_CLOCK_PORT_DATA_SET:
case TLV_DELAY_MECHANISM:
case TLV_LOG_MIN_PDELAY_REQ_IN

Re: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized variable in nmea_scan_rmc

[Geva, Erez]

I think you can mention you are talking on UTC (Every one know UTC).

May be something like: 
"As UTC do not use daylight savings time and with accords to POSIX, disable the 
use of daylight savings by setting tm_isdst to 0".

Feel free to find a better syntax.

Or just copy the 2 lines from the POSIX (2004 Edition)
https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html
"A positive or 0 value for tm_isdst shall cause mktime() to presume initially 
that Daylight Savings Time, respectively, is or is not in effect for the 
specified time.
 A negative value for tm_isdst shall cause mktime() to attempt to determine 
whether Daylight Savings Time is in effect for the specified time."

Are you sure it was added in POSIX 2017?
I do not think you need to be that precise which version of POSIX you use, they 
usually do not change much. Only enhance functionality or improve description.

Last thought:
We are software engineers, not poets. Do not be hard on yourself.

Just use something short, clear that describe the problem and the fix.
A message that if you read it in 2 years from now, you understand what was it.

Erez

-Original Message-
From: Lars Munch  
Sent: Friday, 14 May 2021 19:30
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized variable in 
nmea_scan_rmc

So how about the following simple explanation?

According to POSIX.1-2017 tm_isdst must be set to 0 to indicate that Daylight 
Savings Time is not in effect for the specified time.



On Fri, May 14, 2021 at 6:28 PM Geva, Erez  wrote:
>
> One of my hardest bug was one a single bit.
> Do not measure bugs by code. Measure by complexity.
>
> Erez
>
> -Original Message-
> From: Lars Munch 
> Sent: Friday, 14 May 2021 18:14
> To: Geva, Erez (ext) (DI PA DCP R 3) 
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized 
> variable in nmea_scan_rmc
>
> So much work for a one-liner. I see If I can come up with a better 
> explanation.
>
> On Fri, May 14, 2021 at 4:34 PM Geva, Erez  wrote:
> >
> > Hi,
> >
> >
> >
> > I think it is better to use a short explanation how does mktime() use the 
> > tm_isdst flag, and why should it be set to 0.
> >
> > For me the problem is that we did not comply with proper use of mktime().
> >
> > Fixing glibc only revealed the bug in linuxptp.
> >
> > So we fix linuxptp, not trying to comply with a specific glibc!
> >
> >
> >
> > The choice of libc is up to the user, as long as it comply to the standards 
> > (ISO C or POSIX).
> >
> > I do not see the purpose of links to bugs in glibc.
> >
> > It is also does not helps the Developers to understand, why do we need the 
> > patch (which we do need).
> >
> >
> >
> > We are a source project, not a binary one
> >
> >
> >
> > Erez
> >
> >
> >
> > -Original Message-
> > From: Lars Munch 
> > Sent: Friday, 14 May 2021 13:34
> > To: linuxptp-devel@lists.sourceforge.net
> > Subject: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized 
> > variable in nmea_scan_rmc
> >
> >
> >
> > tm_isdst needs to be initialized to make sure mktime does not fail 
> > on recent versions of glibc
> >
> >
> >
> > See:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu
> > gzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1653340data=04%7C01%7Ce
> > rez.geva.ext%40siemens.com%7C9d2a2f4353c0403194bc08d916fdfdd6%7C38ae
> > 3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637566103157490221%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C3000sdata=BkgCRqVecfkCb4ug8zYUpNz%2By6Lum%2FIm4y
> > ZiZj8Hsw4%3Dreserved=0
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fso
> > urceware.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D24630data=04%7C01
> > %7Cerez.geva.ext%40siemens.com%7C9d2a2f4353c0403194bc08d916fdfdd6%7C
> > 38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637566103157500214%7CUnkn
> > own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> > wiLCJXVCI6Mn0%3D%7C3000sdata=%2FFscYQHQqnvekRr%2Fkmf2H4FL96HsT2
> > EbDqEF%2F2f1qHw%3Dreserved=0
> >
> >
> >
> > Signed-off-by: Lars Munch 
> >
> > ---
> >
> > nmea.c | 1 +
> >
> > 1 file changed, 1 insertion(+)
> >
> >
> >
> > diff --git a/nmea.c b/nmea.c
> >
> > index dc865d0..44c7c01 100644
> >
> > --- a/nmea.c
> >
>

Re: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized variable in nmea_scan_rmc

[Geva, Erez]

One of my hardest bug was one a single bit.
Do not measure bugs by code. Measure by complexity.

Erez

-Original Message-
From: Lars Munch  
Sent: Friday, 14 May 2021 18:14
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized variable in 
nmea_scan_rmc

So much work for a one-liner. I see If I can come up with a better explanation.

On Fri, May 14, 2021 at 4:34 PM Geva, Erez  wrote:
>
> Hi,
>
>
>
> I think it is better to use a short explanation how does mktime() use the 
> tm_isdst flag, and why should it be set to 0.
>
> For me the problem is that we did not comply with proper use of mktime().
>
> Fixing glibc only revealed the bug in linuxptp.
>
> So we fix linuxptp, not trying to comply with a specific glibc!
>
>
>
> The choice of libc is up to the user, as long as it comply to the standards 
> (ISO C or POSIX).
>
> I do not see the purpose of links to bugs in glibc.
>
> It is also does not helps the Developers to understand, why do we need the 
> patch (which we do need).
>
>
>
> We are a source project, not a binary one
>
>
>
> Erez
>
>
>
> -Original Message-
> From: Lars Munch 
> Sent: Friday, 14 May 2021 13:34
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized variable in 
> nmea_scan_rmc
>
>
>
> tm_isdst needs to be initialized to make sure mktime does not fail on recent 
> versions of glibc
>
>
>
> See:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1653340data=04%7C01%7Cerez.geva.ext%40siemens.com%7Cbb3c26d6fe6243c5653c08d916f35332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637566057003345547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BiIYzGcoTO%2FoSXwswIGKV%2B%2F1%2B%2FJ%2FTeNy0YmbS5vFMAo%3Dreserved=0
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D24630data=04%7C01%7Cerez.geva.ext%40siemens.com%7Cbb3c26d6fe6243c5653c08d916f35332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637566057003345547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Z6FYtLeYtUpCZ%2B5zuv%2FBA8gLjTCns%2FtIU30UnYcytmE%3Dreserved=0
>
>
>
> Signed-off-by: Lars Munch 
>
> ---
>
> nmea.c | 1 +
>
> 1 file changed, 1 insertion(+)
>
>
>
> diff --git a/nmea.c b/nmea.c
>
> index dc865d0..44c7c01 100644
>
> --- a/nmea.c
>
> +++ b/nmea.c
>
> @@ -157,6 +157,7 @@ static int nmea_scan_rmc(struct nmea_parser *np, struct 
> nmea_rmc *result)
>
>}
>
>tm.tm_year += 100;
>
>tm.tm_mon--;
>
> + tm.tm_isdst = 0;
>
>result->ts.tv_sec = mktime();
>
>result->ts.tv_nsec = msec * 100UL;
>
>result->fix_valid = status == 'A' ? true : false;
>
> --
>
> 2.25.1
>
>
>
>
>
>
>
> ___
>
> Linuxptp-devel mailing list
>
> Linuxptp-devel@lists.sourceforge.net
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Cbb3c26d6fe6243c5653c08d916f35332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637566057003345547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=W%2FcRIT%2FxVV%2BoClCJ%2Fpw1nOZFAwfC0rCsMu9oJra3O9g%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 2/4] ts2phc: Close socket on peer shutdown

[Geva, Erez]

Yes.

-Original Message-
From: Lars Munch  
Sent: Friday, 14 May 2021 18:20
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 2/4] ts2phc: Close socket on peer shutdown

On Fri, May 14, 2021 at 4:24 PM Geva, Erez  wrote:
>
> Make sense to handle 0, end of file.
> But as it is NOT an error, perhaps it should use a proper pr_info().

So something like this?

cnt = read(pfd.fd, input, sizeof(input)); if (cnt <= 0) {
if (cnt == 0)
pr_info("disconnected from remote nmea source");
else
pr_err("failed to read from nmea source");
close(pfd.fd);
pfd.fd = -1;

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized variable in nmea_scan_rmc

[Geva, Erez]

Hi,



I think it is better to use a short explanation how does mktime() use the 
tm_isdst flag, and why should it be set to 0.

For me the problem is that we did not comply with proper use of mktime().

Fixing glibc only revealed the bug in linuxptp.

So we fix linuxptp, not trying to comply with a specific glibc!



The choice of libc is up to the user, as long as it comply to the standards 
(ISO C or POSIX).

I do not see the purpose of links to bugs in glibc.

It is also does not helps the Developers to understand, why do we need the 
patch (which we do need).



We are a source project, not a binary one 



Erez



-Original Message-
From: Lars Munch 
Sent: Friday, 14 May 2021 13:34
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH 1/4] ts2phc: Fix uninitialized variable in 
nmea_scan_rmc



tm_isdst needs to be initialized to make sure mktime does not fail on recent 
versions of glibc



See:

https://bugzilla.redhat.com/show_bug.cgi?id=1653340

https://sourceware.org/bugzilla/show_bug.cgi?id=24630



Signed-off-by: Lars Munch mailto:l...@segv.dk>>

---

nmea.c | 1 +

1 file changed, 1 insertion(+)



diff --git a/nmea.c b/nmea.c

index dc865d0..44c7c01 100644

--- a/nmea.c

+++ b/nmea.c

@@ -157,6 +157,7 @@ static int nmea_scan_rmc(struct nmea_parser *np, struct 
nmea_rmc *result)

   }

   tm.tm_year += 100;

   tm.tm_mon--;

+ tm.tm_isdst = 0;

   result->ts.tv_sec = mktime();

   result->ts.tv_nsec = msec * 100UL;

   result->fix_valid = status == 'A' ? true : false;

--

2.25.1







___

Linuxptp-devel mailing list

Linuxptp-devel@lists.sourceforge.net

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C6bd447d3aa4a436be41808d916d024c9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637565905494246406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JgJVYnL%2BvSHUfF5H9n%2FZC0N0dwSr%2Fw2flJ5QGdZ88lI%3Dreserved=0
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 4/4] ts2phc: Add serial baudrate option

[Geva, Erez]

A great idea to add baud-rate.

Just a suggestion, 
As I remember from gtkterm application.

It provide setting: port name, Baud rate, parity, bits, stop bit, and flow 
control.

What do you think of adding all of the setting?

Erez

-Original Message-
From: Lars Munch  
Sent: Friday, 14 May 2021 13:34
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH 4/4] ts2phc: Add serial baudrate option

Add serial baudrate configuration option. Default to 9600 bps.

Signed-off-by: Lars Munch 
---
 config.c |  1 +
 ts2phc.8 | 23 ---
 ts2phc_nmea_master.c | 10 +-
 3 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/config.c b/config.c
index 4472d3d..a42a57f 100644
--- a/config.c
+++ b/config.c
@@ -319,6 +319,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_STR("ts2phc.nmea_remote_host", ""),
GLOB_ITEM_STR("ts2phc.nmea_remote_port", ""),
GLOB_ITEM_STR("ts2phc.nmea_serialport", "/dev/ttyS0"),
+   PORT_ITEM_INT("ts2phc.nmea_baudrate", 9600, 0, INT_MAX),
PORT_ITEM_INT("ts2phc.pin_index", 0, 0, INT_MAX),
GLOB_ITEM_INT("ts2phc.pulsewidth", 5, 100, 99900),
PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu), diff --git 
a/ts2phc.8 b/ts2phc.8 index 99067c5..690c462 100644
--- a/ts2phc.8
+++ b/ts2phc.8
@@ -146,19 +146,20 @@ set to 0.0, the servo will never step the clock except on 
start.
 The default is 0.0.
 .TP
 .B ts2phc.nmea_remote_host, ts2phc.nmea_remote_port -Specifies the serial port 
character device providing ToD information -when using the "nmea" PPS signal 
source.  Note that if these two -options are both specified, then the given 
remote connection will be -used in preference to the configured serial port.
-These options default to the empty string, that is, not specified.
-.TP
-.B ts2phc.nmea_serialport
-Specifies the serial port character device providing ToD information -when 
using the "nmea" PPS signal source.  Note that if the options, 
-ts2phc.nmea_remote_host and ts2phc.nmea_remote_port, are both
+Specifies the remote host providing ToD information when using the 
+"nmea" PPS signal source.  Note that if these two options are both
 specified, then the given remote connection will be used in preference  to the 
configured serial port.
-The default is "/dev/ttyS0".
+These options default to the empty string, that is, not specified.
+.TP
+.B ts2phc.nmea_serialport, ts2phc.nmea_baudrate Specifies the serial 
+port and baudrate in bps for character device providing ToD information 
+when using the "nmea" PPS signal source. Note that if the options, 
+ts2phc.nmea_remote_host and ts2phc.nmea_remote_port, are both 
+specified, then the given remote connection will be used in preference 
+to the configured serial port.
+The default serial port is "/dev/ttyS0".
+The default baudrate is 9600 bps.
 .TP
 .B ts2phc.pulsewidth
 The expected pulse width of the external PPS signal in nanoseconds.
diff --git a/ts2phc_nmea_master.c b/ts2phc_nmea_master.c index 2fc460d..a383429 
100644
--- a/ts2phc_nmea_master.c
+++ b/ts2phc_nmea_master.c
@@ -23,7 +23,6 @@
 #include "ts2phc_nmea_master.h"
 #include "util.h"
 
-#define BAUD   9600
 #define MAX_RMC_AGE50ULL
 #define NMEA_TMO   2000 /*milliseconds*/
 
@@ -45,7 +44,7 @@ struct ts2phc_nmea_master {  };
 
 static int open_nmea_connection(const char *host, const char *port,
-   const char *serialport)
+   const char *serialport, int baud)
 {
int fd;
 
@@ -56,7 +55,7 @@ static int open_nmea_connection(const char *host, const char 
*port,
}
return fd;
}
-   fd = serial_open(serialport, BAUD, 0, 0);
+   fd = serial_open(serialport, baud, 0, 0);
if (fd == -1) {
pr_err("failed to open nmea source %s", serialport);
}
@@ -70,7 +69,7 @@ static void *monitor_nmea_status(void *arg)
char *host, input[256], *port, *ptr, *uart;
struct ts2phc_nmea_master *master = arg;
struct timespec rxtime, tmo = { 2, 0 };
-   int cnt, num, parsed;
+   int cnt, num, parsed, baud;
struct nmea_rmc rmc;
struct timex ntx;
 
@@ -81,12 +80,13 @@ static void *monitor_nmea_status(void *arg)
host = config_get_string(master->config, NULL, 
"ts2phc.nmea_remote_host");
port = config_get_string(master->config, NULL, 
"ts2phc.nmea_remote_port");
uart = config_get_string(master->config, NULL, 
"ts2phc.nmea_serialport");
+   baud = config_get_int(master->config, NULL, "ts2phc.nmea_baudrate");
memset(, 0, sizeof(ntx));
ntx.modes = ADJ_NANO;
 
while (is_running()) {
if (pfd.fd == -1) {
-   pfd.fd = open_nmea_connection(host, port, uart);
+   pfd.fd = open_nmea_connection(host, port, uart, baud);
if (pfd.fd == -1) {

Re: [Linuxptp-devel] [PATCH 2/4] ts2phc: Close socket on peer shutdown

[Geva, Erez]

Make sense to handle 0, end of file.
But as it is NOT an error, perhaps it should use a proper pr_info().

Erez

-Original Message-
From: Lars Munch  
Sent: Friday, 14 May 2021 13:34
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH 2/4] ts2phc: Close socket on peer shutdown

Read returns 0 (the traditional "end-of-file" return) when a remote peer 
performs an orderly shutdown. Hence, ts2phc needs to close the socket and try 
to establish a new connection.

Signed-off-by: Lars Munch 
---
 ts2phc_nmea_master.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts2phc_nmea_master.c b/ts2phc_nmea_master.c index b031e65..2fc460d 
100644
--- a/ts2phc_nmea_master.c
+++ b/ts2phc_nmea_master.c
@@ -115,7 +115,7 @@ static void *monitor_nmea_status(void *arg)
continue;
}
cnt = read(pfd.fd, input, sizeof(input));
-   if (cnt < 0) {
+   if (cnt <= 0) {
pr_err("failed to read from nmea source");
close(pfd.fd);
pfd.fd = -1;
--
2.25.1



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C1dac059442c145cbbf9e08d916d0a8c4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637565907704909454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RjhfkcVf7M46tr%2BrAquaCttDpc38MA7wrAWIu2yT%2FgI%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Regarding linuxPTP static analysis..

[Geva, Erez]

On 04/05/2021 10:16, Miroslav Lichvar wrote:
> On Tue, May 04, 2021 at 04:43:51PM +0900, 박웅섭 wrote:
>> 1.In the text->length=c->desc.userDescription.length part of clock.c line
>> 368, the length declared in the static_ptp_text structure is of type signed
>> int and the length declared in the text structure is unsigned int. Why did
>> you write the code like this? Assigning Signed integers to unsigned
>> integers can lead to overflow problems.
> 
> In my copy of the code the length field of the PTPText structure is
> uint8_t. It's a structure used in the network protocol.
> 

Yes, Miroslav is right. PTPText uses unsigned 8 bits as specify in IEEE 
1558.
As text length is positive or zero. Why should it be a problem?
Look on static_ptp_text_set() the length is set using strlen() which is 
possitive or zero and the maximum length is 255.

/* A static_ptp_text is like a PTPText but includes space to store the
  * text inside the struct. The text array must always be
  * null-terminated. Also tracks a maximum number of symbols. Note in
  * UTF-8, # symbols != # bytes.
  */
#define MAX_PTP_OCTETS 255

I assume static_ptp_text uses int for simlicity. But the length value is 
bound to unsigned 8 bits, 0 to 255.


>> 2. The memcpy function is vulnerable to security. Wouldn't it be correct to
>> use memcpy_s instead of memcpy function?
> 
> Isn't that a Windows-only function?
> 

No, C11
https://en.cppreference.com/w/c/string/byte/memcpy

However, the make file does not specify standard.
Perhaps some users defer C11.

Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/1] Add master only management TLV

[Geva, Erez]

On 26/04/2021 00:47, Richard Cochran wrote:
> On Thu, Apr 22, 2021 at 03:04:17PM +0200, Erez Geva wrote:
> 
>> diff --git a/pmc.c b/pmc.c
>> index a767c8a..00d6014 100644
>> --- a/pmc.c
>> +++ b/pmc.c
>> @@ -335,6 +335,11 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
>>  fprintf(fp, "TIMESCALE_PROPERTIES "
>>  IFMT "ptpTimescale %d", mtd->val & PTP_TIMESCALE ? 1 : 
>> 0);
>>  break;
>> +case TLV_MASTER_ONLY:
>> +mtd = (struct management_tlv_datum *) mgt->data;
>> +fprintf(fp, "MASTER_ONLY "
>> +IFMT "masterOnly %d", mtd->val);
>> +break;
> 
> These switch/case tables are in numeric order.

I was wonder what was the proper order.
On configuration we use alephbet order.
I tried my luck on that.

I will order and send version 2.
Erez

> 
> Could you please put this entry between TLV_VERSION_NUMBER (0x200C)
> and TLV_DELAY_MECHANISM (0x6000)?
> 
> Ditto for the other tables.
> 
>>  case TLV_TIME_STATUS_NP:
>>  tsn = (struct time_status_np *) mgt->data;
>>  fprintf(fp, "TIME_STATUS_NP "
> 
> Thanks,
> Richard
> 


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 0/1] Add master only management TLV

[Geva, Erez]

You may add set action if you wish.
You may combine my get master only patch with it.

You need to verify the ptp4l can dynamically change the master only flag.

As the 'slave only' flag does not allow set, I skip it for now.

Only priorities 1 and  2 can be changed at the moment.

However as the 'master only' is a port action and not clock action as 'slave 
only', it might be easier to implement and verify.

Erez

-Original Message-
From: Luigi 'Comio' Mantellini  
Sent: Thursday, 22 April 2021 15:25
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 0/1] Add master only management TLV

Why do you also introduce the set action?
This is a snip from port_management_set:

static int port_management_set(struct port *target,
   struct port *ingress, int id,
   struct ptp_message *req) { ...
switch (id) {
case TLV_MASTERONLY:
mtd = (struct management_tlv_datum *) tlv->data;
master_only = !!mtd->val;
respond = 1;

if (!!target->master_only != master_only) {
if (target->bmca == BMCA_NOOP && target->transport != TRANS_UDS) {
if (master_only) {
target->state_machine = designated_master_fsm;
} else if (clock_slave_only(target->clock)) {
target->state_machine = designated_slave_fsm;
} else {
pr_err("Please enable at least one of masterOnly or 
slaveOnly when BMCA == noop.\n");
respond = 0;
}
} else {
target->state_machine =
clock_slave_only(target->clock) ? ptp_slave_fsm : ptp_fsm;
}
if (respond) {
target->master_only = master_only;
port_dispatch(target, EV_INITIALIZE, 0);
}
}
break;
...
}


ciao

luigi

Il giorno gio 22 apr 2021 alle ore 15:06 Erez Geva  
ha scritto:
>
> As we support the new master only flag.
> Add the master only TLV to pmc tool.
>
> Erez Geva (1):
>   Add master only management TLV
>
>  pmc.c| 5 +
>  pmc_common.c | 2 ++
>  port.c   | 6 ++
>  tlv.h| 1 +
>  4 files changed, 14 insertions(+)
>
> --
> 2.20.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01
> %7Cerez.geva.ext%40siemens.com%7C2a01d35f5d5442723c6408d90592150e%7C38
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546947238491423%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C1000sdata=Oj0HTnrQYZ%2Bz7f8ZC8CqdW2hlj%2Frd8gHQuQNeq
> rJKiM%3Dreserved=0



--
Luigi 'Comio' Mantellini
My Professional Profile

"UNIX is very simple, it just needs a genius to understand its simplicity." 
[cit.]


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] pmc is not giving any output without using -d option

[Geva, Erez]

No,

You must use a proper domain number that match the PTP domain.

You can fetch it from

  1.  A configuration file with domainNumber
  2.  The – domainNumber option
  3.  The -d

The default is 0.

Erez


From: Ruby Bhati 
Sent: Thursday, 22 April 2021 13:40
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] pmc is not giving any output without using -d option

Hi

I am running ptp4l with G.8275.2 profile.
But when i am running pmc without -d option its not showing any output
]# pmc -u -d 0  'GET DOMAIN'
sending: GET DOMAIN

Its working only when I am running with -d option as
# pmc -u -d 0 -d 44 'GET DOMAIN'
sending: GET DOMAIN
a0369f.fffe.874100-0 seq 0 RESPONSE MANAGEMENT DOMAIN
domainNumber 44

I want to run pmc without -d option. Is there any way to run without giving -d 
option?

Thanks,
Ruby Bhati
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v4] Rework twoStepFlag in order to handle one step on port basis.

[Geva, Erez]

On 22/04/2021 09:18, Luigi 'Comio' Mantellini wrote:
> With this patch we introduce the twoStepFlag evaluation at port level.
> 
> ---
>   config.c |  2 +-
>   port.c   | 35 ++-
>   ptp4l.8  |  9 -
>   3 files changed, 39 insertions(+), 7 deletions(-)
> 
> diff --git a/config.c b/config.c
> index 4472d3d..f0e1e07 100644
> --- a/config.c
> +++ b/config.c
> @@ -322,7 +322,7 @@ struct config_item config_tab[] = {
>   PORT_ITEM_INT("ts2phc.pin_index", 0, 0, INT_MAX),
>   GLOB_ITEM_INT("ts2phc.pulsewidth", 5, 100, 99900),
>   PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu),
> - GLOB_ITEM_INT("twoStepFlag", 1, 0, 1),
> + PORT_ITEM_INT("twoStepFlag", 1, 0, 1),
>   GLOB_ITEM_INT("tx_timestamp_timeout", 1, 1, INT_MAX),
>   PORT_ITEM_INT("udp_ttl", 1, 1, 255),
>   PORT_ITEM_INT("udp6_scope", 0x0E, 0x00, 0x0F),
> diff --git a/port.c b/port.c
> index 10bb9e1..b700ff3 100644
> --- a/port.c
> +++ b/port.c
> @@ -3028,6 +3028,37 @@ err:
>   msg_put(msg);
>   }
>   
> +static enum timestamp_type port_harmonize_onestep(struct port *p, enum 
> timestamp_type timestamping, int twoStepFlag)
> +{
> + switch (timestamping) {
> + case TS_SOFTWARE:
> + case TS_LEGACY_HW:
> + if (!twoStepFlag) {
> + pr_err("%s: one step is only possible "
> +"with hardware time stamping", p->log_name);
> + return timestamping;
> + }
> + break;
> + case TS_HARDWARE:
> + if (!twoStepFlag) {
> + pr_debug("%s: upgrading to one step time stamping "
> +  "in order to match the port.twoStepFlag", 
> p->log_name);
> + return TS_ONESTEP;
> + }
> + break;
> + case TS_ONESTEP:
> + case TS_P2P1STEP:
> + if (twoStepFlag) {
> + pr_debug("%s: degrading to two step time stamping, "
> +  "in order to match the port.twoStepFlag", 
> p->log_name);
> + return TS_HARDWARE;
> + }
> + break;
> + }
> +
> + return timestamping;
> +}
> +

As user do configure the time_stamping, I think that changing of timestamping 
require a flag that permit it, or alternatively generate error.
I think that automatic probing of timestamping without proper configuration may 
confuse users.

We should allow time_stamping per port.

Just because I choose one step or two steps, does not guarantee I like the 
resulting timestamping.
In addition, the driver might not support the probed timestamping.

I do like probing. I just think it requires a flag that the user can decide to 
use it or not.

>   struct port *port_open(const char *phc_device,
>  int phc_index,
>  enum timestamp_type timestamping,
> @@ -3039,6 +3070,7 @@ struct port *port_open(const char *phc_device,
>   struct config *cfg = clock_config(clock);
>   struct port *p = malloc(sizeof(*p));
>   int i;
> + int twoStepFlag;
>   
>   if (!p) {
>   return NULL;
> @@ -3134,7 +3166,8 @@ struct port *port_open(const char *phc_device,
>   p->tx_timestamp_offset <<= 16;
>   p->link_status = LINK_UP;
>   p->clock = clock;
> - p->timestamping = timestamping;
> + twoStepFlag = config_get_int(cfg, p->name, "twoStepFlag");
> + p->timestamping = port_harmonize_onestep(p, timestamping, twoStepFlag);
>   p->portIdentity.clockIdentity = clock_identity(clock);
>   p->portIdentity.portNumber = number;
>   p->state = PS_INITIALIZING;
> diff --git a/ptp4l.8 b/ptp4l.8
> index fe9e150..bea4dae 100644
> --- a/ptp4l.8
> +++ b/ptp4l.8
> @@ -143,6 +143,10 @@ See UNICAST DISCOVERY OPTIONS, below.
>   .SH PORT OPTIONS
>   
>   .TP
> +.B twoStepFlag
> +Enable two-step mode for sync messages. One-step mode can be used only with
> +hardware time stamping.
> +The default is 1 (enabled).
>   .B delayAsymmetry
>   The time difference in nanoseconds of the transmit and receive
>   paths. This value should be positive when the server-to-client
> @@ -378,11 +382,6 @@ to the same subnet.
>   
>   .SH PROGRAM AND CLOCK OPTIONS
>   
> -.TP
> -.B twoStepFlag
> -Enable two-step mode for sync messages. One-step mode can be used only with
> -hardware time stamping.
> -The default is 1 (enabled).
>   .TP
>   .B clientOnly
>   The local clock is a client-only clock if enabled. The default is 0 
> (disabled).
> 

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc

[Geva, Erez]

That make sense.

nmea uses UTC.
UTC does not use daylight saving.
So we should set tm_isdst to zero or negative.
I think zero is better as UTC should not use daylight saving.

Sound like a good ground  for a patch

Erez

From: Lars Munch 
Sent: Wednesday, 21 April 2021 15:01
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: Richard Cochran ; 
linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in 
nmea_scan_rmc

My Arch system does indeed have daylight saving set, but nmea.c forces the TZ 
to UTC where a positive value of tm_isdst does not make sense.

On Wed, Apr 21, 2021 at 1:51 PM Geva, Erez 
mailto:erez.geva@siemens.com>> wrote:
Looks like the man page is not accurate.
Looking in 
https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Ffunctions%2Fmktime.html=04%7C01%7Cerez.geva.ext%40siemens.com%7Cda8de2bf9a9b49318d0b08d904c59709%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546069391715822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=%2F7zfn0tJyfjfQRFOJTRUMa4pxhfSeWh%2FR4ikHOK%2BPeU%3D=0>

A positive or 0 value for tm_isdst shall cause mktime() to presume initially 
that Daylight Savings Time, respectively, is or is not in effect for the 
specified time.
A negative value for tm_isdst shall cause mktime() to attempt to determine 
whether Daylight Savings Time is in effect for the specified time.

My guess is that on Lars new system the daylight is NOT set, then the mktime 
fail to determine the Daylight Savings and return error (-1).

Erez

-Original Message-
From: Richard Cochran 
mailto:richardcoch...@gmail.com>>
Sent: Tuesday, 20 April 2021 16:05
To: Lars Munch mailto:l...@segv.dk>>
Cc: 
linuxptp-devel@lists.sourceforge.net<mailto:linuxptp-devel@lists.sourceforge.net>
Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in 
nmea_scan_rmc

On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> tm_isdst needs to be initialized to make sure mktime does not fail or
> calculates the wrong time.

No, take a look at the mktime(3) man page.  There you will read the following.

   The  mktime() function modifies the fields of the tm structure as fol‐
   lows: tm_wday and tm_yday are set to values determined from  the  con‐
   tents  of  the  other  fields;  if structure members are outside their
   valid interval, they will be normalized (so that, for example, 40  Oc‐
   tober  is changed into 9 November); tm_isdst is set (regardless of its
   initial value) to a positive value or to 0, respectively, to  indicate
   whether DST is or is not in effect at the specified time.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C6b9d88bf27584b2d9eb508d9040556d6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637545243247255579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wHxP0yERXKP6unOP1ZPV%2F87BVduutafEUIOl8jH%2Bud4%3Dreserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel=04%7C01%7Cerez.geva.ext%40siemens.com%7Cda8de2bf9a9b49318d0b08d904c59709%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546069391725818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=fAigqGaS7r%2FSyDhqtebI4bmYmfHq0Mp0evVhlko7M9c%3D=0>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Propagate management messages from UNIX layer to PTP network

[Geva, Erez]

Thanks,

Forgot about it.

Erez

From: Luigi 'Comio' Mantellini 
Sent: Wednesday, 21 April 2021 18:10
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Propagate management messages from UNIX layer to 
PTP network

You should specify 0 (ZERO) boundary hops:

pmc -b 0 -u -f /blabla/ptp4l.conf "GET CURRENT_DATA_SET"

caio

luigi

Il giorno mer 21 apr 2021 alle ore 17:37 Geva, Erez 
mailto:erez.geva@siemens.com>> ha scritto:
Hi,

We notice that when sending Management messages using UNIX socket ('pmc -u').
ptp4l propagate the message to the PTP domain network.

We try to set the target using local clock ID.
# pmc -u -f /etc/linuxptp/ptp4l.conf 'target xx.fffe.xx-1' 'get 
CLOCK_DESCRIPTION'

Now, we get reply to the lock clock only.
But yet we see a GET request message on the PTP domain network.
Why does the ptp4l propagate the message?

Same with CURRENT_DATA_SET.
Management IDs for PTP port or PTP instance (clock) seems to behave the same in 
this respect.


With best regards,
Erez Geva

AURELLY TECHNOLOGIES GmbH
External service provider at Siemens AG
Digital Industries
Process Automation
Software House Nbg
DI PA DCP R 3
Gleiwitzer Str. 555
90475 Nuremberg, Germany
mailto:erez.geva@siemens.com
[cid:image001.jpg@01D736DA.69E0A760]
www.aurelly.com<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.aurelly.com%2F=04%7C01%7Cerez.geva.ext%40siemens.com%7C17bfac7f95b671aa08d904dff407%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546182182321555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=3NmBboR1enlyXc3ASrjN7Yig9iwREAAZraCnn9rN2s4%3D=0>
CEO: Jens Stötzner, company's place of business: Nürnberg,
VAT identification: DE 255071685, Commercial register No.: HRB: 15550
[cid:image002.png@01D736DA.69E0A760] Please consider the environment before 
printing this email
Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel=04%7C01%7Cerez.geva.ext%40siemens.com%7C17bfac7f95b671aa08d904dff407%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546182182331556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=NOMHZKRHOqRzOA9Jkox7z%2BkR2D7pfXmfPrA61R%2FXTdo%3D=0>


--
Luigi 'Comio' Mantellini
[cid:image003.gif@01D736DA.69E0A760]My Professional 
Profile<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fcomio=04%7C01%7Cerez.geva.ext%40siemens.com%7C17bfac7f95b671aa08d904dff407%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546182182331556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=109ELXMa56%2B%2FrwiLJa%2FICn9O1VnpfcaaBSDAFB%2FjaTc%3D=0>

"UNIX is very simple, it just needs a genius to understand its simplicity." 
[cit.]

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] Propagate management messages from UNIX layer to PTP network

[Geva, Erez]

Hi,

We notice that when sending Management messages using UNIX socket ('pmc -u').
ptp4l propagate the message to the PTP domain network.

We try to set the target using local clock ID.
# pmc -u -f /etc/linuxptp/ptp4l.conf 'target xx.fffe.xx-1' 'get 
CLOCK_DESCRIPTION'

Now, we get reply to the lock clock only.
But yet we see a GET request message on the PTP domain network.
Why does the ptp4l propagate the message?

Same with CURRENT_DATA_SET.
Management IDs for PTP port or PTP instance (clock) seems to behave the same in 
this respect.


With best regards,
Erez Geva

AURELLY TECHNOLOGIES GmbH
External service provider at Siemens AG
Digital Industries
Process Automation
Software House Nbg
DI PA DCP R 3
Gleiwitzer Str. 555
90475 Nuremberg, Germany
mailto:erez.geva@siemens.com
[cid:image005.jpg@01D736D4.9D0E84A0]
www.aurelly.com
CEO: Jens Stötzner, company's place of business: Nürnberg,
VAT identification: DE 255071685, Commercial register No.: HRB: 15550
[cid:image006.png@01D736D4.9D0E84A0] Please consider the environment before 
printing this email
Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc

[Geva, Erez]

Looks like you daylight time is broken on Arch Linux and Ubuntu 20.04.
-1 is error by mktime.

Why do you think it is related here?

Fix you daylight time setting in your system and open a bug report in the 
relevant packages/systems.

Erez


From: Lars Munch 
Sent: Tuesday, 20 April 2021 22:24
To: Michael Galassi 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in 
nmea_scan_rmc

Sorry for the noise. In my previous example I had by accident pasted a huge 
number into the example. New example:

#include 
#include 
#include 

int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
setenv("TZ", "UTC", 1);
t.tm_isdst = 1;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}

Gives:
-1
1618956512
1618956512

This is on my up-to-date Arch Linux and Ubuntu 20.04.
On my Ubuntu 18.04 it's fine.


On Tue, Apr 20, 2021 at 5:55 PM Lars Munch mailto:l...@segv.dk>> 
wrote:
Ok, so mktime is forced to return in time UTC time scale earlier in the code:

#include 
#include 
#include 

int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
setenv("TZ", "UTC", 1);
t.tm_isdst = 41;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}

1618941220
1618941220
1618941220

So my problem might come from the fact that I do not have any timezone database 
on my system.




On Tue, Apr 20, 2021 at 5:30 PM Lars Munch mailto:l...@segv.dk>> 
wrote:
Indeed, any positive random number in tm.tm_isdst will set DST in effect it 
seems.

On my stripped down ARM system with no timezone information, it will simply 
return -1.

On Tue, Apr 20, 2021 at 4:26 PM Michael Galassi 
mailto:mich...@galassi.us>> wrote:
Somewhere lies a bug.  The following code snippet:
#include 
#include 
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
t.tm_isdst = 1;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
Yields:
1618928503
1618932103
1618932103
This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.

-michael

On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran 
mailto:richardcoch...@gmail.com>> wrote:
On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> tm_isdst needs to be initialized to make sure mktime does not fail
> or calculates the wrong time.

No, take a look at the mktime(3) man page.  There you will read the
following.

   The  mktime() function modifies the fields of the tm structure as fol‐
   lows: tm_wday and tm_yday are set to values determined from  the  con‐
   tents  of  the  other  fields;  if structure members are outside their
   valid interval, they will be normalized (so that, for example, 40  Oc‐
   tober  is changed into 9 November); tm_isdst is set (regardless of its
   initial value) to a positive value or to 0, respectively, to  indicate
   whether DST is or is not in effect at the specified time.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc

[Geva, Erez]

Looks like the man page is not accurate.
Looking in https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html

A positive or 0 value for tm_isdst shall cause mktime() to presume initially 
that Daylight Savings Time, respectively, is or is not in effect for the 
specified time. 
A negative value for tm_isdst shall cause mktime() to attempt to determine 
whether Daylight Savings Time is in effect for the specified time.

My guess is that on Lars new system the daylight is NOT set, then the mktime 
fail to determine the Daylight Savings and return error (-1).

Erez

-Original Message-
From: Richard Cochran  
Sent: Tuesday, 20 April 2021 16:05
To: Lars Munch 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in 
nmea_scan_rmc

On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> tm_isdst needs to be initialized to make sure mktime does not fail or 
> calculates the wrong time.

No, take a look at the mktime(3) man page.  There you will read the following.

   The  mktime() function modifies the fields of the tm structure as fol‐
   lows: tm_wday and tm_yday are set to values determined from  the  con‐
   tents  of  the  other  fields;  if structure members are outside their
   valid interval, they will be normalized (so that, for example, 40  Oc‐
   tober  is changed into 9 November); tm_isdst is set (regardless of its
   initial value) to a positive value or to 0, respectively, to  indicate
   whether DST is or is not in effect at the specified time.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C6b9d88bf27584b2d9eb508d9040556d6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637545243247255579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wHxP0yERXKP6unOP1ZPV%2F87BVduutafEUIOl8jH%2Bud4%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Get servo state from PMC

[Geva, Erez]

The only state I know is “port state”, that you can see with

PORT_DATA_SET or PORT_PROPERTIES_NP

I do not see any TLV for “clock state”.

The clock state is fetched with clock_synchronize()

See port_synchronize() in port.c

Erez


From: Ruby Bhati 
Sent: Thursday, 15 April 2021 13:10
To: Geva, Erez (ext) (DI PA DCP R 3) 
Subject: Re: [Linuxptp-devel] Get servo state from PMC

Hi Erez,

Actually i can see in ptp4l, there are four servo states as
SERVO_UNLOCKED
SERVO_JUMP
SERVO_LOCKED
SERVO_LOCKED_STABLE

In port.c, there is function clock_servo_state to get the current servo state.

Is there any way from pmc also I can read this servo state

Thanks,
Ruby Bhati

On Thu, Apr 15, 2021 at 4:31 PM Geva, Erez 
mailto:erez.geva@siemens.com>> wrote:
Hi,

Can you be more explicit?
What do you mean by “servo state”?
What state you want to query?

Erez

From: Ruby Bhati mailto:rubybhati1...@gmail.com>>
Sent: Thursday, 15 April 2021 12:49
To: 
linuxptp-devel@lists.sourceforge.net<mailto:linuxptp-devel@lists.sourceforge.net>
Subject: Re: [Linuxptp-devel] Get servo state from PMC

Hi,

Updating the Qus.
Is there any way to get the current running servo state via pmc?



On Thu, Apr 15, 2021 at 4:13 PM Ruby Bhati 
mailto:rubybhati1...@gmail.com>> wrote:
Hi

Is there any way to get the current running state via pmc?

Thanks,
Ruby Bhati
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Get servo state from PMC

[Geva, Erez]

Hi,

Can you be more explicit?
What do you mean by “servo state”?
What state you want to query?

Erez

From: Ruby Bhati 
Sent: Thursday, 15 April 2021 12:49
To: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Get servo state from PMC

Hi,

Updating the Qus.
Is there any way to get the current running servo state via pmc?



On Thu, Apr 15, 2021 at 4:13 PM Ruby Bhati 
mailto:rubybhati1...@gmail.com>> wrote:
Hi

Is there any way to get the current running state via pmc?

Thanks,
Ruby Bhati
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 0/1] Fix SLAVE_ONLY TLV

[Geva, Erez]

On 30/03/2021 09:22, Michael Walle wrote:
> Hi Erez,
> 
> Am 2021-03-30 01:26, schrieb Erez Geva:
>> Confirm to IEEE 1588 SLAVE_ONLY management TLB
>>
>> Erez Geva (1):
>>   Fix SLAVE_ONLY TLV
> 
> I guess this is the new patch version? This should be reflected in the
> Subject line, e.g. "[PATCH v2] ..". See also the -v parameter of > 
> git-send-email.

You mean "git format-patch -v2 --cover-letter"

Thanks for the tip.

-Erez

> 
> Preferably with a short version history.
> 
> -michael

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/1] Fix SLAVE_ONLY TLV

[Geva, Erez]

On 22/03/2021 16:31, Erez Geva wrote:
> According to IEEE 1588 The slave only flag in the SLAVE_ONLY TLV
>   is bit 0 and not bit 1 as in the DEFAULT_DATA_SET TLV.
> 
> To retain backward compatibility and as bit 1 in SLAVE_ONLY
>   is not used anyway. Read and set both bits with same value.
> ---
>   clock.c | 2 +-
>   pmc.c   | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/clock.c b/clock.c
> index f88df58..410a5df 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -404,7 +404,7 @@ static int clock_management_fill_response(struct clock 
> *c, struct port *p,
>   break;
>   case TLV_SLAVE_ONLY:
>   mtd = (struct management_tlv_datum *) tlv->data;
> - mtd->val = c->dds.flags & DDS_SLAVE_ONLY;
> + mtd->val = c->dds.flags & DDS_SLAVE_ONLY ? 0x3 : 0;
>   datalen = sizeof(*mtd);
>   break;
>   case TLV_CLOCK_ACCURACY:
> diff --git a/pmc.c b/pmc.c
> index 1e569b5..680c244 100644
> --- a/pmc.c
> +++ b/pmc.c
> @@ -315,7 +315,7 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
>   case TLV_SLAVE_ONLY:
>   mtd = (struct management_tlv_datum *) mgt->data;
>   fprintf(fp, "SLAVE_ONLY "
> - IFMT "slaveOnly %d", mtd->val & DDS_SLAVE_ONLY ? 1 : 0);
> + IFMT "slaveOnly %d", mtd->val > 0 ? 1 : 0);

On a second thought, we should and bitwise here too:
IFMT "slaveOnly %d", (mtd->val & 0x3) > 0 ? 1 : 0);

>   break;
>   case TLV_CLOCK_ACCURACY:
>   mtd = (struct management_tlv_datum *) mgt->data;
> 

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] SyncE support

[Geva, Erez]

On 18/03/2021 11:57, Frantisek Rysanek wrote:
> On 17 Mar 2021 at 18:01, Miroslav Lichvar wrote:
> 
> [on PCI-e PTM]
>>
>> The switches are supposed to work like NTP server and client at the
>> same time (boundary clock in the PTP terminology), so all PCIe links
>> have hardware timestamping on both ends.
>>
>> BTW, at least in theory, a network using boundary clocks should
>> perform better than a similar network using transparent clocks,
>> assuming the servos are well configured and the sync interval is short
>> enough to minimize the time errors in the chain. Divide and conquer
>> :). I think transparent clocks are meant to be the simpler and cheaper
>> variant.
>>
> 
> I recall some history around the debate on BC vs TC.
>  From my subjective perspective anyway.
> 
> PTP v1 used to be all about BC's.
> Then in 2008 came PTP v2, and suddenly TC was all the rage, the only
> right way for PTP-capable switches to function from now on.
> Except that, as years were passing by, PTP-aware switches did not
> exactly spawn in flocks everywhere. Rather, they remained few and far
> between. And, especially the telco industry would've loved to deploy
> PTP, but there was no way for their active elements in the networks
> to support PTP (to turn them all into TC's). So after some years
> since 2008, suddenly the Telecom Profiles came out, and were all
> about BC's and partial on-path support (or rather: no on-path
> support). The TC idea has a stronghold in the electric power
> industry, at least on paper - practical compatibility of
> implementations remains a fun topic, to use a euphemism, especially
> where multi-vendor heterogeneous setups are attempted... this is
> where I have a limited by ongoing practical experience :-)
> 
> On the topic of BC's and their apparent renaissance, I've had a brief
> debate about this with someone from Meinberg, and the message was:
> BC's or TC's, either of them works, if done properly. Reportedly
> there have been tests of up to 16 BC's in a cascade, and if the local
> oscillators were stable, and the feedback loops were tuned
> appropriately, the cascade just worked, there were no ill effects
> (excessive residual wander at the tail end, or whatever). So it's all
> down to oscillator quality and feedback loop parameters = control
> theory and the respective math. Laplace, Nyquist, whatever...
> 
> As for TC's, from my practical observations (and maybe a bit of
> gossip), switch chipset vendors have a hard time implementing the
> on-the-fly corrections in the hardware. Something that would work
> "out of the box" for the switch box makers. And because the silicon
> vendors struggle, some switch box vendors implement PTP on their own,
> mangling MII on the fly using custom FPGA designs etc.
> You probably know the ugly details an order of magnitude better than
> I do, i.e. what it takes to make a TC switch, for P2P mode vs. E2E
> mode... The "TC support in a switch" is likely never going to be pure
> hardware, there's always an element of switch firmware that e.g. does
> the talking with P2P peers... While E2E might look easier to support
> in a switch (than P2P), I've heard a credible opinion that in E2E
> mode, a switch port needs to keep track of delay transactions passing
> through (stateful style - ORLY?) and making E2E work for a single
> slave is not the same as making it work for many slaves :-) etc.
> 
> 
> I've wandered even further off topic here...
> 
> In PTM, having a servoed local oscillator in every PCI-e switch (BC
> style) seems complicated, to the point of being impractical /
> difficult to implement, if the oscillator should be half decent /
> stable...
> 
> In my wildest dreams, it would be beautiful to have a 1PPS output out
> of the CPU TSC. Plug that into some SDP input on an i210, and you'd
> have an idea, where the CPU's PPS edge is located, relative to the
> i210 PHC. Which can in turn be disciplined by PTP, or by another
> external 1PPS reference. Just a single output wire, coming from the
> TSC - it wouldn't even need to be adjustable. Having a timestamp for
> that CPU 1PPS event from the i210, you'd be able to calculate an
> offset in TSC granularity, and subtract that offset from every
> timestamp obtained via rdtsc (at the cost of a single integer sub()
> instruction). A single signal, for 1PPS, coming out of the CPU
> socket. Is that too much to ask? Compared to the rather complex and
> imperfect PTM implementation?
> 
> Actually this is not my wildest dream. I can extrapolate this
> further. Such as:
> 
> After the all, the TSC stands for a "Time Stamp Counter" - isn't that
> ironic?  As it is, the TSC is just a register counting steadily
> forward. What reference does it actually have to the wall time in the
> outside world, apart from the CPU core clock? (Yes I know - now with
> TurboBoost, even the notion of a CPU clock is hazy.) I mean wouldn't
> it be nice if the CPU would have a discrete event *input* into the
> TSC? Typically useable 

Re: [Linuxptp-devel] SyncE support

[Geva, Erez]

On 16/03/2021 15:52, Frantisek Rysanek wrote:
> On 16 Mar 2021 at 11:25, Miroslav Lichvar wrote:
>>
>> In the Intel's igc driver I saw few SYNCE registers defined,
>> but no code using them.
>>
> Whoa. igc ? oh there's an i225... didn't know about this one, thanks
> for the pointer, this definitely looks promising :-)
> Looks like a successor to the i210 generation.
> 
> If I read the gossip correctly, the first generation of i225 are in
> circulation on some gaming motherboards from the first half of 2020,
> and have a hardware bug, something to do with the inter-packet gap.

Yes, like:
https://rog.asus.com/us/motherboards/rog-strix/rog-strix-b550-a-gaming-model/spec
https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-Z490-A/techspec/
https://rog.asus.com/motherboards/rog-strix/rog-strix-z490-g-gaming-model/spec

Looks like both Intel and AMD use them with gaming chipsets.
I guess other motherboard vendors and other chipsets for gaming do too.
Though other motherboard vendors do not specifying the LAN chip on thier 
site.

The inter packet gap remind me of the same issue we measure on Intel i210.

Thanks for telling us know about this issue :-)

> 
> https://www.techpowerup.com/266335/intel-i225-foxville-2-5gbe-phy-has-a-flaw-affecting-performance-rocket-lake-s-2h-2020-production-confirmed
> 
> A version 2 of the silicon, supposedly produced since Q4/2020, has
> this bug fixed. There's no public datasheet, just a data brief and a
> spec update (a list of SKU's + the erratum for v1 inter-packet gap
> bug.)
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.intel.com%2Fcontent%2Fwww%2Fus%2Fen%2Fdesign%2Fproducts-and-solutions%2Fdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Ce50c9c225c1f4ec3b96108d8e88d9381%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637515042052738109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Y7lJWL8HEyW31pF%2BAF5wyFuzMGMfSzF84E969t0kSlU%3Dreserved=0
> networking-and-io/ethernet-controller-i225/technical-library.html
> 
> And, I can actually see a stand-alone PCI-e board mentioned at
> ark.intel.com - the i225-T1 :
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fark.intel.com%2Fcontent%2Fwww%2Fus%2Fen%2Fark%2Fproducts%2F211808%2Fintel-ethedata=04%7C01%7Cerez.geva.ext%40siemens.com%7Ce50c9c225c1f4ec3b96108d8e88d9381%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637515042052738109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tV8bxprqrTAkpRVJGWhH75XfMBmNYPNR%2BNxrjy49H8E%3Dreserved=0
> rnet-network-adapter-i225-t1.html
> 
> I cannot see this in the price lists at disties yet, will keep an eye
> on that one :-) The board may surface sooner from HP, Lenovo or
> Dell... There are no photoes yet - I'm curious if it has an SDP pin
> header, similar to the i210-T1.
> 
> And this one looks cool too:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.commell.com.tw%2FProduct%2FPeripheral%2FPCI%2520Express%2520mini%2520cadata=04%7C01%7Cerez.geva.ext%40siemens.com%7Ce50c9c225c1f4ec3b96108d8e88d9381%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637515042052738109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2BEhxwy%2F%2B5QTl5mTj2wjsE9swiQh65rW%2BgIfbdAlYufU%3Dreserved=0
> rd/MPX-225.HTM
> 
> Frank
> 

We found this one "QXG-2G1T-I225, Single-port 2.5 GbE network expansion 
card with Intel Ethernet Controller I225-LM"
  https://shop.qnap.com/index.php?route=product/product_id=387

Hope it uses a newer hardware version that do not have the inter packet 
gap issue.

I guess there are probably more i225 expansion cards available on market.

Erez

> 
> 
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7Ce50c9c225c1f4ec3b96108d8e88d9381%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637515042052748101%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CzVsygRZot5V9S0ISPFUrabdA5R1Zf03tZb3%2Fl8JIs8%3Dreserved=0
> 

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] SyncE support

[Geva, Erez]

On 16/03/2021 16:59, Miroslav Lichvar wrote:
> On Tue, Mar 16, 2021 at 03:52:36PM +0100, Frantisek Rysanek wrote:
>> On 16 Mar 2021 at 11:25, Miroslav Lichvar wrote:
>>>
>>> In the Intel's igc driver I saw few SYNCE registers defined,
>>> but no code using them.
>>>
>> Whoa. igc ? oh there's an i225... didn't know about this one, thanks
>> for the pointer, this definitely looks promising :-)
>> Looks like a successor to the i210 generation.
> 
> I'm sorry for misleading you. I meant the ice driver (speeds up to
> 100Gb). I didn't see an out-of-tree version of the igc driver.
> 
> The I225 might be an interesting NIC for experiments for a different
> reason. It seems it supports the PCIe Precision Time Measurement (PTM)
> feature. It is a hardware implementation of an NTP-like protocol over
> PCIe, which should allow a highly accurate synchronization of the
> system clock, avoiding the asymmetry on PCIe. It is not supported in
> the igc driver yet, but there were some patches submitted for it.
> 
> I measured the PCIe asymmetry with the I210 on few different
> boards+CPUs and it changed a lot (between about -100ns and 100ns), so
> I think PTM could make a significant improvement.
> 

The "Precision Time Measurement" sound a cool feature.

The PCI is probably asymmetric.
As long as the traffic is not overflow (less then 99%),
The transfer time of the PCI have a limit of ~120 ms (on my PC).
Using hardware timestamps, the timestamps are always taken on the NIC 
hardware, before the PCI. So, the PCI should not change the measurement.

The i210 does have inter gap issue, but it should not be relevant for 
PTP measure.

I did some testing with TSN streaming with i210.
By adding guards on the i210 drivers to over come the inter gap issue, I 
manage to get a precision of less then 20 ns on the streams.

My team did notice that the oscillator of the i210 was not precise 
enough. We use the i210 as client (slave mode), with a good master.
The results should be higher.

Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] Quation regarding the new 'uds_ro_address'

[Geva, Erez]

Hi,

There is a new uds_ro_address with the default file /var/run/ptp4lro.
Which allow to read without setting or modifying.
Great, Good work -:)

What is your view on the files permission?

$ ls -l  /var/run/ptp4l*
srw-rw 1 root root 0 Mar 16 13:21 /var/run/ptp4l
srw-rw 1 root root 0 Mar 16 13:21 /var/run/ptp4lro

Can we set the read only file with a group, so we can run quaries 
without root?

How about adding a "group" configuration for the uds_ro_address?

Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/2] Explicit length byte order swap functions.

[Geva, Erez]

How do you want to call the 64 bits?
I think that naming should be consistence.

Erez

-Original Message-
From: Richard Cochran  
Sent: Thursday, 11 March 2021 04:12
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH 1/2] Explicit length byte order swap 
functions.

On Wed, Mar 10, 2021 at 11:17:48PM +0100, Erez Geva wrote:
> Replace byte order with explicit length.
> 
> Add function for byte order for 64 bits.
> 
> Signed-off-by: Erez Geva 
> ---
>  clock.c |   4 +-
>  msg.c   |  51 ++---
>  nsm.c   |   2 +-
>  port.c  |   5 +-
>  raw.c   |  10 +--
>  tc.c|   8 +-
>  tlv.c   | 207 ++--
>  transport.c |   9 ++-
>  udp.c   |   6 +-
>  udp6.c  |   4 +-
>  util.h  |  67 +
>  11 files changed, 221 insertions(+), 152 deletions(-)
> 
> diff --git a/clock.c b/clock.c
> index 7005636..5b3b4d0 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -255,12 +255,12 @@ void clock_send_notification(struct clock *c, struct 
> ptp_message *msg,
>   if (!event_bitmask_get(s->events, event))
>   continue;
>   /* send event */
> - msg->header.sequenceId = htons(s->sequenceId);
> + msg->header.sequenceId = hton16(s->sequenceId);

I really don't see any improvement here.

Sorry,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] PORT_STATS_NP management TLV message

[Geva, Erez]

On 10/03/2021 00:38, Keller, Jacob E wrote:
>> -Original Message-
>> From: Geva, Erez
>> Sent: Tuesday, March 09, 2021 2:29 PM
>> To: Richard Cochran
>> Cc:linuxptp-devel@lists.sourceforge.net
>> Subject: Re: [Linuxptp-devel] PORT_STATS_NP management TLV message
>>
>> Hi,
>>
>> I can be live with using little endian.
>> This is not the first time I see using little endian with IEEE.
>>
>> However with the current code the endian depends on machine.
>> So a linuxptp daemon that runs on a big endian (there are yet some) will 
>> send the
>> message in big endian.
>>
>> May be we should limit this TLV message to UDS only?
>> Since UDS always run on the same machine.
>>
>> Erez
>>
> If it only runs on the same machine there should be no issue. Even if it 
> crosses network I think just documenting that the format is in "host" endian 
> and adding a configuration option to pmc tool that allows you to set the 
> format to read the command output in would be enough?
>
> Alternatively we can add a new PORTS_STATS_STRICT_NP or something which would 
> strictly use either Big or Little endian format, and then work on deprecating 
> the old format...
>
> Thanks,
> Jake
-- 

I see the same issue in:
     TLV_TIME_STATUS_NP
     TLV_GRANDMASTER_SETTINGS_NP
     TLV_SUBSCRIBE_EVENTS_NP
     TLV_PORT_DATA_SET_NP

Do you think we should add  "STRICT" version, add "endian" flag to pmc 
or both?
Or limit all the managment XX_NP to UDS?

Erez



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] First alpha version of libpmc here https://github.com/erezgeva/libpmc

[Geva, Erez]

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] PORT_STATS_NP management TLV message

[Geva, Erez]

Hi,

I can be live with using little endian.
This is not the first time I see using little endian with IEEE.

However with the current code the endian depends on machine.
So a linuxptp daemon that runs on a big endian (there are yet some) will send 
the message in big endian.

May be we should limit this TLV message to UDS only?
Since UDS always run on the same machine.

Erez


-Original Message-
From: Richard Cochran  
Sent: Tuesday, 9 March 2021 17:57
To: Geva, Erez (ext) (DI PA DCP R 3) 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: PORT_STATS_NP management TLV message

On Tue, Mar 09, 2021 at 01:59:33PM +, Geva, Erez wrote:
> As I add the PORT_STATS_NP message,
>  I notice that the statistics is stored in unsigned integer 64 bits values, 
> but using host order instead of network order.

Oops, that was an oversight.
 
> As I know you follow the IEEE standard, It would be nice if you could 
> elaborate on this message.

This message is a custom message, and it is not covered by IEEE 1588 or any 
other standard.
 
> Can we fix it and rebase it to network order?

Unfortunately, simply "fixing" it unconditionally will break existing 
deployments.

> May be add a flag for backward compatible.

If we go with that, then the default value of "compatible" will have to be 
"true".

> What do you think?

Maybe it is better to simply leave it as is.  I myself don't use this TLV.  
Since the pmc tool prints the correct values, probably nobody would insist on 
having big endian in the on-the-wire format.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] PORT_STATS_NP management TLV message

[Geva, Erez]

Hi,

I am about to release a first version of a new libpmc library under LGPL for 
all the guys who "parse" pmc output.

As I add the PORT_STATS_NP message,
 I notice that the statistics is stored in unsigned integer 64 bits values, but 
using host order instead of network order.

As I know you follow the IEEE standard,
It would be nice if you could elaborate on this message.

Can we fix it and rebase it to network order?
May be add a flag for backward compatible.

What do you think?

With best regards,
Erez Geva

AURELLY TECHNOLOGIES GmbH
External service provider at Siemens AG
Digital Industries
Process Automation
Software House Nbg
DI PA DCP R 3
Gleiwitzer Str. 555
90475 Nuremberg, Germany
mailto:erez.geva@siemens.com
[cid:image002.jpg@01D714F4.CF479670]
www.aurelly.com
CEO: Jens Stötzner, company's place of business: Nürnberg,
VAT identification: DE 255071685, Commercial register No.: HRB: 15550
[cid:image004.png@01D714F4.CF479670] Please consider the environment before 
printing this email
Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Geva, Erez]

Hi,



Personally I prefer leader/followers over source/sink.



Source remind me of source code.

And sink remind me of where our water goes after we use them.



Client/server is good as well.



Erez



From: Jagmeet Singh Hanspal 
Sent: Wednesday, 19 August 2020 06:00
To: Richard Cochran 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology



Few suggestions:



AVB uses end-stations and relays, as well as initiator/responder as the context 
maybe, like:

 - PTP End Instance: The AVB talkers and listener end-stations. It may also be 
a GM.

- PTP Relay Instance: Could be inside a bridge, a router, or a multiport 
end-station.

- PTP .1AS initiator: The node that has initiated the Peer-to-Peer delay 
mechanism.

- PTP .1AS responder: The peer-node that is responding to the P2P delay request.

 And Source/Sink or Client/Server may also be ok, in the documentation. The 
master/slave etc will have to be replaced in the IEEE 1588 and GM etc all the 
way to ITU-T telecom standards.



The term, “slave” has the negative connotations, rather a “follower” that 
chooses its leader or role-model (GM -> RM) and looks-up to follow its lead. 
Anyways, even in the IEEE standard (like Richard mentioned), a master is not 
employing slaves, instead, it is the follower that is "choosing" who it needs 
to consider a leader and subsequently follow it, so in our conversations, we 
are starting to use these terminologies instead.



Regards,

Jagmeet



On Wed, Aug 19, 2020 at 3:26 AM Richard Cochran 
mailto:richardcoch...@gmail.com>> wrote:

   On Tue, Aug 18, 2020 at 02:51:26PM -0700, Jacob Keller wrote:
   > Yep, makes sense. Long term, after changing the stuff which doesn't
   > impact config, we can work towards finding a way to deprecate and rename
   > config options in a way that won't break existing deployment. I'm
   > personally Ok with simply leaving the original name as a deprecated
   > alternative name with an explanation.

   That is what I was thinking, too.

   Thanks,
   Richard


   ___
   Linuxptp-devel mailing list
   
Linuxptp-devel@lists.sourceforge.net
   
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel






   --


   Best Regards,
   ~
   Jagmeet Singh Hanspal
   ~

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Geva, Erez]

A sheep herder dog is leading the sheep.
And yet it is all over the place.

Leading does not mean you are a head on behind.
It means that all the reset are following you.
Some might be a head and slowing.
Some might be behind and being pushed by the leader.

I short. It means that they are follows the leader.

Erez

-Original Message-
From: Richard Cochran 
Sent: Wednesday, 19 August 2020 17:20
To: Geva, Erez (ext) (DI PA CI R 3) 
Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

On Wed, Aug 19, 2020 at 03:06:22PM +, Geva, Erez wrote:
> Personally I prefer leader/followers over source/sink.

Let's think about those terms...

If clock A is leading clock B, then clock A is running ahead.

If clock A is following clock B, then clock A is running behind.

Sounds rather silly for a synchronization protocol, if you ask me.

> Source remind me of source code.
>
> And sink remind me of where our water goes after we use them.

:)

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

[Geva, Erez]

P.S.

The sink goes in one direction.


-Original Message-
From: Geva, Erez (ext) (DI PA CI R 3)
Sent: Wednesday, 19 August 2020 18:14
To: richardcoch...@gmail.com
Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net
Subject: RE: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

A sheep herder dog is leading the sheep.
And yet it is all over the place.

Leading does not mean you are a head on behind.
It means that all the reset are following you.
Some might be a head and slowing.
Some might be behind and being pushed by the leader.

I short. It means that they are follows the leader.

Erez

-Original Message-
From: Richard Cochran 
Sent: Wednesday, 19 August 2020 17:20
To: Geva, Erez (ext) (DI PA CI R 3) 
Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

On Wed, Aug 19, 2020 at 03:06:22PM +, Geva, Erez wrote:
> Personally I prefer leader/followers over source/sink.

Let's think about those terms...

If clock A is leading clock B, then clock A is running ahead.

If clock A is following clock B, then clock A is running behind.

Sounds rather silly for a synchronization protocol, if you ask me.

> Source remind me of source code.
>
> And sink remind me of where our water goes after we use them.

:)

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [RFC PATCH 01/15] posix_clock_open: derive PHC index from device name if possible

[Geva, Erez]

On 12/08/2020 23:40, Keller, Jacob E wrote:
>> -Original Message-
>> From: Richard Cochran 
>> Sent: Wednesday, August 12, 2020 8:40 AM
>> To: Keller, Jacob E 
>> Cc: linuxptp-devel@lists.sourceforge.net
>> Subject: Re: [Linuxptp-devel] [RFC PATCH 01/15] posix_clock_open: derive PHC
>> index from device name if possible
>>
>> On Wed, Aug 05, 2020 at 04:12:02PM -0700, Jacob Keller wrote:
>>> Here, we are making the implicit assumption that all ptp clock devices
>>> will always have /dev/ptpX format. I don't think anyone is crazy enough
>>> to rename these devices...
>>
>> (Not yet, anyways  ;^)
>>
>>> An alternative (requiring kernel implementation maybe?) would be to read
>>> the phc index from the kernel somehow. It doesn't look like this is
>>> exported anywhere else besides the name.
>>
>> How about /sys/class/ptp/ptpX/clock_index ?
>>
>> Is that something you would like to code up for the lkml?
>>
>> Thanks,
>> Richard
>
> To make this fully work we'll probably want to adjust the LinuxPTP code base 
> with a phc_index_to_dev function that scans the sys/class/ptp folder for the 
> matching clock based on the index to obtain the name. I'll see about adding 
> that as well (with a fallback to attempting /dev/ptpX if clock_index doesn't 
> exist)
>
> Thanks,
> Jake
>

Most linux system have /sys mounted
"sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)"

But I guess it is not mandatory.
I think fallback is needed.

Erez

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH V1 2/2] Add support for write phase mode.

[Geva, Erez]

Hi,

For TSN, we need jitter of ~ 100 nanoseconds,
And most interface can issue a jitter of ~10 nanoseconds.
So for now TSN does not need fractions of nanosecond.
Further more, I do not think there is any Ethernet based traffic that can 
benefit from such accuracy.
As for 1 Gigabits, each bit is nanoseconds so the phy is not sensitive for less.
It is only make sense to have PHC of fractional nanoseconds if you can set the 
PTP to accuracy < 2 nanoseconds,
I mean master offset and time adjust of less then.
May be when 10 Gigabits or higher throughput goes to end device, it will make 
sense.

Erez


-Original Message-
From: Richard Cochran 
Sent: Sunday, 24 May 2020 18:33
To: FUSTE Emmanuel 
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH V1 2/2] Add support for write phase mode.

On Mon, May 18, 2020 at 07:58:47AM +, FUSTE Emmanuel wrote:
> Perhaps too late, and should have been raised on netdev but why ns
> granularity for phase adjustment ?

This comes from the traditional NTP timex interface.

> Talking about net device phc clock and phase adjustment I directly
> think "white rabbit". If your PHC is locked on the ethernet carrier
> (SyncE), the final step is phase adjustment to go to sub ns sync.
> Choosing ps granularity would be more future proof for the interface
> and would allow to expose white rabbit hardware clock/board as a PHC
> and implement the WR control plane in userspace using standard
> interface (would need more extension, but it is a start).

I think it wouldn't be hard to extend the interface.  You could take one of the 
unused 32 bit fields and make that fractional nanoseconds, for example.  If 
white rabbit wants to submit an patch to the kernel along with a driver, then I 
would support the idea.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=02%7C01%7Cerez.geva.ext%40siemens.com%7Ceeb3d8bedb8f4424853d08d847ad%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637259348485004077sdata=5ORoy2eXzrwJI4ETgsbfUIbhLpb4ZlpKDvnm5jRk%2BXI%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [RFC PATCH v2 2/3] pwm: Add helper apis to control pwm

[Geva, Erez]

>From a quick look.
It seems that it is 'pwmchip%d' for a long time.

https://elixir.bootlin.com/linux/v4.0/source/drivers/pwm/sysfs.c#L314

Erez

-Original Message-
From: Richard Cochran 
Sent: Saturday, 16 May 2020 21:15
To: Lokesh Vutla 
Cc: Sekhar Nori ; linuxptp-devel@lists.sourceforge.net; 
e-ru...@ti.com
Subject: Re: [Linuxptp-devel] [RFC PATCH v2 2/3] pwm: Add helper apis to 
control pwm

On Sat, May 16, 2020 at 11:53:57PM +0530, Lokesh Vutla wrote:
> +#define PWM_CHAN_EXPORT  "/sys/class/pwm/pwmchip%d/export"

> +#define PWM_CHAN_ENABLE  "/sys/class/pwm/pwmchip%d/pwm%d/enable"
> +#define PWM_CHAN_PERIOD  "/sys/class/pwm/pwmchip%d/pwm%d/period"

Hm, this is strange.  I have been using pwm via sysfs on kernel 4.19, and there 
the paths are like this:

/sys/class/pwm/pwm%d/enable

What happened to sysfs?  Did the ABI change?

Looks like there will be more work needed here, in order to deal with the (at 
least) two different ABIs.

:(

Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=02%7C01%7Cerez.geva.ext%40siemens.com%7C4f8629e3f807483229c108d7f9cda6d6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637252533971915054sdata=%2FqoHl08HgDyaVrfgm3pliszetPtRpocnRberVYs%2B5cI%3Dreserved=0


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Adding libpmc

[Geva, Erez]

> > While the Kernel is under GPL 2.
> > The headers and system call are under exception, so user can use the
> > Kernel with non GPL code. But any changes or addition to the kernel
> > itself should be GPL 2.
>
> This is very different. The Linux kernel is supposed to run any kind of 
> programs under various licenses. Linux PTP is not a generic mechanism 
> intended to run other software.
>
> [Slightly off topic: Moreover, the kernel has a strict boundary (uAPI) 
> between its internals and the user space programs. It's so strictly defined 
> that it does not require LGPL but instead is covered by a GPL exception. That 
> is different to libraries. In fact, the kernel uAPI is more close to stuff 
> like RPC or REST API than to libraries.]

I merely use the kernel as example that copywrites holders think of using their 
GPL software with non GPL software.
LGPL is only one way common to libraries, but there are other approaches.

> > The exception means that any code that is part of the LinuxPTP must be
> > coverd by GPL.
> >
> > But user may embedded a library in their non GPL application and
> > communicate with the ptp4l.
> >
> > Do you have another suggestion?
>
> Why can't those applications that use parts of linuxptp code be licensed 
> under GPL? That seems like a win for everybody.

If I could write all of my software as GPL, I would not ask.
Although I personally in favour, sometimes there are more constrains that are 
beyond me.
I do not ask you copywrites holders to solve all of the licence constrains, 
just for more flexible with a library that is derive from the project.

I was looking for a management interface to communicate with the ptp4l without 
implement PTP all over again.
I only find future SNMP support, but SNMP is more suitable for NMS.
I did not find any simple way to query the ptp4l for it's status without using 
the PMC tool.

> Jiri

Any advice is welcome, if I can add GPL code to improve, I will.

Erez


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Adding libpmc

[Geva, Erez]

My logic is the same one you find in Linux kernel and in other GNU projects.

While the Kernel is under GPL 2.
The headers and system call are under exception, so user can use the Kernel 
with non GPL code.
But any changes or addition to the kernel itself should be GPL 2.

The exception means that any code that is part of the LinuxPTP must be coverd 
by GPL.

But user may embedded a library in their non GPL application and communicate 
with the ptp4l.

Do you have another suggestion?

Erez

-Original Message-
From: Richard Cochran 
Sent: Thursday, 16 April 2020 17:09
To: Geva, Erez (ext) (DI PA CI R 3) 
Cc: Red Hat, Inc., Jiri Benc ; Miroslav Lichvar 
; Jacob Keller ; Delio Brignoli 
; Jacob Keller ; Vedang 
Patel ; linuxptp-devel@lists.sourceforge.net
Subject: Re: Adding libpmc

On Thu, Apr 16, 2020 at 02:18:25PM +, Geva, Erez wrote:
> I see that linux PTP is under GPL 2.
>
> I would like to ask your permission to allow using a libpmc library and 
> headers needed by it under LGPL 2.

As one of the copyright holders, I do not agree to any change of license.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Adding libpmc

[Geva, Erez]

Hi,



I see that linux PTP is under GPL 2.

I would like to ask your permission to allow using a libpmc library and headers 
needed by it under LGPL 2.

As you are the copywrite holders, we need your explicit consent.



Thanks

   Erez Geva



From: Geva, Erez (ext) (DI PA CI R 3)
Sent: Thursday, 9 April 2020 16:30
To: linuxptp-devel@lists.sourceforge.net
Subject: Adding libpmc



Hi,



As I thought that libpmc could be nice for several application that need to 
communicate with the ptp4l.

I decided to make a short test.



First I patch the makefile to create the libpmc.so

diff --git a/makefile b/makefile

index a23945a..f5e12da 100644

--- a/makefile

+++ b/makefile

@@ -23,6 +23,7 @@ VER = -DVER=$(version)

CFLAGS = -Wall $(VER) $(incdefs) $(DEBUG) $(EXTRA_CFLAGS)

LDLIBS = -lm -lrt $(EXTRA_LDFLAGS)

PRG= ptp4l hwstamp_ctl nsm phc2sys phc_ctl pmc timemaster

+LIBS   = libpmc.so

FILTERS= filter.o mave.o mmedian.o

SERVOS = linreg.o ntpshm.o nullf.o pi.o servo.o

TRANSP = raw.o transport.o udp.o udp6.o uds.o

@@ -46,7 +47,7 @@ sbindir   = $(prefix)/sbin

mandir = $(prefix)/man

man8dir= $(mandir)/man8



-all: $(PRG)

+all: $(PRG) $(LIBS)



ptp4l: $(OBJ)



@@ -56,6 +57,18 @@ nsm: config.o $(FILTERS) hash.o interface.o msg.o nsm.o 
phc.o print.o \

pmc: config.o hash.o interface.o msg.o phc.o pmc.o pmc_common.o print.o sk.o \

  tlv.o $(TRANSP) util.o version.o



+.libs:

+   @mkdir -p $@

+# Generic rule to compile for shared libraries

+.libs/%.o: %.c | .libs

+   $(CC) $(CPPFLAGS) $(CFLAGS) -fPIC -DPIC -c $< -o $@

+

+LIBPMC_OBJS:=$(foreach n,config.o hash.o interface.o msg.o phc.o \

+ pmc_common.o print.o sk.o tlv.o $(TRANSP) util.o version.o,.libs/$n)

+

+libpmc.so: $(LIBPMC_OBJS)

+   $(CC) -shared $^ $(LDLIBS) -o $@

+

phc2sys: clockadj.o clockcheck.o config.o hash.o interface.o msg.o \

  phc.o phc2sys.o pmc_common.o print.o $(SERVOS) sk.o stats.o \

  sysoff.o tlv.o $(TRANSP) util.o version.o

@@ -83,7 +96,7 @@ install: $(PRG)

done



clean:

-   rm -f $(OBJECTS) $(DEPEND) $(PRG)

+   rm -f $(OBJECTS) $(DEPEND) $(PRG) $(LIBS) $(LIBPMC_OBJS)



distclean: clean

rm -f .version

diff --git a/.gitignore b/.gitignore

index 3dbcbfa..091fbf2 100644

--- a/.gitignore

+++ b/.gitignore

@@ -9,3 +9,5 @@

/phc_ctl

/snmp4lptp

/timemaster

+/libpmc.so

+/.libs/





Than I create a simple application

#include 
#include 

extern "C"
{
#include "linuxptp/ds.h"
#include "linuxptp/fsm.h"
#include "linuxptp/notification.h"
#include "linuxptp/pmc_common.h"
#include "linuxptp/print.h"
#include "linuxptp/tlv.h"
#include "linuxptp/uds.h"
#include "linuxptp/util.h"
#include "linuxptp/version.h"
}

class My_Pmc
{
private:
bool init_done;
struct config *cfg;
struct pmc *pmc;

bool parse(struct ptp_message *msg);
bool get(int id);

public:
My_Pmc(const char *cfg_file, const char *uds_address, uint8_t 
boundary_hops);
~My_Pmc();

bool get_port_data_set();
bool get_time_status_np();

// from TLV_PORT_DATA_SET - PORT_DATA_SET
int64_t peerMeanPathDelay;
std::string portState;

// from TLV_TIME_STATUS_NP - TIME_STATUS_NP
int64_t master_offset;
std::string gmIdentity;
};

bool My_Pmc::parse(struct ptp_message *msg)
{
if (msg_type(msg) != MANAGEMENT)
return false;
int action = management_action(msg);
if (action < GET || action > ACKNOWLEDGE)
return false;
if (msg_tlv_count(msg) != 1)
return false;

struct TLV *tlv = (struct TLV *)msg->management.suffix;
if (tlv->type == TLV_MANAGEMENT_ERROR_STATUS && tlv->type != TLV_MANAGEMENT)
return false;

struct management_tlv *mgt;
mgt = (struct management_tlv *)msg->management.suffix;
if (mgt->length == 2 && mgt->id != TLV_NULL_MANAGEMENT)
return false;

struct time_status_np *tsn;
struct portDS *p;

switch (mgt->id) {
case TLV_PORT_DATA_SET:
p = (struct portDS *)mgt->data;
if (p->portState > PS_SLAVE)
portState = "NONE";
else
portState = ps_str[p->portState];
peerMeanPathDelay = p->peerMeanPathDelay >> 16;
break;
case TLV_TIME_STATUS_NP:
tsn = (struct time_status_np *)mgt->data;
master_offset = tsn->master_offset;
gmIdentity = cid2str(>gmIdentity);
break;
}
return true;
}

My_Pmc::My_Pmc(const char *cfg_file, const char *uds_address, uint8_t 
boundary_hops):
init_done(false)
{
cfg = config_create();
if (cfg == nullptr)
return;

if (config_read(cfg_file, cfg))
return;

if (config_set_string(cfg, "uds_address", uds_address))
return;

if (config_set_int(cfg, "network_transport", TRANS_UDS))
return;

char uds_local[MAX_IFN

[Linuxptp-devel] Adding libpmc

[Geva, Erez]

Hi,



As I thought that libpmc could be nice for several application that need to 
communicate with the ptp4l.

I decided to make a short test.



First I patch the makefile to create the libpmc.so

diff --git a/makefile b/makefile

index a23945a..f5e12da 100644

--- a/makefile

+++ b/makefile

@@ -23,6 +23,7 @@ VER = -DVER=$(version)

CFLAGS = -Wall $(VER) $(incdefs) $(DEBUG) $(EXTRA_CFLAGS)

LDLIBS = -lm -lrt $(EXTRA_LDFLAGS)

PRG= ptp4l hwstamp_ctl nsm phc2sys phc_ctl pmc timemaster

+LIBS   = libpmc.so

FILTERS= filter.o mave.o mmedian.o

SERVOS = linreg.o ntpshm.o nullf.o pi.o servo.o

TRANSP = raw.o transport.o udp.o udp6.o uds.o

@@ -46,7 +47,7 @@ sbindir   = $(prefix)/sbin

mandir = $(prefix)/man

man8dir= $(mandir)/man8



-all: $(PRG)

+all: $(PRG) $(LIBS)



ptp4l: $(OBJ)



@@ -56,6 +57,18 @@ nsm: config.o $(FILTERS) hash.o interface.o msg.o nsm.o 
phc.o print.o \

pmc: config.o hash.o interface.o msg.o phc.o pmc.o pmc_common.o print.o sk.o \

  tlv.o $(TRANSP) util.o version.o



+.libs:

+   @mkdir -p $@

+# Generic rule to compile for shared libraries

+.libs/%.o: %.c | .libs

+   $(CC) $(CPPFLAGS) $(CFLAGS) -fPIC -DPIC -c $< -o $@

+

+LIBPMC_OBJS:=$(foreach n,config.o hash.o interface.o msg.o phc.o \

+ pmc_common.o print.o sk.o tlv.o $(TRANSP) util.o version.o,.libs/$n)

+

+libpmc.so: $(LIBPMC_OBJS)

+   $(CC) -shared $^ $(LDLIBS) -o $@

+

phc2sys: clockadj.o clockcheck.o config.o hash.o interface.o msg.o \

  phc.o phc2sys.o pmc_common.o print.o $(SERVOS) sk.o stats.o \

  sysoff.o tlv.o $(TRANSP) util.o version.o

@@ -83,7 +96,7 @@ install: $(PRG)

done



clean:

-   rm -f $(OBJECTS) $(DEPEND) $(PRG)

+   rm -f $(OBJECTS) $(DEPEND) $(PRG) $(LIBS) $(LIBPMC_OBJS)



distclean: clean

rm -f .version

diff --git a/.gitignore b/.gitignore

index 3dbcbfa..091fbf2 100644

--- a/.gitignore

+++ b/.gitignore

@@ -9,3 +9,5 @@

/phc_ctl

/snmp4lptp

/timemaster

+/libpmc.so

+/.libs/





Than I create a simple application

#include 
#include 

extern "C"
{
#include "linuxptp/ds.h"
#include "linuxptp/fsm.h"
#include "linuxptp/notification.h"
#include "linuxptp/pmc_common.h"
#include "linuxptp/print.h"
#include "linuxptp/tlv.h"
#include "linuxptp/uds.h"
#include "linuxptp/util.h"
#include "linuxptp/version.h"
}

class My_Pmc
{
private:
bool init_done;
struct config *cfg;
struct pmc *pmc;

bool parse(struct ptp_message *msg);
bool get(int id);

public:
My_Pmc(const char *cfg_file, const char *uds_address, uint8_t 
boundary_hops);
~My_Pmc();

bool get_port_data_set();
bool get_time_status_np();

// from TLV_PORT_DATA_SET - PORT_DATA_SET
int64_t peerMeanPathDelay;
std::string portState;

// from TLV_TIME_STATUS_NP - TIME_STATUS_NP
int64_t master_offset;
std::string gmIdentity;
};

bool My_Pmc::parse(struct ptp_message *msg)
{
if (msg_type(msg) != MANAGEMENT)
return false;
int action = management_action(msg);
if (action < GET || action > ACKNOWLEDGE)
return false;
if (msg_tlv_count(msg) != 1)
return false;

struct TLV *tlv = (struct TLV *)msg->management.suffix;
if (tlv->type == TLV_MANAGEMENT_ERROR_STATUS && tlv->type != TLV_MANAGEMENT)
return false;

struct management_tlv *mgt;
mgt = (struct management_tlv *)msg->management.suffix;
if (mgt->length == 2 && mgt->id != TLV_NULL_MANAGEMENT)
return false;

struct time_status_np *tsn;
struct portDS *p;

switch (mgt->id) {
case TLV_PORT_DATA_SET:
p = (struct portDS *)mgt->data;
if (p->portState > PS_SLAVE)
portState = "NONE";
else
portState = ps_str[p->portState];
peerMeanPathDelay = p->peerMeanPathDelay >> 16;
break;
case TLV_TIME_STATUS_NP:
tsn = (struct time_status_np *)mgt->data;
master_offset = tsn->master_offset;
gmIdentity = cid2str(>gmIdentity);
break;
}
return true;
}

My_Pmc::My_Pmc(const char *cfg_file, const char *uds_address, uint8_t 
boundary_hops):
init_done(false)
{
cfg = config_create();
if (cfg == nullptr)
return;

if (config_read(cfg_file, cfg))
return;

if (config_set_string(cfg, "uds_address", uds_address))
return;

if (config_set_int(cfg, "network_transport", TRANS_UDS))
return;

char uds_local[MAX_IFNAME_SIZE + 1];
snprintf(uds_local, sizeof(uds_local), "/var/run/pmc.%d", getpid());

pmc = pmc_create(cfg, TRANS_UDS, uds_local, boundary_hops,
config_get_int(cfg, nullptr, "domainNumber"),
config_get_int(cfg, nullptr, "transportSpecific") << 4, 0);

if (pmc != nullptr)
init_done = true;
}

bool My_Pmc::get(int id)
{
if (!init_done)
return false;
if (pmc_send_get_action(pmc, id))
return false;

struct pollfd pd;
pd.fd = pmc_get_transport_fd(pmc);
pd.events = POLLIN | POLLPRI;
int cnt = poll(, 1, 200); // 200 

Re: [Linuxptp-devel] [PATCH v4] sk: Recognize HWTSTAMP_FILTER_SOME

[Geva, Erez]

Great patch

Good work  :-)


From: Petr Machata [pe...@mellanox.com]
Sent: 11 June 2019 18:35
To: linuxptp-devel@lists.sourceforge.net
Cc: Petr Machata; Keller, Jacob E; Geva, Erez (ext) (DI PA CI R 3)
Subject: [PATCH v4] sk: Recognize HWTSTAMP_FILTER_SOME

struct hwtstamp_config.rx_filter passed to SIOCSHWTSTAMP can be updated by
the kernel with the value of HWTSTAMP_FILTER_SOME. That indicates that all
requested packets will be timestamped, and some others as well.

Update hwts_init() to recognize this as a valid response in HWTS_FILTER_NORMAL
mode, instead of rejecting it as mismatch.

Cc: "Keller, Jacob E" 
Cc: "Geva, Erez" 
Signed-off-by: Petr Machata 
---

Notes:
v4:
- Do not permit HWTSTAMP_FILTER_SOME for HWTS_FILTER_FULL either.

v3:
- Do not permit HWTSTAMP_FILTER_SOME for SIOCGHWTSTAMP.

v2:
- Fix whitespace.

 sk.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/sk.c b/sk.c
index 93ba77a..e211175 100644
--- a/sk.c
+++ b/sk.c
@@ -61,6 +61,7 @@ static int hwts_init(int fd, const char *device, int 
rx_filter,
 {
struct ifreq ifreq;
struct hwtstamp_config cfg;
+   int orig_rx_filter;
int err;

init_ifreq(, , device);
@@ -84,14 +85,14 @@ static int hwts_init(int fd, const char *device, int 
rx_filter,
break;
case HWTS_FILTER_NORMAL:
cfg.tx_type   = tx_type;
-   cfg.rx_filter = rx_filter;
+   cfg.rx_filter = orig_rx_filter = rx_filter;
err = ioctl(fd, SIOCSHWTSTAMP, );
if (err < 0) {
pr_info("driver rejected most general HWTSTAMP filter");

init_ifreq(, , device);
cfg.tx_type   = tx_type;
-   cfg.rx_filter = rx_filter2;
+   cfg.rx_filter = orig_rx_filter = rx_filter2;

err = ioctl(fd, SIOCSHWTSTAMP, );
if (err < 0) {
@@ -99,6 +100,8 @@ static int hwts_init(int fd, const char *device, int 
rx_filter,
return err;
}
}
+   if (cfg.rx_filter == HWTSTAMP_FILTER_SOME)
+   cfg.rx_filter = orig_rx_filter;
break;
}

--
2.20.1



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

[Geva, Erez]

If you ask to stamp all packets with HWTSTAMP_FILTER_ALL, then you can not get 
a reply of "plus some others". 
You ask for all, which more do you think you can get?

It does make sense as a reply in case of HWTS_FILTER_FULL.

enum hwtstamp_rx_filters {
/* time stamp any incoming packet */
HWTSTAMP_FILTER_ALL,

As of HWTS_FILTER_NORMAL case, your patch make sense.

Thanks
   Erez



From: Petr Machata [pe...@mellanox.com]
Sent: 11 June 2019 16:22
To: Geva, Erez (ext) (DI PA CI R 3)
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

Geva, Erez  writes:

> Hi,
>
> The "cfg.rx_filter != HWTSTAMP_FILTER_ALL)) { "
>   line catch both filter mode is "HWTS_FILTER_FULL, and the fact that the 
> filter could is in a higher state for both HWTS_FILTER_NORMAL, 
> HWTS_FILTER_CHECK.
>
> Could you be more specific what does the HWTSTAMP_FILTER_SOME means?

>From net_tstamp.h:

/* possible values for hwtstamp_config->rx_filter */
enum hwtstamp_rx_filters {
...
/* return value: time stamp all packets requested plus some others */
HWTSTAMP_FILTER_SOME,
};

> For me, the HWTSTAMP_FILTER_SOME might be good when using filter mode
> "HWTS_FILTER_NORMAL".
>
> But when filter mode is "HWTS_FILTER_FULL" I would accept that the flag will 
> be HWTSTAMP_FILTER_ALL only.

If you make ALL acceptable, why not SOME? Both mean that the driver will
timestamp everything requested and more.

> What would you accept on filter mode HWTS_FILTER_CHECK?

I agree that for HWTS_FILTER_CHECK, SOME is not acceptable, which is why
I respun v3 of my patch.

> Full state machine:
>
> HWTS_FILTER_CHECK
> get config
> check if RX filter one of Rx filter 1, Rx filter 2, HWTSTAMP_FILTER_ALL
> As HWTSTAMP_FILTER_ALL is a higher state
>
> HWTS_FILTER_NORMAL
> set Rx filter 1
> if fail set Rx filter 2
> check if RX filter one of Rx filter 1, Rx filter 2, HWTSTAMP_FILTER_ALL
> As HWTSTAMP_FILTER_ALL is a higher state
>
> HWTS_FILTER_FULL
> set Rx filter HWTSTAMP_FILTER_ALL
> check if RX filter one of Rx filter 1, Rx filter 2, HWTSTAMP_FILTER_ALL
> Filter should be HWTSTAMP_FILTER_ALL,
>  but if NIc driver only set filter to be one of Rx filter 1, Rx filter 2 
> then the PTP daemon may proceed normally.
>
> Erez
>
> 
> From: Petr Machata [pe...@mellanox.com]
> Sent: 10 June 2019 15:56
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME
>
> struct hwtstamp_config.rx_filter passed to SIOCSHWTSTAMP can be updated by
> the kernel with the value of HWTSTAMP_FILTER_SOME. That indicates that all
> requested packets will be timestamped, and some others as well.
>
> Update hwts_init() to recognize this as a valid response, instead of
> rejecting it as mismatch.
>
> Signed-off-by: Petr Machata 
> ---
>
> Notes:
> v2: Fix whitespace.
>
>  sk.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/sk.c b/sk.c
> index 93ba77a..416d784 100644
> --- a/sk.c
> +++ b/sk.c
> @@ -105,7 +105,8 @@ static int hwts_init(int fd, const char *device, int 
> rx_filter,
> if (cfg.tx_type != tx_type ||
> (cfg.rx_filter != rx_filter &&
>  cfg.rx_filter != rx_filter2 &&
> -cfg.rx_filter != HWTSTAMP_FILTER_ALL)) {
> +cfg.rx_filter != HWTSTAMP_FILTER_ALL &&
> +cfg.rx_filter != HWTSTAMP_FILTER_SOME)) {
> pr_debug("tx_type   %d not %d", cfg.tx_type, tx_type);
> pr_debug("rx_filter %d not %d or %d", cfg.rx_filter, 
> rx_filter,
>  rx_filter2);


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v3] sk: Recognize HWTSTAMP_FILTER_SOME

[Geva, Erez]

Hi,

It make sense for HWTS_FILTER_NORMAL.

But for HWTSTAMP_FILTER_ALL, it does not make sense to get 
HWTSTAMP_FILTER_SOME. 
Some of what? You ask for all!
Neither can you use rx_filter in this case, since it was not used in the 
SIOCSHWTSTAMP request.

Erez


From: Petr Machata [pe...@mellanox.com]
Sent: 11 June 2019 15:18
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH v3] sk: Recognize HWTSTAMP_FILTER_SOME

struct hwtstamp_config.rx_filter passed to SIOCSHWTSTAMP can be updated by
the kernel with the value of HWTSTAMP_FILTER_SOME. That indicates that all
requested packets will be timestamped, and some others as well.

Update hwts_init() to recognize this as a valid response, instead of
rejecting it as mismatch.

Cc: "Keller, Jacob E" 
Signed-off-by: Petr Machata 
---

Notes:
v3:
- Do not permit HWTSTAMP_FILTER_SOME for SIOCGHWTSTAMP.

v2:
- Fix whitespace.

 sk.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/sk.c b/sk.c
index 93ba77a..8fda9c2 100644
--- a/sk.c
+++ b/sk.c
@@ -61,6 +61,7 @@ static int hwts_init(int fd, const char *device, int 
rx_filter,
 {
struct ifreq ifreq;
struct hwtstamp_config cfg;
+   int orig_rx_filter;
int err;

init_ifreq(, , device);
@@ -81,17 +82,19 @@ static int hwts_init(int fd, const char *device, int 
rx_filter,
pr_err("ioctl SIOCSHWTSTAMP failed: %m");
return err;
}
+   if (cfg.rx_filter == HWTSTAMP_FILTER_SOME)
+   cfg.rx_filter = rx_filter;
break;
case HWTS_FILTER_NORMAL:
cfg.tx_type   = tx_type;
-   cfg.rx_filter = rx_filter;
+   cfg.rx_filter = orig_rx_filter = rx_filter;
err = ioctl(fd, SIOCSHWTSTAMP, );
if (err < 0) {
pr_info("driver rejected most general HWTSTAMP filter");

init_ifreq(, , device);
cfg.tx_type   = tx_type;
-   cfg.rx_filter = rx_filter2;
+   cfg.rx_filter = orig_rx_filter = rx_filter2;

err = ioctl(fd, SIOCSHWTSTAMP, );
if (err < 0) {
@@ -99,6 +102,8 @@ static int hwts_init(int fd, const char *device, int 
rx_filter,
return err;
}
}
+   if (cfg.rx_filter == HWTSTAMP_FILTER_SOME)
+   cfg.rx_filter = orig_rx_filter;
break;
}

--
2.20.1


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

[Geva, Erez]

Hi,

The "cfg.rx_filter != HWTSTAMP_FILTER_ALL)) { " 
  line catch both filter mode is "HWTS_FILTER_FULL, and the fact that the 
filter could is in a higher state for both HWTS_FILTER_NORMAL, 
HWTS_FILTER_CHECK.

Could you be more specific what does the HWTSTAMP_FILTER_SOME means?

For me, the HWTSTAMP_FILTER_SOME might be good when using filter mode 
"HWTS_FILTER_NORMAL".

But when filter mode is "HWTS_FILTER_FULL" I would accept that the flag will be 
HWTSTAMP_FILTER_ALL only.

What would you accept on filter mode HWTS_FILTER_CHECK?


Full state machine:

HWTS_FILTER_CHECK
get config
check if RX filter one of Rx filter 1, Rx filter 2, HWTSTAMP_FILTER_ALL
As HWTSTAMP_FILTER_ALL is a higher state

HWTS_FILTER_NORMAL
set Rx filter 1
if fail set Rx filter 2
check if RX filter one of Rx filter 1, Rx filter 2, HWTSTAMP_FILTER_ALL
As HWTSTAMP_FILTER_ALL is a higher state

HWTS_FILTER_FULL
set Rx filter HWTSTAMP_FILTER_ALL
check if RX filter one of Rx filter 1, Rx filter 2, HWTSTAMP_FILTER_ALL
Filter should be HWTSTAMP_FILTER_ALL, 
 but if NIc driver only set filter to be one of Rx filter 1, Rx filter 2 
then the PTP daemon may proceed normally.

Erez


From: Petr Machata [pe...@mellanox.com]
Sent: 10 June 2019 15:56
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

struct hwtstamp_config.rx_filter passed to SIOCSHWTSTAMP can be updated by
the kernel with the value of HWTSTAMP_FILTER_SOME. That indicates that all
requested packets will be timestamped, and some others as well.

Update hwts_init() to recognize this as a valid response, instead of
rejecting it as mismatch.

Signed-off-by: Petr Machata 
---

Notes:
v2: Fix whitespace.

 sk.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sk.c b/sk.c
index 93ba77a..416d784 100644
--- a/sk.c
+++ b/sk.c
@@ -105,7 +105,8 @@ static int hwts_init(int fd, const char *device, int 
rx_filter,
if (cfg.tx_type != tx_type ||
(cfg.rx_filter != rx_filter &&
 cfg.rx_filter != rx_filter2 &&
-cfg.rx_filter != HWTSTAMP_FILTER_ALL)) {
+cfg.rx_filter != HWTSTAMP_FILTER_ALL &&
+cfg.rx_filter != HWTSTAMP_FILTER_SOME)) {
pr_debug("tx_type   %d not %d", cfg.tx_type, tx_type);
pr_debug("rx_filter %d not %d or %d", cfg.rx_filter, rx_filter,
 rx_filter2);
--
2.20.1


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel