[Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry correction

[Richard Cochran]

* ChangeLog
** V2
- rename the configuration options to match those in the standards

Most (or all?) hardware provides time stamps that are offset from the
actual point at the reference plane. The amount of delay is asymmetrical
between ingress and egress, and depending on the particular technology,
MAC or PHY, and link speed, there can be jitter in the delay.

Sometimes the manufacturer specifies the amount of expected delay. This
patch series provides a way for the user to correct the delays based on
values from the data sheet or based on empirical data.

This series was tested with an i210 paired with a dp83640 using a short
cable. These devices have their delay values listed in the data sheet.
PPS signals in both directions showed a remaining offset of about 120
nanoseconds, which matches the sum of uncertainties (40 and 80) given
for the i210 card at the 100 MBit link speed.

Comments are welcome.

Thanks,
Richard


Richard Cochran (4):
Introduce a helper function to identify valid (non-zero) time stamps.
Invoke the clock check even if the time stamp nanoseconds field is
zero.
config: Introduce options for correcting transmit and receive delays.
port: correct transmit and receive time stamps for their calibrated
delays.

config.c | 12 ++++++++++++
default.cfg | 2 ++
ds.h | 2 ++
gPTP.cfg | 2 ++
msg.c | 2 +-
msg.h | 10 ++++++++++
port.c | 35 ++++++++++++++++++++++++++++++++---
ptp4l.8 | 12 ++++++++++++
ptp4l.c | 2 ++
9 files changed, 75 insertions(+), 4 deletions(-)

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
msg.c | 2 +-
msg.h | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/msg.c b/msg.c
index 7edbdd2..06a3812 100644
--- a/msg.c
+++ b/msg.c
@@ -468,5 +468,5 @@ int msg_sots_missing(struct ptp_message *m)
default:
return 0;
}
- return (!m->hwts.ts.tv_sec && !m->hwts.ts.tv_nsec) ? 1 : 0;
+ return msg_sots_valid(m) ? 0 : 1;
}
diff --git a/msg.h b/msg.h
index 3fa5833..12e6ce8 100644
--- a/msg.h
+++ b/msg.h
@@ -339,6 +339,16 @@ void msg_put(struct ptp_message *m);
int msg_sots_missing(struct ptp_message *m);

/**
+ * Test whether a message has a valid SO_TIMESTAMPING time stamp.
+ * @param m Message to test.
+ * @return One if the message has a valid time stamp, zero otherwise.
+ */
+static inline int msg_sots_valid(struct ptp_message *m)
+{
+ return (m->hwts.ts.tv_sec || m->hwts.ts.tv_nsec) ? 1 : 0;
+}
+
+/**
* Work around buggy 802.1AS switches.
*/
extern int assume_two_step;

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/port.c b/port.c
index 475d3e4..25265f7 100644
--- a/port.c
+++ b/port.c
@@ -2188,7 +2188,7 @@ enum fsm_event port_event(struct port *p, int fd_index)
msg_put(msg);
return EV_NONE;
}
- if (msg->hwts.ts.tv_sec && msg->hwts.ts.tv_nsec) {
+ if (msg_sots_valid(msg)) {
clock_check_ts(p->clock, msg->hwts.ts);
}
if (port_ignore(p, msg)) {

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
config.c | 12 ++++++++++++
default.cfg | 2 ++
ds.h | 2 ++
gPTP.cfg | 2 ++
ptp4l.8 | 12 ++++++++++++
ptp4l.c | 2 ++
6 files changed, 32 insertions(+)

diff --git a/config.c b/config.c
index d5fa378..7679f44 100644
--- a/config.c
+++ b/config.c
@@ -132,6 +132,18 @@ static enum parser_result parse_pod_setting(const char *option,
return r;
pod->min_neighbor_prop_delay = val;

+ } else if (!strcmp(option, "egressLatency")) {
+ r = get_ranged_int(value, &val, INT_MIN, INT_MAX);
+ if (r != PARSED_OK)
+ return r;
+ pod->tx_timestamp_offset = val;
+
+ } else if (!strcmp(option, "ingressLatency")) {
+ r = get_ranged_int(value, &val, INT_MIN, INT_MAX);
+ if (r != PARSED_OK)
+ return r;
+ pod->rx_timestamp_offset = val;
+
} else if (!strcmp(option, "fault_badpeernet_interval")) {
pod->flt_interval_pertype[FT_BAD_PEER_NETWORK].type = FTMO_LINEAR_SECONDS;
if (!strcasecmp("ASAP", value)) {
diff --git a/default.cfg b/default.cfg
index 9e794ba..0e20726 100644
--- a/default.cfg
+++ b/default.cfg
@@ -70,6 +70,8 @@ delay_mechanism E2E
time_stamping hardware
delay_filter moving_median
delay_filter_length 10
+egressLatency 0
+ingressLatency 0
#
# Clock description
#
diff --git a/ds.h b/ds.h
index ea25fbb..00260ed 100644
--- a/ds.h
+++ b/ds.h
@@ -137,6 +137,8 @@ struct port_defaults {
struct fault_interval flt_interval_pertype[FT_CNT];
UInteger32 neighborPropDelayThresh; /*nanoseconds*/
int min_neighbor_prop_delay; /*nanoseconds*/
+ int tx_timestamp_offset; /*nanoseconds*/
+ int rx_timestamp_offset; /*nanoseconds*/
};

#endif
diff --git a/gPTP.cfg b/gPTP.cfg
index e15a05a..689abd8 100644
--- a/gPTP.cfg
+++ b/gPTP.cfg
@@ -69,3 +69,5 @@ delay_mechanism P2P
time_stamping hardware
delay_filter moving_median
delay_filter_length 10
+egressLatency 0
+ingressLatency 0
diff --git a/ptp4l.8 b/ptp4l.8
index 687beb6..bee42e9 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -205,6 +205,18 @@ The default is moving_median.
.B delay_filter_length
The length of the delay filter in samples.
The default is 10.
+.TP
+.B egressLatency
+Specifies the difference in nanoseconds between the actual transmission
+time at the reference plane and the reported transmit time stamp. This
+value will be added to egress time stamps obtained from the hardware.
+The default is 0.
+.TP
+.B ingressLatency
+Specifies the difference in nanoseconds between the reported receive
+time stamp and the actual reception time at reference plane. This value
+will be subtracted from ingress time stamps obtained from the hardware.
+The default is 0.

.SH PROGRAM AND CLOCK OPTIONS

diff --git a/ptp4l.c b/ptp4l.c
index 83824f7..c18406f 100644
--- a/ptp4l.c
+++ b/ptp4l.c
@@ -92,6 +92,8 @@ static struct config cfg_settings = {
/* Default to very a large neighborPropDelay threshold */
.neighborPropDelayThresh = 20000000,
.min_neighbor_prop_delay = -20000000,
+ .tx_timestamp_offset = 0,
+ .rx_timestamp_offset = 0,
},

.timestamping = TS_HARDWARE,

[Christian Riesch]

Hi Richard,

-----Original Message-----
Sent: Tuesday, December 09, 2014 9:55 PM
Subject: [Linuxptp-devel] [PATCH RFC V2 3/4] config: Introduce options for
correcting transmit and receive delays.

Note that egress and ingress timestamping delays change with link speed. So you might want to have a list of delays and apply the right one depending on link speed.
Regards,
Christian

---
config.c | 12 ++++++++++++
default.cfg | 2 ++
ds.h | 2 ++
gPTP.cfg | 2 ++
ptp4l.8 | 12 ++++++++++++
ptp4l.c | 2 ++
6 files changed, 32 insertions(+)
diff --git a/config.c b/config.c
index d5fa378..7679f44 100644
--- a/config.c
+++ b/config.c
@@ -132,6 +132,18 @@ static enum parser_result parse_pod_setting(const char *option,
return r;
pod->min_neighbor_prop_delay = val;
+ } else if (!strcmp(option, "egressLatency")) {
+ r = get_ranged_int(value, &val, INT_MIN, INT_MAX);
+ if (r != PARSED_OK)
+ return r;
+ pod->tx_timestamp_offset = val;
+
+ } else if (!strcmp(option, "ingressLatency")) {
+ r = get_ranged_int(value, &val, INT_MIN, INT_MAX);
+ if (r != PARSED_OK)
+ return r;
+ pod->rx_timestamp_offset = val;
+
} else if (!strcmp(option, "fault_badpeernet_interval")) {
pod->flt_interval_pertype[FT_BAD_PEER_NETWORK].type =
FTMO_LINEAR_SECONDS;
if (!strcasecmp("ASAP", value)) {
diff --git a/default.cfg b/default.cfg
index 9e794ba..0e20726 100644
--- a/default.cfg
+++ b/default.cfg
@@ -70,6 +70,8 @@ delay_mechanism E2E
time_stamping hardware
delay_filter moving_median
delay_filter_length 10
+egressLatency 0
+ingressLatency 0
#
# Clock description
#
diff --git a/ds.h b/ds.h
index ea25fbb..00260ed 100644
--- a/ds.h
+++ b/ds.h
@@ -137,6 +137,8 @@ struct port_defaults {
struct fault_interval flt_interval_pertype[FT_CNT];
UInteger32 neighborPropDelayThresh; /*nanoseconds*/
int min_neighbor_prop_delay; /*nanoseconds*/
+ int tx_timestamp_offset; /*nanoseconds*/
+ int rx_timestamp_offset; /*nanoseconds*/
};
#endif
diff --git a/gPTP.cfg b/gPTP.cfg
index e15a05a..689abd8 100644
--- a/gPTP.cfg
+++ b/gPTP.cfg
@@ -69,3 +69,5 @@ delay_mechanism P2P
time_stamping hardware
delay_filter moving_median
delay_filter_length 10
+egressLatency 0
+ingressLatency 0
diff --git a/ptp4l.8 b/ptp4l.8
index 687beb6..bee42e9 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -205,6 +205,18 @@ The default is moving_median.
.B delay_filter_length
The length of the delay filter in samples.
The default is 10.
+.TP
+.B egressLatency
+Specifies the difference in nanoseconds between the actual transmission
+time at the reference plane and the reported transmit time stamp. This
+value will be added to egress time stamps obtained from the hardware.
+The default is 0.
+.TP
+.B ingressLatency
+Specifies the difference in nanoseconds between the reported receive
+time stamp and the actual reception time at reference plane. This value
+will be subtracted from ingress time stamps obtained from the hardware.
+The default is 0.
.SH PROGRAM AND CLOCK OPTIONS
diff --git a/ptp4l.c b/ptp4l.c
index 83824f7..c18406f 100644
--- a/ptp4l.c
+++ b/ptp4l.c
@@ -92,6 +92,8 @@ static struct config cfg_settings = {
/* Default to very a large neighborPropDelay threshold */
.neighborPropDelayThresh = 20000000,
.min_neighbor_prop_delay = -20000000,
+ .tx_timestamp_offset = 0,
+ .rx_timestamp_offset = 0,
},
.timestamping = TS_HARDWARE,
--
1.7.10.4
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clk
trk
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
port.c | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/port.c b/port.c
index 25265f7..aa9354b 100644
--- a/port.c
+++ b/port.c
@@ -313,6 +313,22 @@ static void fc_prune(struct foreign_clock *fc)
}
}

+static void ts_add(struct timespec *ts, int ns)
+{
+ if (!ns) {
+ return;
+ }
+ ts->tv_nsec += ns;
+ while (ts->tv_nsec < 0) {
+ ts->tv_nsec += (long) NS_PER_SEC;
+ ts->tv_sec--;
+ }
+ while (ts->tv_nsec >= (long) NS_PER_SEC) {
+ ts->tv_nsec -= (long) NS_PER_SEC;
+ ts->tv_sec++;
+ }
+}
+
static void ts_to_timestamp(struct timespec *src, struct Timestamp *dst)
{
dst->seconds_lsb = src->tv_sec;
@@ -492,7 +508,13 @@ static int peer_prepare_and_send(struct port *p, struct ptp_message *msg,
return -1;
}
cnt = transport_peer(p->trp, &p->fda, event, msg);
- return cnt <= 0 ? -1 : 0;
+ if (cnt <= 0) {
+ return -1;
+ }
+ if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, p->pod.tx_timestamp_offset);
+ }
+ return 0;
}

static int port_capable(struct port *p)
@@ -2189,6 +2211,7 @@ enum fsm_event port_event(struct port *p, int fd_index)
return EV_NONE;
}
if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, -p->pod.rx_timestamp_offset);
clock_check_ts(p->clock, msg->hwts.ts);
}
if (port_ignore(p, msg)) {
@@ -2258,7 +2281,13 @@ int port_prepare_and_send(struct port *p, struct ptp_message *msg, int event)
if (msg_pre_send(msg))
return -1;
cnt = transport_send(p->trp, &p->fda, event, msg);
- return cnt <= 0 ? -1 : 0;
+ if (cnt <= 0) {
+ return -1;
+ }
+ if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, p->pod.tx_timestamp_offset);
+ }
+ return 0;
}

struct PortIdentity port_identity(struct port *p)

[Keller, Jacob E]

In regards to the comment about whether a negative value should be acceptable, I think it should not. The reason is because I can't think of any scenario in which hardware timestamps the packet *before* it arrives... That is, there should never be a hardware which negative latency as that is physically not possible.

Regards,
Jake

-----Original Message-----
Sent: Tuesday, December 09, 2014 12:55 PM
Subject: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry
correction
* ChangeLog
** V2
- rename the configuration options to match those in the standards
Most (or all?) hardware provides time stamps that are offset from the
actual point at the reference plane. The amount of delay is asymmetrical
between ingress and egress, and depending on the particular technology,
MAC or PHY, and link speed, there can be jitter in the delay.
Sometimes the manufacturer specifies the amount of expected delay. This
patch series provides a way for the user to correct the delays based on
values from the data sheet or based on empirical data.
This series was tested with an i210 paired with a dp83640 using a short
cable. These devices have their delay values listed in the data sheet.
PPS signals in both directions showed a remaining offset of about 120
nanoseconds, which matches the sum of uncertainties (40 and 80) given
for the i210 card at the 100 MBit link speed.
Comments are welcome.
Thanks,
Richard
Introduce a helper function to identify valid (non-zero) time stamps.
Invoke the clock check even if the time stamp nanoseconds field is
zero.
config: Introduce options for correcting transmit and receive delays.
port: correct transmit and receive time stamps for their calibrated
delays.
config.c | 12 ++++++++++++
default.cfg | 2 ++
ds.h | 2 ++
gPTP.cfg | 2 ++
msg.c | 2 +-
msg.h | 10 ++++++++++
port.c | 35 ++++++++++++++++++++++++++++++++---
ptp4l.8 | 12 ++++++++++++
ptp4l.c | 2 ++
9 files changed, 75 insertions(+), 4 deletions(-)
--
1.7.10.4
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.
clktrk
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Miroslav Lichvar]

Post by Keller, Jacob E
In regards to the comment about whether a negative value should be acceptable, I think it should not. The reason is because I can't think of any scenario in which hardware timestamps the packet *before* it arrives... That is, there should never be a hardware which negative latency as that is physically not possible.

Could there be a HW which tries to compensate for some delay, but
overshoots?

[Christian Riesch]

Jake,

-----Original Message-----
Sent: Wednesday, December 10, 2014 1:00 AM
Subject: Re: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry
correction
In regards to the comment about whether a negative value should be
acceptable, I think it should not. The reason is because I can't think of any
scenario in which hardware timestamps the packet *before* it arrives... That
is, there should never be a hardware which negative latency as that is
physically not possible.

We did a few measurements of egress and ingress timestamping delays (see [1]). We actually measured negative delays for some hardware (see Table III in [1]). Our conclusion was that this hardware must already be (over)compensating PHY delays, however I did not yet manage to ask this question to the manufacturer. But it shows that there are cases where one wants to compensate a negative egress or ingress latency.

Regards,
Christian

[1] http://www.riesch.at/christian/ISPCS2013_Measurement_of_egress_and_ingress_delays_of_PTP_clocks.pdf

[Keller, Jacob E]

-----Original Message-----
Sent: Tuesday, December 09, 2014 11:37 PM
To: Keller, Jacob E; Richard Cochran; linuxptp-
Subject: RE: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry
correction
Jake,

-----Original Message-----
Sent: Wednesday, December 10, 2014 1:00 AM
Subject: Re: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp

asymmetry

correction
In regards to the comment about whether a negative value should be
acceptable, I think it should not. The reason is because I can't think of

any

scenario in which hardware timestamps the packet *before* it arrives...

That

is, there should never be a hardware which negative latency as that is
physically not possible.

We did a few measurements of egress and ingress timestamping delays
(see [1]). We actually measured negative delays for some hardware (see
Table III in [1]). Our conclusion was that this hardware must already be
(over)compensating PHY delays, however I did not yet manage to ask
this question to the manufacturer. But it shows that there are cases
where one wants to compensate a negative egress or ingress latency.
Regards,
Christian

Fair enough. I had not thought of over-compensated delays. I think we can just modify the configs code to allow negative numbers, as the scanf function should already do it. Just treat numbers which have no sign indicator as positive.

Regards,
Jake