Re: [Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry correction
On Mon, Dec 08, 2014 at 02:04:56PM +0100, Delio Brignoli wrote: > > Regardless of where the correction is applied there should be a way > to query/set the currently applied offsets at runtime. I’d think the > obvious choice for linuxptp would be an implementation specific > management interface message. Yes, I agree. As you said, this can be added later on... > >> (2) For some reason I would prefer (but not strongly) adding a > >> signed correction offset in both the egress and ingress directions > >> instead of adding in one direction and subtracting in the other. > > > > So far, the data sheets I have seen give these corrections as positive > > numbers for both egress and ingress delays. The idea was to allow the > > user to simply enter the values from the data sheet into the > > configuration file. > > ACK, good point. Someone pointed out to me off-list that these corrections are standardized, and they are *not* part of the delayAsymmetry field. In 802.1AS they are defined in Section 8.4.3 as "egressLatency" and "ingressLatency", and 1588 uses an almost identical definition. I will respin this series to make the configuration options have the same names as in the standards. Thanks, Richard -- 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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH RFC V2 3/4] config: Introduce options for correcting transmit and receive delays.
Signed-off-by: Richard Cochran
---
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_length10
+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_length10
+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 = 2000,
.min_neighbor_prop_delay = -2000,
+ .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.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH RFC V2 4/4] port: correct transmit and receive time stamps for their calibrated delays.
Signed-off-by: Richard Cochran
---
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)
--
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
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[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 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(-) -- 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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH RFC V2 1/4] Introduce a helper function to identify valid (non-zero) time stamps.
Signed-off-by: Richard Cochran
---
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;
--
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
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH RFC V2 2/4] Invoke the clock check even if the time stamp nanoseconds field is zero.
Signed-off-by: Richard Cochran
---
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)) {
--
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
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 4/4] port: correct transmit and receive time stamps for their calibrated delays.
Excellent series.
I know that some of the Intel hardware has measurable delays, and we were
thinking of whether it was better to hack the driver for this delay, but being
able to do it generically here is a good way to avoid having to modify the
driver for this.
Thanks,
Jake
> -Original Message-
> From: Richard Cochran [mailto:richardcoch...@gmail.com]
> Sent: Saturday, December 06, 2014 1:59 PM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH RFC 4/4] port: correct transmit and
> receive time stamps for their calibrated delays.
>
> Signed-off-by: Richard Cochran
> ---
> 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)
> --
> 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
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
--
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
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
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. Regards, Jake > -Original Message- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Tuesday, December 09, 2014 12:55 PM > To: linuxptp-devel@lists.sourceforge.net > 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 > > > 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(-) > > -- > 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 > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel -- 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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry correction
On Tue, Dec 09, 2014 at 11:59:39PM +, Keller, Jacob E wrote: > 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? -- Miroslav Lichvar -- 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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
