On Mon, Oct 03, 2016 at 09:08:55PM +0200, Richard Cochran wrote:
> On Thu, Sep 15, 2016 at 01:23:20PM +0100, Kieran Tyrrell wrote:
> > Signed-off-by: Kieran Tyrrell
>
> Overall, this is looking much better. I will come back to this with
> some comments, but I would like to ru
On Tue, Dec 06, 2016 at 11:59:40PM +, Keller, Jacob E wrote:
> Neat, I didn't think it would be so little code! Thanks!
Yeah, sometimes you get lucky.
Thanks,
Richard
--
Developer Access Program for Intel Xeon Phi Pr
On Tue, Dec 13, 2016 at 04:47:23PM +0100, Miroslav Lichvar wrote:
> I'm testing the latest code from git which includes this feature. It
> doesn't seem to work correctly for me. The program accepts long
> options, but the behaviour doesn't change as if they were not
> specified. Also, valgrind repo
From: Richard Cochran
The state machines in 1588 do not specify an event that causes a transition
out of the initializing state. This was left as a local issue. For this
transition, the current code assigns the next state outside of the FSM. But
doing so prevents an alternative FSM to handle
The code that decides whether a fault qualifies for ASAP treatment is
a tangle of logical operators. This patch replaces the open coded
logic with a helper function whose name makes the intent clear. This
is a cosmetic change only.
Signed-off-by: Richard Cochran
---
port.c | 17
This allows adding new FSM flavors in the future.
Signed-off-by: Richard Cochran
---
port.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/port.c b/port.c
index a1ad6f6..afe0057 100644
--- a/port.c
+++ b/port.c
@@ -94,6 +94,8 @@ struct port {
unsigned int
order to cleanly support other algorithms, we
have to clean this spot up, placing all state transitions under
control of the FSM code proper.
Thanks in advance for your comments and reviews,
Richard
Richard Cochran (5):
port: Make the finite state machine into a function variable.
Change a
cases resulting in two benefits. First,
the check for ASAP fault status is only made when a fault is actually
present, unlike the present unconditional check. Second, this change
will allow us to cleanly support alternative state machines later on.
Signed-off-by: Richard Cochran
---
port.c | 14
return type to void, making the
actual behavior explicit. Dropping the input check is safe because
that function has exactly two callers, both of whom always provide
valid inputs.
Signed-off-by: Richard Cochran
---
port.c | 15 +--
port.h | 5 ++---
2 files changed, 7 insertions
On Thu, Jan 05, 2017 at 10:15:53AM +0100, Miroslav Lichvar wrote:
> A leap second was applied to UTC on 2016-12-31 and the offset between
> TAI and UTC is now 37 seconds.
Applied.
Thanks,
Richard
--
Check out the vibrant
On Tue, Jan 17, 2017 at 05:51:40PM +, Viliam Lejcik wrote:
> Hi Miroslav, thank you for your review. I updated the patch as suggested.
> Hopefully it is ok now...
Applied.
Thanks,
Richard
--
Check out the vibrant te
On Tue, Jan 17, 2017 at 02:17:38PM +0100, Miroslav Lichvar wrote:
> Changes in v2:
> - rename options to use "tag" instead of "prefix"
> - don't add short command-line option to ptp4l
Series applied.
Thanks,
Richard
--
C
Having one fewer port may affect the result of the BMCA. This patch
changes the main loop so that a link down event also causes a state
decision event.
Signed-off-by: Richard Cochran
Reported-by: Henry Jesuiter
---
clock.c | 19 +--
1 file changed, 13 insertions(+), 6
This global function used to return an error code, but now it always
returns zero. This patch converts the function signature to return void
and simplifies the main clock loop by removing the useless test.
Signed-off-by: Richard Cochran
---
clock.c | 6 +++---
port.c | 9 -
port.h
On Thu, Jan 19, 2017 at 01:52:24PM +, Jesuiter, Henry (ALC NetworX GmbH)
wrote:
> After investigating into the code, I recognize, that probably there
> is a handle_state_decision_event(c) on a link down event necessary
> (just to give the other ports the chance to recognize that link
> state c
On Wed, Feb 08, 2017 at 01:53:29PM -0500, Vanderpool, Clyde wrote:
> I am new to this type of forum so I hope I am posting this correctly. I
> was wondering if it is possible to integrate machines with Linux OS that
> are synced via Linux PTP to Windows machines that are using Greyware to
> implem
On Wed, Feb 08, 2017 at 01:53:29PM -0500, Vanderpool, Clyde wrote:
> I am new to this type of forum so I hope I am posting this correctly.
BTW, your question is more of a "users" question, and so it would have
been better on the linuxptp-users list (but no big deal :)
Thanks,
Richard
---
On Sun, Feb 05, 2017 at 06:37:13PM +0100, Richard Cochran wrote:
> I just posted two patches to fix this issue. Can you please try them?
Ping?
--
Check out the vibrant tech community on one of the world's most
On Tue, Feb 14, 2017 at 07:47:32AM +, Jesuiter, Henry (ALC NetworX GmbH)
wrote:
> Sorry, I thought I already answered a week ago. These patches work fine for
> us, and I already integrated them in our current firmware for further real
> live tests.
That is good news, thanks!
Richard
-
On Mon, Feb 06, 2017 at 03:51:10PM +0100, Miroslav Lichvar wrote:
> Signed-off-by: Miroslav Lichvar
Applied.
Thanks,
Richard
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashD
On Tue, Feb 14, 2017 at 04:33:34PM +, Urs Ritzmann wrote:
> What's your opinion. Is it worth sending patches?
Yes, this is a use case that would interest many people, I should
think.
Thanks,
Richard
--
Check out the
On Wed, Feb 15, 2017 at 10:33:52AM +0100, Miroslav Lichvar wrote:
> In general this looks interesting, but it's not very clear to me what
> would be the advantage over using the PI servo with smaller constants.
Yes, I was wondering this as well. If you have some test results that
show the advanta
On Thu, Feb 16, 2017 at 06:30:31PM +0100, Emilio Marín López wrote:
> I would like to know if the following PTP profiles are currently
> supported by the linuxptp:
>
> - PTP default profile
Yes.
> - IEEE-C37.238 Power Profile
Yes and no. We do not produce messages with the p
On Fri, Feb 17, 2017 at 10:27:34AM +0100, Miroslav Lichvar wrote:
> Do you think it would be worth adding support for the hybrid
> multicast/unicast mode, where only delay request and response are
> unicast, in order to save network traffic in very large networks?
> If I understand it correctly, th
On Fri, Feb 17, 2017 at 10:03:35AM +, Urs Ritzmann wrote:
> But I was still concerned that we could get such a transient for any
> reason. Perhaps NTP was not yet ready to tune the system clock which
> invalidates that initial measurement.
But ntpd avoids sudden system clock adjustments, doesn
On Fri, Feb 17, 2017 at 11:08:39AM +0100, Miroslav Lichvar wrote:
> Awesome, I didn't realize we already have that :). Full unicast
> support doesn't seem very useful to me, but maybe I just didn't see
> the right use case for it.
It is specified in one of the telecom profiles. The ITU published
On Fri, Feb 17, 2017 at 02:29:16PM +0100, Emilio Marín López wrote:
> We are trying to make one of our devices PTP compatible so we are thinking
> in using your linuxptp. The problem is that we need the telecom profile (ITU
> G.8265.1) and that specific profile uses unicast traffic. That was the
>
On Mon, Mar 06, 2017 at 12:56:08PM +, Rommel, Albrecht wrote:
> Is there a particular reason that linuxptp does not support some SET commands
> in PTP management client?
The only reason is that no one has needed any additional SET commands.
In practice, with the exception of the GM settings,
On Mon, Mar 06, 2017 at 03:52:26PM +, Rommel, Albrecht wrote:
> There is a demand for changing PORT_DATA_SET and probably
> CLOCK_DESCRIPTION while ptp4l is running.
First off, according to 1588 CLOCK_DESCRIPTION is GET only. There is
no SET.
Secondly, PORT_DATA_SET is a collection, and thus
On Tue, Mar 07, 2017 at 11:37:23AM +, Rommel, Albrecht wrote:
> There are some applications where a PTP clock node (i.e. a
> master-only-ordinary-clock) will be configured from remote in a
> secure environment, i.e. NETCONF YANG, or other transport technology
> (ITU PON, IEEE PON, DOCSIS) speci
On Wed, Mar 08, 2017 at 05:15:35PM +, Rommel, Albrecht wrote:
> Richard,
>
> Another question:
> What does the ´NP´ stand for, with management TLVs *_NP, such as
> GRANDMASTER_SETTINGS_NP
> PORT_DATA_SET_NP
> TIME_STATUS_NP
Non-Portable. IOW, these are custom TLVs.
HTH,
Richard
---
If I understood correctly, then in your setup phc2sys will use the
UTC/TAI offset provided by the GM...
On Tue, Mar 21, 2017 at 08:37:49AM +0100, Stefan Lange wrote:
> ptp4l correctly syncs /dev/ptp0 to one of the grandmaster clocks:
>
> root@cp61850:/var/log# pmc -u -b 0 'GET PORT_DATA_SET'
Wh
On Wed, Mar 22, 2017 at 09:01:23AM +0100, Stefan Lange wrote:
> root@cp61850:~# pmc -u -b 0 'GET TIME_PROPERTIES_DATA_SET'
> sending: GET TIME_PROPERTIES_DATA_SET
> 00d093.fffe.274a5e-0 seq 0 RESPONSE MANAGEMENT
> TIME_PROPERTIES_DATA_SET
> currentUtcOffset 37
>
On Wed, Mar 22, 2017 at 12:59:42PM +0100, Stefan Lange wrote:
> Anyway I still can not see why the setup would work with ptp4l using
> only 1 ethernet interface or phc2sys non-autoconfig, even given there
> was (or maybe still is) a problem in the GM configuration.
Sorry, I misread your original p
On Mon, Mar 27, 2017 at 10:45:16AM +0200, Burkhard Ilsen wrote:
> On Thu, Sep 15, 2016 at 08:55:34PM +0000, Richard Cochran wrote:
> > So I do want to have TC/TAB in linuxptp for version 2.0.
>
> According to 802.1 AS all message timestamps shall be based on a free running
>
On Mon, Mar 27, 2017 at 12:32:46PM +0200, Burkhard Ilsen wrote:
> My use case is a bridged end-station, i.e. a time-aware bridge with an
> application that needs to be synchronized.
So we don't actually support TC or TAB. Those patches were only a
rudimentary proof of concept. Did you see the T
On Tue, Mar 28, 2017 at 10:30:43AM +0200, Stefan Lange wrote:
> great, the V2 patch works well with me. Thanks a lot.
I am going to merge this patch.
With your permission, Stefan, I would like to give you credit in the
commit message with a tag like this:
Reported-by: Stefan Lange
Thanks,
On Mon, Apr 03, 2017 at 09:20:44AM +0200, Burkhard Ilsen wrote:
> The reason is that t3 is reset after the first step letting
> tsproc_update_offset() fail.
You mean the call to tsproc_reset() after SERVO_JUMP...
> I think tsproc_update_offset() should not fail in this case because the
> filtered
On Mon, Apr 03, 2017 at 03:52:13PM +0200, Burkhard Ilsen wrote:
> 1.
> For the first measurement the nrate ratio cannot be calculated.
> To avoid an erroneous measurement the calculation could be aborted if the
> nrate is not valid,
> e.g. by placing a "if(!p->nrate.ratio_valid) return;" between
>
On Wed, Apr 05, 2017 at 12:21:33PM +0200, Burkhard Ilsen wrote:
> I found a bug, patch is attached (because this is the only way I
> manage to send proper formatted patches).
Patch applied (after fixing whitespace error.)
Thanks,
Richard
--
On Thu, Apr 06, 2017 at 12:30:39PM +0200, Burkhard Ilsen wrote:
> Alright then, I fixed it.
We want to review your patches, and for that we need to also quote
them in replies. Can you please teach your mailer to send plain text,
or use a different mailer?
Once, when I was forced to use Outlook/E
On Fri, Apr 07, 2017 at 08:11:24PM +0200, Burkhard Ilsen wrote:
> Now shall I resend the patch?
Yes, please.
Thanks,
Richard
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdo
On Sat, Apr 08, 2017 at 12:31:30AM +0200, Burkhard Ilsen wrote:
> The sequence of port_nrate_calculate() and tsproc_update_delay()
> in port_peer_delay() is mixed up.
> The peer delay depends on the nrate ratio so the nrate ratio
> shall be updated before peer delay is calculated.
>
> Signed-off-b
On Sat, Apr 08, 2017 at 12:30:05AM +0200, Burkhard Ilsen wrote:
> diff --git a/tsproc.c b/tsproc.c
> index cf5f0dc..a9c1c48 100644
> --- a/tsproc.c
> +++ b/tsproc.c
> @@ -163,12 +163,17 @@ int tsproc_update_offset(struct tsproc *tsp, tmv_t
> *offset, double *weight)
> {
> tmv_t delay, raw_
We will want to test whether a valid filtered delay value has been
calculated or not. However, we cannot simply test for zero since that is
a legitimate possible delay value. This patch adds a flag that reflects
the state of the filtered delay field.
Signed-off-by: Richard Cochran
sue by allowing the stored filtered delay to be
used when appropriate.
Signed-off-by: Richard Cochran
Reported-by: Burkhard Ilsen
---
tsproc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tsproc.c b/tsproc.c
index 550f32c..63c989d 100644
--- a/tsproc.c
++
we
will want to add some more complexity. In the interest of clarity,
this patch converts the paired Boolean tests into a switch/case
pattern.
No functional change.
Signed-off-by: Richard Cochran
---
tsproc.c | 64
1 file changed
On Thu, Apr 27, 2017 at 03:41:03PM +1000, David Mirabito wrote:
> * "Fixing" (if this is indeed a bug) was reasonably straight forward - more
> or less reordering steps 4,5,6 so that we wake the app only *after* we've
> unlocked the bit.
If your analysis was correct, then yes, indeed this is a dri
On Tue, May 02, 2017 at 11:24:27AM -0400, Chris LaRocque wrote:
> Other than strolling through the pmc and ptp4l source, is there a
> definitive document and if so where can I locate it?
They are not documented anywhere in our project materials (BTW they
are documented in IEEE 1588), but you can s
On Tue, May 02, 2017 at 11:24:27AM -0400, Chris LaRocque wrote:
> Other than strolling through the pmc and ptp4l source, is there a
> definitive document and if so where can I locate it?
Also, most of the items (like slaveOnly for example) are exactly the
same properties as in the configuration fi
On Wed, May 03, 2017 at 06:40:40AM -0400, Chris LaRocque wrote:
> Is there an immediate way to tell which source, ntp vs PTP is being used by
> phc2sys to discipline the system clock?
Apart from monitoring the log messages, no, I don't think so.
Sorry,
Richard
---
On Sun, May 07, 2017 at 01:02:33PM -0700, Florian Fainelli wrote:
> Upon inspection, it does not appear that netdb.h is providing any useful
> definition or declaration, so let's just remove its inclusion.
Applied.
Thanks,
Richard
-
On Sun, May 07, 2017 at 02:44:13PM -0700, Florian Fainelli wrote:
> musl-libc does not provide a net/ethernet.h which is a glibc-ism.
> eth_hdr is already declared in ether.h and provides everything that is
> necessary.
>
> Signed-off-by: Wojciech Dubowik
> [florian: extract patch for OpenWrt, ad
On Sun, May 07, 2017 at 02:44:14PM -0700, Florian Fainelli wrote:
> Fixes the following build errors seen with musl-libc:
>
> In file included from print.h:25:0,
> from linreg.c:24:
> util.h:364:32: error: unknown type name 'time_t'
> int rate_limited(int interval, time_t *las
On Fri, May 12, 2017 at 03:36:45PM +0800, Hangbin Liu wrote:
> If the len is not enought for another tlv process. e.g. one more bytes
> padding at the end of message. And we set extra to NULL instead of
> msg->last_tlv in tlv_post_recv(). Then the msg->last_tlv will not be
> initialised. And progra
On Sun, May 07, 2017 at 02:44:14PM -0700, Florian Fainelli wrote:
> Fixes the following build errors seen with musl-libc:
>
> In file included from print.h:25:0,
> from linreg.c:24:
> util.h:364:32: error: unknown type name 'time_t'
> int rate_limited(int interval, time_t *las
On Mon, May 15, 2017 at 10:17:51AM +0200, Petr Kulhavy wrote:
> On some targets the time_t structure was missing and the compilation was
> failing.
>
> Signed-off-by: Petr Kulhavy
> ---
> util.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/util.h b/util.h
> index e912f19..3efde5c 1
On Mon, May 15, 2017 at 10:17:52AM +0200, Petr Kulhavy wrote:
> On some platforms like br-arm-cortex-a9-musl struct ethhdr was defined twice
> due to including of both linux/if_ether.h and netinet/ether.h. Which lead
> to a compilation error.
>
> Remove netinet/ether.h as the official header for s
On Mon, May 15, 2017 at 10:17:53AM +0200, Petr Kulhavy wrote:
> On some platforms clock_adjtime is defined in timex.h instead of time.h
> Due to this fact the detection in incdefs.h was failing.
> Add timex.h into the list of searched files.
>
> Signed-off-by: Petr Kulhavy
Applied.
Thanks,
Rich
On Mon, May 15, 2017 at 10:17:54AM +0200, Petr Kulhavy wrote:
> On some platforms compilation issues due to clock_nanosleep were occuring. The
> simple test for __uClinux__ was not sufficient.
>
> Implement full detection of clock_nanosleep in incdefs.h by compiling a short
> C
> file. incdefs.s
On Tue, May 16, 2017 at 04:56:48PM +0200, Petr Kulhavy wrote:
> This is not a fix of an actual issue rather than prevention of a potential
> issue.
No, your patch introduces an issue that wasn't there before.
> @@ -1589,7 +1589,7 @@ int clock_switch_phc(struct clock *c, int phc_index)
> cl
On Tue, May 16, 2017 at 09:58:19PM +0200, Petr Kulhavy wrote:
> Did I miss something? What is the reason then?
Never mind, this is snprintf() and not strncpy().
The original code was confused and misleading using 31 (but not really
incorrect either).
Thanks,
Richard
On Mon, May 15, 2017 at 11:37:05PM +0200, Petr Kulhavy wrote:
> However it is too weak. On some targets clock_nanosleep is defined
> conditionally in #if preprocessor directives.
> There is no way to detect that with grep.
Is this a configuration option for uClibc? If so, then correct
solution is
On Tue, May 16, 2017 at 04:56:48PM +0200, Petr Kulhavy wrote:
> This is not a fix of an actual issue rather than prevention of a potential
> issue.
> On two places a fixed array size (different to the actual size) is used in
> snprintf.
> Replace with sizeof(array)
I merged this change, but I co
On Wed, May 17, 2017 at 03:58:39PM +0200, Petr Kulhavy wrote:
> TLV_PRIORITY1 and TLV_PRIORITY2 cases in do_set_action() use the same repeated
> piece of generic code for setting one-value parameter. Remove the duplicated
> code and let both cases use the same code.
>
> Signed-off-by: Petr Kulhavy
On Wed, May 17, 2017 at 04:08:53PM +0200, Miroslav Lichvar wrote:
> On Wed, May 17, 2017 at 03:58:40PM +0200, Petr Kulhavy wrote:
> > + case TLV_DOMAIN:
> > + mtd = (struct management_tlv_datum *) tlv->data;
> > + c->dds.domainNumber = mtd->val;
> > + *changed = 1;
>
On Sun, May 21, 2017 at 10:02:06PM +0200, Richard Cochran wrote:
> On Wed, May 17, 2017 at 04:08:53PM +0200, Miroslav Lichvar wrote:
> > Shouldn't this also reset the state of the clock?
Thinking out loud, the cleanest way might be to introduce a new fault
type called "reco
On Mon, May 22, 2017 at 12:09:06AM +0200, Petr Kulhavy wrote:
> I'm not a uclibc expert, so I can't answer under what conditions
> clock_nanosleep is defined. TYou would need to ask the uclibc authors.
And just who might they be?
If you want this to work on uClibc, then *you* could ask them!
> B
On Sun, May 21, 2017 at 10:32:10PM +0200, Petr Kulhavy wrote:
> Fix "may be used uninitialized in this function" warnings for state and
> timestamping.
Please tell us more:
What gcc version produces this warning?
Is the warning a false positive or not?
> @@ -1037,7 +1037,7 @@ static int auto_in
On Mon, May 22, 2017 at 11:05:39PM +0200, Petr Kulhavy wrote:
> If you don't like it, please take my email just as a bugreport: linuxptp
> fails to build with uclibc, details in my previous emails.
Let me fix that for you:
bugreport: Improperly configured uClibc lacks clock_nanosleep.
> I don't
On Mon, May 22, 2017 at 11:05:39PM +0200, Petr Kulhavy wrote:
> I can't find any rational argument against test-compiling a piece of code in
> that negatively loaded emotional outburst you referred to.
you still have to do the hard work and figure out the right way to
explain to the autocr
On Tue, May 23, 2017 at 02:49:55PM +0800, Hangbin Liu wrote:
> If handle unknown management tlv. The management message id and format are
> also unknown, thus we may crash due to access unknown area.
>
> Signed-off-by: Hangbin Liu
Applied.
Thanks,
Richard
--
On Mon, May 15, 2017 at 11:37:05PM +0200, Petr Kulhavy wrote:
> I'm trying to get linuxptp into Buildroot so that it compiles on all 49
> targets.
FYI, your buildroot patch
http://lists.busybox.net/pipermail/buildroot/2017-May/192051.html
has another issue. If you build beaglebone_defconfig
On Tue, May 23, 2017 at 11:43:57AM +0200, Petr Kulhavy wrote:
> I'm not sure that you fully understand the problem. It seems there are
> currently four scenarios possible.
Yeah, I get that. Your task then would have been to address the four
possibilities.
> Now the question is how to handle this
- the DEVELOPERS hunk (which no longer applies, fix is trivial)
- the patches for linuxptp, no longer necessary
- the broken LINUXPTP_INSTALL_INIT_SYSV macro
Richard Cochran (1):
Fix build when using uClinux.
missing.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
From: Richard Cochran
Unfortunately uClinux is rather inconsistent with respect to
clock_nanosleep(). Older versions of uclibc lack that function, while
newer versions may include the declaration but still lack the
definition, depending on whether pthreads are selected in the
configuration
On Tue, May 30, 2017 at 08:37:39AM +0200, Richard Cochran wrote:
> diff --git a/package/linuxptp/linuxptp.mk b/package/linuxptp/linuxptp.mk
> new file mode 100644
> index 0..44f56f98d
> --- /dev/null
> +++ b/package/linuxptp/linuxptp.mk
Apart from the actual logic, this patch (and the other two) have
formatting issues.
First off, these patches don't apply. They are white space damaged.
Secondly:
In order to submit a patch from someone else, please follow this
direction from linux/Documentation/process/submitting-patches.rst:
This patch doesn't let ptp4l work as a Time Aware Bridge!
On Thu, Jun 01, 2017 at 04:05:57PM +, Erik Hons wrote:
> This commit only focuses on time transfer and not BMCA changes.
This change log is totally inadequate. You need to tell us why your
changes are needed. Is something not in com
On Thu, Jun 01, 2017 at 04:06:54PM +, Erik Hons wrote:
> These changes are:
> - Removed UNCALIBRATED and PRE_MASTER port states.
> - Short circuited foreign master qualification mechanism.
> - Correctly identify if the local PTP clock is the domain Grand Master.
> - port: Reduce the foreign mas
On Thu, Jun 01, 2017 at 04:07:41PM +, Erik Hons wrote:
> port: Prevent erroneous neighbor rate calculations.
>
> When a connected peer introduces a time discontinuities in between
> consecutive peer-delay measurements (i.e. a jump in time in
> consecutive PDelay response), an erroneous neighbo
On Wed, Jun 07, 2017 at 02:46:39PM +, Rodney Greenstreet wrote:
> Thank you for your feedback. I want to explain why we chose to add TAB to
> your BC implementation rather than adding a new type of device. A TAB is
> mathematically equivalent to a TC but is functionally equivalent to a BC.
>
On Wed, Jun 07, 2017 at 02:46:39PM +, Rodney Greenstreet wrote:
> Based on these clauses, it’s clear that each port maintains its own
> sync interval setting and needs to maintain its own sync interval
> timer. It’s also clear that when the slave port of a TAB receives a
> sync event, that mess
On Wed, Jun 07, 2017 at 06:11:42PM +0200, Richard Cochran wrote:
> On Wed, Jun 07, 2017 at 02:46:39PM +, Rodney Greenstreet wrote:
> > Based on these clauses, it’s clear that each port maintains its own
> > sync interval setting and needs to maintain its own sync interval
>
On Wed, Jun 07, 2017 at 04:24:52PM +, Rodney Greenstreet wrote:
> Please read clause 10.6.2.3 ‘time-synchronization event message transmission
> interval’ and clause 10.6.2.4 ‘Interval for providing synchronization
> information
> by ClockMaster entity’. The last clause makes it very clear tha
On Wed, Jun 07, 2017 at 04:51:03PM +, Rodney Greenstreet wrote:
> Please review this state machine again. The syncInterval is used to govern
> the transition back to the ‘SEND_MD_SYNC’ state. This transition only occurs
> if the the syncInterval has elapsed and the received Sync message is not
On Wed, Jun 07, 2017 at 06:20:40PM +, Rodney Greenstreet wrote:
> I think this SM is optimized for behaving as you suggest, with the
> assumption all sync intervals are the same. However, a port’s
> syncInterval, or some fraction of it, must be adhered to. Also, if a
> Sync event is not receive
On Thu, Jun 08, 2017 at 04:50:27PM +0800, Hangbin Liu wrote:
> Do you have any comments?
I was waiting for Miroslav to comment first ;)
He did suggest something some time ago. I have not yet thought much
about bonding, and so I not yet ready to give an opinion...
Thanks,
Richard
--
On Thu, Jun 08, 2017 at 03:50:13PM +0200, Miroslav Lichvar wrote:
> What Hangbin is suggesting is different in that most of the work is
> done in ptp4l and there are no or only minimal changes needed in the
> kernel and phc2sys. ptp4l would use the master interface for
> networking and slave interf
On Thu, Jun 15, 2017 at 09:23:16PM +0800, Hangbin Liu wrote:
> Sorry to bother you again. But customers are pushing for this.
Well, I have been overloaded with work, and today I am feeling sick.
So I will take a look as soon as I can, but your customers will have
to be patient.
> If you like, I
On Thu, Jun 15, 2017 at 10:16:43AM -0600, Brian Olson wrote:
> Miroslav Lichvar suggested that I submit these changes to linuxptp-devel.
Can you please resubmit those as two separate emails (not as
attachments), adding a SOB line. See the file, README.org, under
"Submitting Patches".
> In file
Hangbin
Finally getting back to this...
On Tue, Jun 06, 2017 at 06:22:28PM +0800, Hangbin Liu wrote:
> Now more and more customers are asking for linuxptp bond/team fail over
> support.
> I have a draft plan to implement this feature. Would you like to help review
> it
> to see if it's OK or no
On Thu, Jun 08, 2017 at 03:50:13PM +0200, Miroslav Lichvar wrote:
> The question is if you would be ok with bonding/teaming-specific code
> in ptp4l and if you have any suggestions on the design. Should there
> be only one port, or should each slave interface has its own port?
There should be only
On Mon, Jun 19, 2017 at 10:55:21AM +0800, Hangbin Liu wrote:
> > >struct interface {
> > >STAILQ_ENTRY(interface) list;
> > >char name[MAX_IFNAME_SIZE + 1];
> > >char slave[MAX_IFNAME_SIZE + 1];
> > >int index;
> > >int slave_index;
>
On Fri, Jun 16, 2017 at 12:58:32PM -0400, Brian Olson wrote:
> ---
> rtnl.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, fixing up the SOB and adding a comment so as not to forget
the ordering requirements.
Thanks,
Richard
--
On Fri, Jun 16, 2017 at 12:58:33PM -0400, Brian Olson wrote:
> ---
> clockadj.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied.
Thanks,
Richard
--
Check out the vibrant tech community on one of th
On Fri, Jun 16, 2017 at 03:07:19PM -0700, Cliff Spradlin via Linuxptp-devel
wrote:
> When phc2sys synced more than one ethernet interface, such as in a JBOD
> boundary clock arrangement, it was unclear which interface a line of
> statistics
> referred to.
Applied.
Thanks,
Richard
-
On Mon, Jun 19, 2017 at 02:56:00PM +0800, Hangbin Liu wrote:
> Then how do we know the slave changed. Cause via netlink rta
> IFLA_BOND_ACTIVE_SLAVE, we only know the current active slave. If we do not
> store previous slave name/index some where and compare with current value.
> How do we know the
On Mon, Jun 19, 2017 at 03:35:16PM +0800, Hangbin Liu wrote:
> But other device actions will also trigger a rtnl notification, i.e. mtu
> change.
> So we need to make sure the slave actually changed before reset clock/port.
Fair enough, but that requires only one additional variable per port.
Th
On Thu, Jun 22, 2017 at 10:36:33PM +0800, Hangbin Liu wrote:
> +static void clock_destroy(struct node *node)
Can't we name this differently?
We already have a function called clock_destroy in clock.c. Yes, I
know that that is not linked into phc2sys, but for the sake of grep
and cscope we want u
101 - 200 of 2642 matches
Mail list logo
