On Wed, 2018-08-22 at 23:47 +0000, Patel, Vedang wrote:
> On Mon, 2018-08-20 at 17:47 -0700, Patel, Vedang wrote:
> >
> > On Sat, 2018-08-18 at 00:03 -0400, Richard Cochran wrote:
> > >
> > >
> > > On Thu, Aug 16, 2018 at 10:42:10AM -0700, Vedang Patel wrote:
> > > >
> > > >
> > > >
> > > > - In port_p2p_transition(), we are setting up the delay timer
> > > > when
> > > > BMCA is set
> > > > as ‘noop’. Usually it is initialized then the device
> > > > transitions
> > > > to
> > > > PS_LISTENING. But, we are skipping the LISTENING state.
> > > > Another
> > > > alternative
> > > > is to transition to PS_LISTENING and then unconditionally
> > > > transfer to
> > > > PS_MASTER/PS_SLAVE. But, that seems more of an hack than what
> > > > is
> > > > currently
> > > > being done. Any other alternatives?
> > > Another idea:
> > >
> > > Can you have INITIALIZING -> LISTENING, and arrange for
> > > EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES to happen right away?
> > >
> > > Then your fsm does LISTENING -> SLAVE on the
> > > EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES event.
> > >
> > > (haven't looked at arranging that timeout, just brainstorming...)
> > >
> > We can do something on the lines of the following (completely
> > untested)
> > snippet:
> >
> > diff --git a/port.c b/port.c
> > index f4a9fbb5a8d7..214a8329d27e 100644
> > --- a/port.c
> > +++ b/port.c
> > @@ -1623,7 +1623,7 @@ int port_initialize(struct port *p)
> > p->fda.fd[FD_FIRST_TIMER + i] = fd[i];
> > }
> >
> > - if (port_set_announce_tmo(p)) {
> > + if (set_tmo_log(p->fda.fd[FD_ANNOUNCE_TIMER], 1, -10)) {
> > goto no_tmo;
> > }
> > if (unicast_client_enabled(p) && unicast_client_set_tmo(p))
> > {
> >
> > This way, the timer will fire once (immediately after it's setup)
> > even
> > if inhibit_announce is set.
> >
> > But, there is going to be a likely effect on the normal working of
> > linuxptp. We can fix this by only doing this when BMCA == noop.
> > Again,
> > will have to actually test this to see what issues might pop up.
> >
> The above approach does work if I set the timer to expire in
> something
> like 2^-100 secs.
>
Looks like the above method won't really work.
First, setting the delay to 2^-100 tries to set the timer to 0.
Also, even if I manually try to set the timer to expire in very small
time like in 10ns, it still does not work with the current behaviour
pointed out below. Whenever the timer is cleared (in port_clr_tmo())
the events pending are also lost and won't be received the next time
you call poll().
I apologize for some misinformation in the last email.
Thanks,
Vedang
> But, I had another concern with the code flow here. Following is the
> flow with relevant functions called to explain what is going on:
>
> bc_dispatch() {
>
> ....
> port_state_update() {
> ...
> port_initialize() {
> ...
> // to be replaced by set_tmo_log()
> port_set_announce_tmo();
>
> ...
> }
> ...
> }
> port_p2p_transition() {
> port_clr_tmo(p->fda.fd[FD_ANNOUNCE_TIMER]);
> }
> }
>
> Here, port_clr_tmo() is happening almost immediately after
> port_set_announce_tmo() is setting up the timer. So, the timer never
> fires.
>
> This is also occuring when I try to run the lastest upstream code
> with
> gPTP profile. Seems like the timer is not going to fire in any
> scenario. Is there something I am missing here or this is a bug?
>
> Thanks,
> Vedang
>
> >
> > Thanks,
> > Vedang
> > >
> > >
> > > Thanks,
> > > Richard
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
