> -Original Message-
> From: Richard Cochran [mailto:richardcoch...@gmail.com]
> Sent: Monday, July 24, 2017 9:38 AM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH RFC 0/3] Fix UTC offset issue
>
> This patch series addresses the jumping UTC offset issue
This patch series addresses the jumping UTC offset issue that occurs
when the default TAI-UTC offset is out of date, but a then GM master
appears providing the correct offset, only to disappear again.
Review and comments are most welcome.
Thanks,
Richard
Richard Cochran (3):
Simplify UTC
When acting as a slave, we accept the foreign master's advertised
TAI-UTC offset for as long as that master is present. However, when
the master disappears, we fall back to the initial offset value. As a
result of this behavior, when starting with an out of date initial
offset, losing a foreign
Now that we test the UTC flags in clock_update_slave(), the similar
code in clock_utc_correct() is redundant.
Signed-off-by: Richard Cochran
---
clock.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/clock.c b/clock.c
index da1fcc4..9d224c9
The current implementation of ptp4l always assumes 6 octets MAC
address, which is correct for Ethernet interfaces but not for IPoIB
interfaces (that have 20 octets MAC), therefore running ptp4l over
IPoIB interface does not function correctly.
In Infiniband, every interface has three identifiers:
The current implementation of ptp4l always assumes 6 octets MAC
address, which is correct for Ethernet interfaces but not for IPoIB
interfaces (that have 20 octets MAC), therefore running ptp4l over
IPoIB interface does not function correctly.
In Infiniband, every interface has three identifiers: