linuxptp-devel Mailing List for linuxptp (Page 3)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
You can subscribe to this list here.
2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(18) |
Jun
|
Jul
(96) |
Aug
(129) |
Sep
(67) |
Oct
(30) |
Nov
(56) |
Dec
(65) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2013 |
Jan
(72) |
Feb
(136) |
Mar
(75) |
Apr
(107) |
May
(183) |
Jun
(110) |
Jul
(158) |
Aug
(76) |
Sep
(108) |
Oct
(125) |
Nov
(47) |
Dec
(56) |
2014 |
Jan
(47) |
Feb
(73) |
Mar
(87) |
Apr
(74) |
May
(88) |
Jun
(151) |
Jul
(41) |
Aug
(8) |
Sep
(13) |
Oct
(19) |
Nov
(55) |
Dec
(45) |
2015 |
Jan
(15) |
Feb
(104) |
Mar
(79) |
Apr
(8) |
May
(20) |
Jun
(22) |
Jul
(19) |
Aug
(379) |
Sep
(17) |
Oct
(8) |
Nov
(35) |
Dec
(5) |
2016 |
Jan
(7) |
Feb
|
Mar
(9) |
Apr
(15) |
May
|
Jun
|
Jul
(70) |
Aug
(31) |
Sep
(26) |
Oct
(53) |
Nov
(14) |
Dec
(24) |
2017 |
Jan
(12) |
Feb
(29) |
Mar
(28) |
Apr
(34) |
May
(56) |
Jun
(67) |
Jul
(77) |
Aug
(97) |
Sep
(45) |
Oct
(40) |
Nov
(2) |
Dec
(24) |
2018 |
Jan
(56) |
Feb
(41) |
Mar
(233) |
Apr
(187) |
May
(51) |
Jun
(99) |
Jul
(100) |
Aug
(76) |
Sep
(74) |
Oct
(60) |
Nov
(92) |
Dec
(20) |
2019 |
Jan
(61) |
Feb
(51) |
Mar
(97) |
Apr
(13) |
May
(16) |
Jun
(34) |
Jul
(10) |
Aug
(7) |
Sep
(66) |
Oct
(56) |
Nov
(3) |
Dec
(20) |
2020 |
Jan
(6) |
Feb
(84) |
Mar
(81) |
Apr
(24) |
May
(90) |
Jun
(78) |
Jul
(21) |
Aug
(118) |
Sep
(16) |
Oct
(29) |
Nov
(115) |
Dec
(45) |
2021 |
Jan
(110) |
Feb
(77) |
Mar
(114) |
Apr
(74) |
May
(116) |
Jun
(25) |
Jul
(62) |
Aug
(36) |
Sep
(25) |
Oct
(58) |
Nov
(118) |
Dec
(9) |
2022 |
Jan
(66) |
Feb
(45) |
Mar
(115) |
Apr
(24) |
May
(105) |
Jun
(94) |
Jul
(80) |
Aug
(67) |
Sep
(69) |
Oct
(109) |
Nov
(77) |
Dec
(71) |
2023 |
Jan
(24) |
Feb
(108) |
Mar
(119) |
Apr
(81) |
May
(74) |
Jun
(112) |
Jul
(82) |
Aug
(23) |
Sep
(53) |
Oct
(33) |
Nov
(171) |
Dec
(42) |
From: Richard C. <ric...@gm...> - 2023-11-30 07:57:41
|
Signed-off-by: Richard Cochran <ric...@gm...> --- clock.c | 4 ++-- config.c | 2 +- interface.c | 12 ++++++++++-- interface.h | 10 +++++++++- pmc_common.c | 2 +- 5 files changed, 23 insertions(+), 7 deletions(-) diff --git a/clock.c b/clock.c index b66dda5..6f7722c 100644 --- a/clock.c +++ b/clock.c @@ -1242,7 +1242,7 @@ struct clock *clock_create(enum clock_type type, struct config *config, /* Configure the UDS. */ uds_ifname = config_get_string(config, NULL, "uds_address"); - c->uds_rw_if = interface_create(uds_ifname); + c->uds_rw_if = interface_create(uds_ifname, NULL); if (config_set_section_int(config, interface_name(c->uds_rw_if), "announceReceiptTimeout", 0)) { return NULL; @@ -1261,7 +1261,7 @@ struct clock *clock_create(enum clock_type type, struct config *config, } uds_ifname = config_get_string(config, NULL, "uds_ro_address"); - c->uds_ro_if = interface_create(uds_ifname); + c->uds_ro_if = interface_create(uds_ifname, NULL); if (config_set_section_int(config, interface_name(c->uds_ro_if), "announceReceiptTimeout", 0)) { return NULL; diff --git a/config.c b/config.c index ad675c8..fe65b76 100644 --- a/config.c +++ b/config.c @@ -896,7 +896,7 @@ struct interface *config_create_interface(const char *name, struct config *cfg) return iface; } - iface = interface_create(name); + iface = interface_create(name, NULL); if (!iface) { fprintf(stderr, "cannot allocate memory for a port\n"); return NULL; diff --git a/interface.c b/interface.c index 9a83c36..e088e07 100644 --- a/interface.c +++ b/interface.c @@ -12,12 +12,13 @@ struct interface { STAILQ_ENTRY(interface) list; char name[MAX_IFNAME_SIZE + 1]; char ts_label[MAX_IFNAME_SIZE + 1]; + char remote[MAX_IFNAME_SIZE + 1]; struct sk_ts_info ts_info; struct sk_if_info if_info; int vclock; }; -struct interface *interface_create(const char *name) +struct interface *interface_create(const char *name, const char *remote) { struct interface *iface; @@ -27,6 +28,9 @@ struct interface *interface_create(const char *name) } strncpy(iface->name, name, MAX_IFNAME_SIZE); strncpy(iface->ts_label, name, MAX_IFNAME_SIZE); + if (remote) { + strncpy(iface->remote, remote, MAX_IFNAME_SIZE); + } iface->vclock = -1; return iface; @@ -57,7 +61,6 @@ bool interface_ifinfo_valid(struct interface *iface) return iface->if_info.valid ? true : false; } - const char *interface_name(struct interface *iface) { return iface->name; @@ -68,6 +71,11 @@ int interface_phc_index(struct interface *iface) return iface->ts_info.phc_index; } +const char *interface_remote(struct interface *iface) +{ + return iface->remote; +} + void interface_set_label(struct interface *iface, const char *label) { strncpy(iface->ts_label, label, MAX_IFNAME_SIZE); diff --git a/interface.h b/interface.h index 0873bba..b56adc5 100644 --- a/interface.h +++ b/interface.h @@ -23,9 +23,10 @@ struct interface; /** * Creates an instance of an interface. * @param name The device which indentifies this interface. + * @param remote For UDS interfaces, the address of the remote server, possibly NULL. * @return A pointer to an interface instance on success, NULL otherwise. */ -struct interface *interface_create(const char *name); +struct interface *interface_create(const char *name, const char *remote); /** * Destroys an instance of an interface. @@ -70,6 +71,13 @@ const char *interface_name(struct interface *iface); */ int interface_phc_index(struct interface *iface); +/** + * Obtains the remote address from a UDS interface. + * @param iface The interface of interest. + * @return The device name of the network interface. + */ +const char *interface_remote(struct interface *iface); + /** * Set the time stamping label of a given interface. * @param iface The interface of interest. diff --git a/pmc_common.c b/pmc_common.c index 62e34a6..5092c09 100644 --- a/pmc_common.c +++ b/pmc_common.c @@ -524,7 +524,7 @@ struct pmc *pmc_create(struct config *cfg, enum transport_type transport_type, goto failed; } - pmc->iface = interface_create(iface_name); + pmc->iface = interface_create(iface_name, NULL); if (!pmc->iface) { pr_err("failed to create interface"); goto failed; -- 2.39.2 |
From: Richard C. <ric...@gm...> - 2023-11-30 07:57:38
|
Signed-off-by: Richard Cochran <ric...@gm...> --- pmc.c | 6 ++++-- pmc_agent.c | 3 ++- pmc_common.c | 8 ++++---- pmc_common.h | 6 +++--- tz2alt.c | 3 ++- uds.c | 6 ++++-- 6 files changed, 19 insertions(+), 13 deletions(-) diff --git a/pmc.c b/pmc.c index 9faf790..d18fea0 100644 --- a/pmc.c +++ b/pmc.c @@ -823,8 +823,10 @@ int main(int argc, char *argv[]) print_set_syslog(1); print_set_verbose(1); - pmc = pmc_create(cfg, transport_type, iface_name, boundary_hops, - domain_number, transport_specific, zero_datalen); + pmc = pmc_create(cfg, transport_type, iface_name, + config_get_string(cfg, NULL, "uds_address"), + boundary_hops, domain_number, transport_specific, + zero_datalen); if (!pmc) { fprintf(stderr, "failed to create pmc\n"); config_destroy(cfg); diff --git a/pmc_agent.c b/pmc_agent.c index 494c174..fec6dea 100644 --- a/pmc_agent.c +++ b/pmc_agent.c @@ -232,7 +232,8 @@ int run_pmc_wait_sync(struct pmc_agent *node, int timeout) int init_pmc_node(struct config *cfg, struct pmc_agent *node, const char *uds, pmc_node_recv_subscribed_t *recv_subscribed, void *context) { - node->pmc = pmc_create(cfg, TRANS_UDS, uds, 0, + node->pmc = pmc_create(cfg, TRANS_UDS, uds, + config_get_string(cfg, NULL, "uds_address"), 0, config_get_int(cfg, NULL, "domainNumber"), config_get_int(cfg, NULL, "transportSpecific") << 4, 1); if (!node->pmc) { diff --git a/pmc_common.c b/pmc_common.c index 5092c09..fca16c6 100644 --- a/pmc_common.c +++ b/pmc_common.c @@ -488,9 +488,9 @@ struct pmc { }; struct pmc *pmc_create(struct config *cfg, enum transport_type transport_type, - const char *iface_name, UInteger8 boundary_hops, - UInteger8 domain_number, UInteger8 transport_specific, - int zero_datalen) + const char *iface_name, const char *remote_address, + UInteger8 boundary_hops, UInteger8 domain_number, + UInteger8 transport_specific, int zero_datalen) { struct pmc *pmc; UInteger32 proc_id; @@ -524,7 +524,7 @@ struct pmc *pmc_create(struct config *cfg, enum transport_type transport_type, goto failed; } - pmc->iface = interface_create(iface_name, NULL); + pmc->iface = interface_create(iface_name, remote_address); if (!pmc->iface) { pr_err("failed to create interface"); goto failed; diff --git a/pmc_common.h b/pmc_common.h index 6fb2fae..355b2c0 100644 --- a/pmc_common.h +++ b/pmc_common.h @@ -29,9 +29,9 @@ struct pmc; struct pmc *pmc_create(struct config *cfg, enum transport_type transport_type, - const char *iface_name, UInteger8 boundary_hops, - UInteger8 domain_number, UInteger8 transport_specific, - int zero_datalen); + const char *iface_name, const char *remote_address, + UInteger8 boundary_hops, UInteger8 domain_number, + UInteger8 transport_specific, int zero_datalen); void pmc_destroy(struct pmc *pmc); diff --git a/tz2alt.c b/tz2alt.c index feb77a5..65b5835 100644 --- a/tz2alt.c +++ b/tz2alt.c @@ -181,7 +181,8 @@ static int update_ptp_serivce(struct tzinfo *tz, struct tzinfo *next) struct pmc *pmc; int err; - pmc = pmc_create(cfg, TRANS_UDS, uds_local, 0, + pmc = pmc_create(cfg, TRANS_UDS, uds_local, + config_get_string(cfg, NULL, "uds_address"), 0, config_get_int(cfg, NULL, "domainNumber"), config_get_int(cfg, NULL, "transportSpecific") << 4, 1); if (!pmc) { diff --git a/uds.c b/uds.c index 6d39dc8..fafb100 100644 --- a/uds.c +++ b/uds.c @@ -54,7 +54,7 @@ static int uds_open(struct transport *t, struct interface *iface, struct fdarray enum timestamp_type tt) { char *uds_ro_path = config_get_string(t->cfg, NULL, "uds_ro_address"); - char *uds_path = config_get_string(t->cfg, NULL, "uds_address"); + const char *uds_path = interface_remote(iface); struct uds *uds = container_of(t, struct uds, t); const char *name = interface_name(iface); const char* file_mode_cfg; @@ -89,7 +89,9 @@ static int uds_open(struct transport *t, struct interface *iface, struct fdarray /* For client use, pre load the server path. */ memset(&sa, 0, sizeof(sa)); sa.sun_family = AF_LOCAL; - strncpy(sa.sun_path, uds_path, sizeof(sa.sun_path) - 1); + if (uds_path) { + strncpy(sa.sun_path, uds_path, sizeof(sa.sun_path) - 1); + } uds->address.sun = sa; uds->address.len = sizeof(sa); -- 2.39.2 |
From: Richard C. <ric...@gm...> - 2023-11-30 07:57:35
|
This is how CMLD should be done, IMHO. Currently, because of the quirks of the UDS module, a program can be a PMC server or PMC client, but not both. Patches 1 and 2 address this issue, allowing ptp4l program to be both a UDS server and client. Still TODO: - replace hard coded 1-hour one shot subscription with renewal logic - man page update for new cmlds options Please review and test to shake out the bugs. Thanks, Richard Kishen Maloor (1): Implement the COMMON_P2P delay mechanism. Richard Cochran (4): interface: Add an optional remote address for use by the UDS transport. pmc/uds: Configure the remote server address using the interface API. Introduce the Common Mean Link Delay Information TLV. Add a push notification for the CMLDS TLV. clock.c | 5 +- config.c | 6 +- dm.h | 3 + fd.h | 1 + interface.c | 12 +++- interface.h | 10 ++- makefile | 4 +- notification.h | 1 + pmc.c | 21 ++++-- pmc_agent.c | 3 +- pmc_common.c | 23 ++++--- pmc_common.h | 6 +- port.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++-- port.h | 2 + port_private.h | 3 + tlv.c | 14 ++++ tlv.h | 6 ++ tz2alt.c | 3 +- uds.c | 6 +- 19 files changed, 275 insertions(+), 33 deletions(-) -- 2.39.2 |
From: Choong, C. L. <chw...@in...> - 2023-11-29 23:19:06
|
Hi Erez, Richard, Is it acceptable to preserve the current printing format in pmc.c (specifically, keeping the line IFMT “scaledLastGMPhaseChange %d” unchanged), while updating other parts of the code to “scaledLastGmFreqChange”, complying with IEEE AS Standards? Regards, CL From: Erez <ere...@gm...> Sent: Wednesday, November 29, 2023 6:51 PM To: Choong, Chwee Lin <chw...@in...> Cc: Richard Cochran <ric...@gm...>; lin...@li... Subject: Re: [Linuxptp-devel] [PATCH] Add scaledLastGmFreqChange computation Hi, I did not argue whether it is an error or not. Once an enterprise management TLV is published (by a linuxptp official version). The TLV is a public API. We should avoid changing them. If the case is really bad, we may create a new enterprise management TLV with the corrections. TIME_STATUS_NP was added in september 2012 and published in version 1.1. You can fix calculations of values in the TLV, but not sizes, types, order or NAMES. Wireshark should follow IEEE 1588 and linuxptp enterprise management TLVs, not the other way around. Erez On Wed, 29 Nov 2023 at 07:52, Choong, Chwee Lin <chw...@in...<mailto:chw...@in...>> wrote: Hi Erez, Richard, There's a potential misunderstanding among users who may believe that both lastGmPhaseChange and scaledLastGmPhaseChange are derived from phase measurements, with the latter representing a scaled version of the former. This assumption, particularly evident when they are displayed simultaneously in the PMC readout Additionally, it's worth noting that Wireshark has already addressed a similar naming discrepancy: https://www.wireshark.org/lists/wireshark-bugs//201602/msg00662.html<https://www.wireshark.org/lists/wireshark-bugs/201602/msg00662.html> Thanks CL -----Original Message----- From: Richard Cochran <ric...@gm...<mailto:ric...@gm...>> Sent: Tuesday, November 28, 2023 7:42 AM To: Erez <ere...@gm...<mailto:ere...@gm...>> Cc: Choong, Chwee Lin <chw...@in...<mailto:chw...@in...>>; lin...@li...<mailto:lin...@li...> Subject: Re: [Linuxptp-devel] [PATCH] Add scaledLastGmFreqChange computation On Mon, Nov 27, 2023 at 10:20:56AM +0100, Erez wrote: > It is public if you change the printed name in PMC. You mean scripts that invoke pmc? Yeah, that could cause users' setups to break. Thanks, Richard |
From: Erez <ere...@gm...> - 2023-11-29 23:07:40
|
On Wed, 29 Nov 2023 at 15:45, Paz Cohen <coh...@gm...> wrote: > I have noticed that "delay_timeout" returned by pmc with > "PORT_SERVICE_STATS_NP" is always increasing, even when rx delay responses > are arriving as expected. > It appears to happen because code flow does not get to resetting the delay > timeout(FD_DELAY_TIMER), unless poll woke on this fd. The problem is that > the delay_timeout counter is incremented together with the timer resetting. > What I expected is that when a legitimate delay response arrives, the > timer should reset. > This is a developers mailing list. You are welcome to find the error and send a patch to fix it. > If I understand the behavior correctly, then delay response timeouts > cannot be detected by pmc. > PMC is not a detection tool. It just retrieves information from the ptp4l service. If you find a "wrong" value, it probably comes from the ptp4l service itself. Erez > > BR, > Paz > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > |
From: Vladimir O. <ol...@gm...> - 2023-11-29 17:19:25
|
Hi Ilia, On Fri, Nov 24, 2023 at 10:29:12PM +0300, IlorDash wrote: > From: Ilya Orazov <ilo...@gm...> > > I’m using an Ethernet controller with PTP support, which requires > determining which PTP packets on RX must be timestamped: SYNC or > DELAY_REQ, based on whether the device is Slave or Master respectively. > So I can’t use the EVENT RX filter and must dynamically switch RX > filters, when port state changes from Master to Slave and vice versa. > > Therefore this feature adds support for DELAY_REQ and SYNC packets > RX filters. If the interface doesn’t support the EVENT RX filter > (getting info about it through ethtool) then RX filters will dynamically > switch between SYNC and DELAY_REQ when port state changes. > > Signed-off-by: Ilya Orazov <ilo...@gm...> > --- What hardware are you targeting, specifically? I know the KSZ9477 DSA switch family has this quirk as well. |
From: Paz C. <coh...@gm...> - 2023-11-29 14:43:45
|
I have noticed that "delay_timeout" returned by pmc with "PORT_SERVICE_STATS_NP" is always increasing, even when rx delay responses are arriving as expected. It appears to happen because code flow does not get to resetting the delay timeout(FD_DELAY_TIMER), unless poll woke on this fd. The problem is that the delay_timeout counter is incremented together with the timer resetting. What I expected is that when a legitimate delay response arrives, the timer should reset. If I understand the behavior correctly, then delay response timeouts cannot be detected by pmc. BR, Paz |
From: Erez <ere...@gm...> - 2023-11-29 12:42:38
|
On Wed, 29 Nov 2023 at 13:09, Miroslav Lichvar <mli...@re...> wrote: > On Tue, Nov 28, 2023 at 03:34:54PM -0800, Richard Cochran wrote: > > On Tue, Nov 28, 2023 at 12:53:38PM +0100, Miroslav Lichvar wrote: > > > However, timestamping only sync messages has an advantage with very > > > large number of clients as they don't have timestamp each other's > > > delay requets and timestamping of sync messages is more reliable. > > > > Actually, in hardware is it much simpler and more efficient just to > > time stamp every frame. (The reporting can be selectable if the > > application doesn't care about some frame types) > > I think it depends on the hardware design, which impacts its cost. If > all hardware was able to accurately and reliably timestamp all > packets, we wouldn't need PTP. PTP was specifically designed to make > the hardware support as simple/cheap as possible. It separates event > messages from the rest and uses multicast messaging in order to reduce > the required timestamping rate. > Although PTP uses multicast. It is only a multicast MAC address, but it is not a real multicast group. As PTP messages are not forward to all peers as is. So PTP messages are actually unicast messages.using a multicast MAC address. > > Timestamping only sync messages on clients is just another trick to > reduce the required timestamping rate. The hardware can keep just one > timestamp at a time and it doesn't matter that if it takes 20 > milliseconds to read it over MDIO. It's good enough for clients, even > if there is a very large number of them on the same communication > path. > It Makes sense, yet using a PTP events filter is sufficient. The PTP service is a master or client, not both. So the amount of traffic you timestamp does not reduce by using a SYNC/ DELY versa events filter. Erez > > -- > Miroslav Lichvar > > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > |
From: Miroslav L. <mli...@re...> - 2023-11-29 12:07:36
|
On Tue, Nov 28, 2023 at 03:34:54PM -0800, Richard Cochran wrote: > On Tue, Nov 28, 2023 at 12:53:38PM +0100, Miroslav Lichvar wrote: > > However, timestamping only sync messages has an advantage with very > > large number of clients as they don't have timestamp each other's > > delay requets and timestamping of sync messages is more reliable. > > Actually, in hardware is it much simpler and more efficient just to > time stamp every frame. (The reporting can be selectable if the > application doesn't care about some frame types) I think it depends on the hardware design, which impacts its cost. If all hardware was able to accurately and reliably timestamp all packets, we wouldn't need PTP. PTP was specifically designed to make the hardware support as simple/cheap as possible. It separates event messages from the rest and uses multicast messaging in order to reduce the required timestamping rate. Timestamping only sync messages on clients is just another trick to reduce the required timestamping rate. The hardware can keep just one timestamp at a time and it doesn't matter that if it takes 20 milliseconds to read it over MDIO. It's good enough for clients, even if there is a very large number of them on the same communication path. -- Miroslav Lichvar |
From: Erez <ere...@gm...> - 2023-11-29 10:52:09
|
Hi, I did not argue whether it is an error or not. Once an enterprise management TLV is published (by a linuxptp official version). The TLV is a public API. We should avoid changing them. If the case is really bad, we may create a new enterprise management TLV with the corrections. TIME_STATUS_NP was added in september 2012 and published in version 1.1. You can fix calculations of values in the TLV, but not sizes, types, order or *NAMES*. Wireshark should follow IEEE 1588 and linuxptp enterprise management TLVs, not the other way around. Erez On Wed, 29 Nov 2023 at 07:52, Choong, Chwee Lin <chw...@in...> wrote: > Hi Erez, Richard, > > There's a potential misunderstanding among users who may believe that both > lastGmPhaseChange and scaledLastGmPhaseChange are derived from phase > measurements, with the latter representing a scaled version of the former. > This assumption, particularly evident when they are displayed > simultaneously in the PMC readout > > Additionally, it's worth noting that Wireshark has already addressed a > similar naming discrepancy: > https://www.wireshark.org/lists/wireshark-bugs//201602/msg00662.html > > Thanks > CL > > -----Original Message----- > From: Richard Cochran <ric...@gm...> > Sent: Tuesday, November 28, 2023 7:42 AM > To: Erez <ere...@gm...> > Cc: Choong, Chwee Lin <chw...@in...>; > lin...@li... > Subject: Re: [Linuxptp-devel] [PATCH] Add scaledLastGmFreqChange > computation > > On Mon, Nov 27, 2023 at 10:20:56AM +0100, Erez wrote: > > It is public if you change the printed name in PMC. > > You mean scripts that invoke pmc? > > Yeah, that could cause users' setups to break. > > Thanks, > Richard > |
From: Choong, C. L. <chw...@in...> - 2023-11-29 06:52:56
|
Hi Erez, Richard, There's a potential misunderstanding among users who may believe that both lastGmPhaseChange and scaledLastGmPhaseChange are derived from phase measurements, with the latter representing a scaled version of the former. This assumption, particularly evident when they are displayed simultaneously in the PMC readout Additionally, it's worth noting that Wireshark has already addressed a similar naming discrepancy: https://www.wireshark.org/lists/wireshark-bugs//201602/msg00662.html Thanks CL -----Original Message----- From: Richard Cochran <ric...@gm...> Sent: Tuesday, November 28, 2023 7:42 AM To: Erez <ere...@gm...> Cc: Choong, Chwee Lin <chw...@in...>; lin...@li... Subject: Re: [Linuxptp-devel] [PATCH] Add scaledLastGmFreqChange computation On Mon, Nov 27, 2023 at 10:20:56AM +0100, Erez wrote: > It is public if you change the printed name in PMC. You mean scripts that invoke pmc? Yeah, that could cause users' setups to break. Thanks, Richard |
From: Richard C. <ric...@gm...> - 2023-11-29 01:26:34
|
On Tue, Nov 28, 2023 at 12:53:38PM +0100, Miroslav Lichvar wrote: > On Sun, Nov 26, 2023 at 11:10:05AM -0800, Richard Cochran wrote: > > The Rx filters are applied globally at the device level, but the PTP > > operates at the application level. This means that the Rx filter are > > shared between applications. And so you can see that one application > > cannot simply change the shared global settings at run time. > > This problem already exists, e.g. with ptpv2-l4-event vs ptpv2-l2-event. That is totally different. As long as the HW supports the given transport, then it works. > If the > hardware which cannot timestamp all event messages is very rare, ok, > maybe it's not worth the trouble. And it simply cannot work in real life. > However, timestamping only sync messages has an advantage with very > large number of clients as they don't have timestamp each other's > delay requets and timestamping of sync messages is more reliable. Actually, in hardware is it much simpler and more efficient just to time stamp every frame. (The reporting can be selectable if the application doesn't care about some frame types) |
From: Bilal O. <bil...@ho...> - 2023-11-28 20:03:07
|
>> PTP traffic by its nature is very low. >> I do not see any benefit for a filter that supports only client or only >> master PTP traffic. >That argument does not hold up in the datacenter. Once you scale up to >100000 nodes @128pps trying to synchronize to a GM it's no longer what > I'd consider "very low". Furthermore, considering a TSN context where a low cycle time, for instance 0.5ms, and a lower sync interval of -5(e.g., logSyncInterval=-5) is needed then the PTP traffic is no longer "very low". hence it worth the trouble. If the tx poll time(out) is also considered then it makes sense to reduce this overhead for the critical real time application. Best regards Bilal ________________________________ From: Maciek Machnikowski <ma...@ma...> Sent: 28 November 2023 18:25 To: lin...@li... <lin...@li...> Subject: Re: [Linuxptp-devel] [PATCH v2] Add support for DELAY_REQ and SYNC packets RX filters On 28/11/2023 14:39, Erez wrote: > > > On Tue, 28 Nov 2023 at 12:55, Miroslav Lichvar <mli...@re... > <mailto:mli...@re...>> wrote: > > On Sun, Nov 26, 2023 at 11:10:05AM -0800, Richard Cochran wrote: > > The Rx filters are applied globally at the device level, but the PTP > > operates at the application level. This means that the Rx filter are > > shared between applications. And so you can see that one application > > cannot simply change the shared global settings at run time. > > This problem already exists, e.g. with ptpv2-l4-event vs ptpv2-l2-event. > We could say that all hardware that cannot timestamp all packets is > broken, but it's so common that it has to be supported. If the > hardware which cannot timestamp all event messages is very rare, ok, > maybe it's not worth the trouble. > > However, timestamping only sync messages has an advantage with very > large number of clients as they don't have timestamp each other's > delay requets and timestamping of sync messages is more reliable. > > > PTP traffic by its nature is very low. > I do not see any benefit for a filter that supports only client or only > master PTP traffic. That argument does not hold up in the datacenter. Once you scale up to 100000 nodes @128pps trying to synchronize to a GM it's no longer what I'd consider "very low". Thanks, Maciek > > Perhaps the kernel should add a HWTSTAMP_FILTER_PTP_V2_ALL_EVENT, > that supports multiple PTP services on several layers. > > Erez > > > -- > Miroslav Lichvar > > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > <https://lists.sourceforge.net/lists/listinfo/linuxptp-devel> > > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel _______________________________________________ Linuxptp-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
From: Maciek M. <ma...@ma...> - 2023-11-28 17:25:49
|
On 28/11/2023 14:39, Erez wrote: > > > On Tue, 28 Nov 2023 at 12:55, Miroslav Lichvar <mli...@re... > <mailto:mli...@re...>> wrote: > > On Sun, Nov 26, 2023 at 11:10:05AM -0800, Richard Cochran wrote: > > The Rx filters are applied globally at the device level, but the PTP > > operates at the application level. This means that the Rx filter are > > shared between applications. And so you can see that one application > > cannot simply change the shared global settings at run time. > > This problem already exists, e.g. with ptpv2-l4-event vs ptpv2-l2-event. > We could say that all hardware that cannot timestamp all packets is > broken, but it's so common that it has to be supported. If the > hardware which cannot timestamp all event messages is very rare, ok, > maybe it's not worth the trouble. > > However, timestamping only sync messages has an advantage with very > large number of clients as they don't have timestamp each other's > delay requets and timestamping of sync messages is more reliable. > > > PTP traffic by its nature is very low. > I do not see any benefit for a filter that supports only client or only > master PTP traffic. That argument does not hold up in the datacenter. Once you scale up to 100000 nodes @128pps trying to synchronize to a GM it's no longer what I'd consider "very low". Thanks, Maciek > > Perhaps the kernel should add a HWTSTAMP_FILTER_PTP_V2_ALL_EVENT, > that supports multiple PTP services on several layers. > > Erez > > > -- > Miroslav Lichvar > > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > <https://lists.sourceforge.net/lists/listinfo/linuxptp-devel> > > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
From: walfred t. <wte...@go...> - 2023-11-28 17:07:25
|
Thank you very much Richard! Best regards, -Fred On Thu, Nov 16, 2023 at 6:23 AM Richard Cochran <ric...@gm...> wrote: > On Mon, Aug 21, 2023 at 10:44:27AM +0200, Walfred Tedeschi wrote: > > On 11.08.23 19:13, Richard Cochran wrote: > > > The CMLDS series will require careful review. My superficial review > > > gave me the impression that the approach was too complex. > > Do you have an indication on how it could be simplified? > > I commented on the v2 patch series just now. > > Thanks, > Richard > |
From: Paz C. <coh...@gm...> - 2023-11-28 15:45:48
|
pmc can specify which domainNumber to use (-d flag), default is domain 0, but sometimes the domain is not 0 Therefore the pmc is not as independent as it can be, for example when working with unicast profiles whose default domain is not 0. The idea is that the pmc does not know in advance which domain to use and must be configured with it. >From what I have seen, the pmc call is marked to be ignored in port_ignore() One option is to check whether the port is uds(if domain1 != domain2 && port is not uds) which I believe is relatively secure, but is not affecting other transport options. Paz |
From: Erez <ere...@gm...> - 2023-11-28 13:40:06
|
On Tue, 28 Nov 2023 at 12:55, Miroslav Lichvar <mli...@re...> wrote: > On Sun, Nov 26, 2023 at 11:10:05AM -0800, Richard Cochran wrote: > > The Rx filters are applied globally at the device level, but the PTP > > operates at the application level. This means that the Rx filter are > > shared between applications. And so you can see that one application > > cannot simply change the shared global settings at run time. > > This problem already exists, e.g. with ptpv2-l4-event vs ptpv2-l2-event. > We could say that all hardware that cannot timestamp all packets is > broken, but it's so common that it has to be supported. If the > hardware which cannot timestamp all event messages is very rare, ok, > maybe it's not worth the trouble. > > However, timestamping only sync messages has an advantage with very > large number of clients as they don't have timestamp each other's > delay requets and timestamping of sync messages is more reliable. > PTP traffic by its nature is very low. I do not see any benefit for a filter that supports only client or only master PTP traffic. Perhaps the kernel should add a HWTSTAMP_FILTER_PTP_V2_ALL_EVENT, that supports multiple PTP services on several layers. Erez > -- > Miroslav Lichvar > > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > |
From: Miroslav L. <mli...@re...> - 2023-11-28 11:53:56
|
On Sun, Nov 26, 2023 at 11:10:05AM -0800, Richard Cochran wrote: > The Rx filters are applied globally at the device level, but the PTP > operates at the application level. This means that the Rx filter are > shared between applications. And so you can see that one application > cannot simply change the shared global settings at run time. This problem already exists, e.g. with ptpv2-l4-event vs ptpv2-l2-event. We could say that all hardware that cannot timestamp all packets is broken, but it's so common that it has to be supported. If the hardware which cannot timestamp all event messages is very rare, ok, maybe it's not worth the trouble. However, timestamping only sync messages has an advantage with very large number of clients as they don't have timestamp each other's delay requets and timestamping of sync messages is more reliable. -- Miroslav Lichvar |
From: Erez <ere...@gm...> - 2023-11-28 11:38:28
|
Hi, Debian builds allow using patches during building of Debian packages. Erez On Tue, 28 Nov 2023 at 00:48, Richard Cochran <ric...@gm...> wrote: > On Mon, Nov 27, 2023 at 10:47:48AM +0300, IlorDash wrote: > > Thanks, Richard, for such a detailed answer! > > I'll try to find another solution to handle it. > > You can always keep your patches for your custom build. After all, it > is open source, free for you to adapt. But I don't want to include > those changes in the main project code base. > > Thanks, > Richard > > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > |
From: Richard C. <ric...@gm...> - 2023-11-27 23:47:03
|
On Mon, Nov 27, 2023 at 10:47:48AM +0300, IlorDash wrote: > Thanks, Richard, for such a detailed answer! > I'll try to find another solution to handle it. You can always keep your patches for your custom build. After all, it is open source, free for you to adapt. But I don't want to include those changes in the main project code base. Thanks, Richard |
From: Richard C. <ric...@gm...> - 2023-11-27 23:42:40
|
On Mon, Nov 27, 2023 at 10:20:56AM +0100, Erez wrote: > It is public if you change the printed name in PMC. You mean scripts that invoke pmc? Yeah, that could cause users' setups to break. Thanks, Richard |
From: Erez <ere...@gm...> - 2023-11-27 09:21:42
|
On Sun, 26 Nov 2023 at 22:07, Richard Cochran <ric...@gm...> wrote: > On Thu, Nov 23, 2023 at 01:39:45PM +0100, Erez wrote: > > On Thu, 23 Nov 2023 at 04:26, Chwee-Lin Choong < > chw...@in...> > > wrote: > > > > > Add the computation for scaledLastGmFreqChange, as specified in > > > IEEE 802.1AS-2020, clause 11.4.4.3.9. This incorporates the > > > necessary logic to calculate scaledLastGmFreqChange and > > > appends the result to the follow-up TLV. > > > > > > In addition, a naming error has been rectified from > > > scaledLastGmPhaseChange to scaledLastGmFreqChange. > > > > > > > It might be an error, but we do not change a public API. > > As some users might depend on it. > > No, this does not break an API/ABI. The name of a field in a header > file is a C language identifier, and it does not exist at run time. > > (Changing the size, type, or position of a field, now THAT would break > the ABI) > It is public if you change the printed name in PMC. Erez > > Thanks, > Richard > > |
From: IlorDash <ilo...@gm...> - 2023-11-27 07:48:05
|
Thanks, Richard, for such a detailed answer! I'll try to find another solution to handle it. On Sun, 26 Nov 2023 at 22:10, Richard Cochran <ric...@gm...> wrote: > On Sun, Nov 26, 2023 at 01:38:15PM +0300, IlorDash wrote: > > Could you, please, explain why you think my hardware is broken? I > thought, > > since SYNC and DELAY_REQ filters are defined in Linux, ptp4l can use them > > to set type-specific hardware filters. > > Here is another reason why: > > The Rx filters are applied globally at the device level, but the PTP > operates at the application level. This means that the Rx filter are > shared between applications. And so you can see that one application > cannot simply change the shared global settings at run time. > > For example, multiple ptp4l instances running different PTP Domains on > the same network interface using virtual PHCs will have different port > roles at the same time. > > Thanks, > Richard > -- Best regards, Ilya Orazov |
From: Richard C. <ric...@gm...> - 2023-11-26 21:35:36
|
On Wed, Nov 08, 2023 at 03:14:04AM +0800, Chwee-Lin Choong wrote: > The patches aim to enhance the handling of multiple pdelay responses. > These improvements are aligned with both IEEE 802.1AS-2011 and > IEEE 802.1AS-2020 standards. > > The first patch introduces configurability for 'allowedLostResponses' > as a per-port parameter. This adjustment aligns with IEEE 802.1AS-2020 > standards, which specify a default value of 9 while allowing a range > of values from 1 to 255. > > The second patch refines the detection and management of multiple > pdelay responses, whether from the same peer or distinct peers. > These refinements ensure that the handling of multiple pdelay responses > is now based on the 'allowedLostResponses' threshold. > > These modifications have been validated following Avnu Alliance > Test Plan for '802.1AS Time Synchronization' > > Kishen Maloor (1): > Make allowedLostResponses configurable > > Chwee-Lin Choong (1): > port: Fix multiple pdelay response handling Series applied. Thanks, Richard |
From: Richard C. <ric...@gm...> - 2023-11-26 21:07:13
|
On Thu, Nov 23, 2023 at 01:39:45PM +0100, Erez wrote: > On Thu, 23 Nov 2023 at 04:26, Chwee-Lin Choong <chw...@in...> > wrote: > > > Add the computation for scaledLastGmFreqChange, as specified in > > IEEE 802.1AS-2020, clause 11.4.4.3.9. This incorporates the > > necessary logic to calculate scaledLastGmFreqChange and > > appends the result to the follow-up TLV. > > > > In addition, a naming error has been rectified from > > scaledLastGmPhaseChange to scaledLastGmFreqChange. > > > > It might be an error, but we do not change a public API. > As some users might depend on it. No, this does not break an API/ABI. The name of a field in a header file is a C language identifier, and it does not exist at run time. (Changing the size, type, or position of a field, now THAT would break the ABI) Thanks, Richard |