From: Neelansh Mittal <neelansh@gmail.com>
To: linux-wireless@vger.kernel.org
Subject: Re: Adjusting_tbtt in mesh capability
Date: Thu, 4 Feb 2016 04:06:56 +0000 (UTC) [thread overview]
Message-ID: <loom.20160204T044620-134@post.gmane.org> (raw)
In-Reply-To: 56B291A8.4000701@codeaurora.org
> I guess it's to prevent mesh peers from running TBTT adjustment?
That's correct.
But in this scenario(Synchronization) , the beacon would be delayed ,
and the peers running faster than me, would see this as drift and should
delay their TSFs too.(which they would do if the bit is unset)
On the contrary ,If the adjusting_tbtt bit is set, the faster peers
would ignore this beacon and hence the "drift due to change in TSF".
Therefore, every time a node adjusts it's TSF, there would be a TBTT
drift as seen by the faster mesh nodes.This drift would keep on getting
added(every time a faster node 'delays' it's TSF).
Peter Oh <poh@...> writes:
>
>
> On 02/03/2016 12:18 PM, Neelansh Mittal wrote:
> > Currently, for a mesh node ,the mac80211
> > sync implementation sets the tbtt
> > adjustment bit , when it is adjusting it's
> > tsf as part of Neighbour offset
> > Synchronization(Function:mesh_sync_offset_
> > adjust_tbtt())
> > According to ieee80211s specification,
> > this bit should(only) be set when tbtt
> > adjustment procedure(as part of tbtt
> > selection/mbca) is ongoing.
> > So why does mac80211 set it as part of
> > Offset syncronization, ie , what is
> > advantage the when a mesh node announces
> > that "my tbtt will be delayed" to it's
> > peers?
> I guess it's to prevent mesh peers from running TBTT adjustment?
> Setting TBTT adjustment bit is good idea although the standard is
> addressing TBTT adjustment bit during MBCA/TBTT selection procedure,
> since the key idea of setting the bit is to run TBTT adjustment by
only
> one mesh point at a time IMO.
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
wireless"
> > in
> > the body of a message to majordomo@...
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
prev parent reply other threads:[~2016-02-04 4:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 20:18 Adjusting_tbtt in mesh capability Neelansh Mittal
2016-02-03 23:47 ` Peter Oh
2016-02-04 4:06 ` Neelansh Mittal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20160204T044620-134@post.gmane.org \
--to=neelansh@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.