linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bruno randolf <bruno@thinktube.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: ath5k-devel@lists.ath5k.org, mcgrof@gmail.com,
	jirislaby@gmail.com, mickflemm@gmail.com,
	linux-wireless@vger.kernel.org, linville@tuxdriver.com,
	flamingice@sourmilk.net, jbenc@suse.cz
Subject: Re: [PATCH] mac80211: enable IBSS merging
Date: Thu, 14 Feb 2008 15:19:38 +0900	[thread overview]
Message-ID: <200802141519.38971.bruno@thinktube.com> (raw)
In-Reply-To: <1202809819.11481.87.camel@johannes.berg>

On Tuesday 12 February 2008 18:50:19 Johannes Berg wrote:
> > thats a very good point! if everything was calibrated properly and =
all
> > delays taken into account *exactly* that would cause us to go thru =
a
> > merge all the time, on every received beacon. i think we have to ta=
ke
> > that into account, for different bitrates. what about something lik=
e:
> >
> > timestamp >=3D ( mactime + (24 * 8 / beacon_phy_rate_in_mbps ))
>
> Looks reasonable, though I'm not entirely sure how we defined 'mactim=
e'
> and whether it is at the first data or the first phy symbol. I think
> it's at the first data symbol which makes this correct.

hmm, it seems we don't have a strict definition of mactime... the kerne=
ldoc of=20
struct ieee80211_rx_status says:
 * @mactime: MAC timestamp as defined by 802.11

but as far as i understand 802.11, it only defines "timestamp" for beac=
on and=20
probe response frames, where it actually means the timestamp field of t=
he=20
frame.

"Local Time" is defined as: "The value of the STA=E2=80=99s TSF timer a=
t the start of=20
reception of the first octet of the timestamp field of the received fra=
me=20
(probe response or beacon) from the found BSS." [802.11 p. 103]

also in "Process Validate_MPDU: it says:
"Save arrival time of first octet of {what may be a} timestamp field."
[802.11 p 391 and 460]

which could imply that this value is given as a rx timestamp (mactime).=
 in=20
that case we could directly compare timestamp and mactime.

radiotap on the other hand defines it as the first bit of the data (MPD=
U):
 * IEEE80211_RADIOTAP_TSFT              u_int64_t       microseconds
 *
 *      Value in microseconds of the MAC's 64-bit 802.11 Time
 *      Synchronization Function timer when the first bit of the
 *      MPDU arrived at the MAC. For received frames, only.

so i guess right now it depends on the hardware what we actually get as=
=20
mactime...

i could not find any definition when the rx timestamp of atheros hardwa=
re is=20
taken.

do we have that information for other hardware? is mactime
 *) the TSF at the reception of the first phy symbol?
 *) the TSF at the reception of the first data (MPDU) symbol
 *) the TSF at the reception of the byte 24 (where the timestamp field =
of
    beacon and probe response frames is)?

bruno
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2008-02-14  6:20 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-05 10:49 [PATCH 0/2] ibss merge resend Bruno Randolf
2008-02-05 10:49 ` [PATCH 1/2] mac80211: move function ieee80211_sta_join_ibss() Bruno Randolf
2008-02-05 10:49 ` [PATCH 2/2] mac80211: enable IBSS merging Bruno Randolf
2008-02-05 11:08   ` Johannes Berg
2008-02-06  2:46     ` [PATCH] addressing johannes latest comments and adding a channel check Bruno Randolf
2008-02-06  2:59       ` [ath5k-devel] " bruno randolf
2008-02-06  2:49     ` [PATCH] mac80211: enable IBSS merging Bruno Randolf
2008-02-06 23:52       ` Johannes Berg
2008-02-08  9:25         ` Luis R. Rodriguez
2008-02-12  3:25         ` bruno randolf
2008-02-12  9:50           ` Johannes Berg
2008-02-14  6:19             ` bruno randolf [this message]
2008-02-14 14:12               ` Johannes Berg
2008-02-12  9:52           ` Johannes Berg
2008-02-14 10:19             ` bruno randolf
  -- strict thread matches above, loose matches on Subject: below --
2008-02-15 15:09 [PATCH 3/3] " Johannes Berg
2008-02-16  2:29 ` [PATCH] " Bruno Randolf
2008-02-17  9:11   ` Johannes Berg
2008-02-18  1:42     ` bruno randolf
2008-02-18 11:15       ` Johannes Berg
2008-02-18  2:03     ` bruno randolf
2008-02-18 11:16       ` Johannes Berg
2008-02-08  9:41 Joerg Pommnitz
2008-01-18 12:52 Bruno Randolf
2008-01-20 10:17 ` Luis R. Rodriguez
2008-01-20 10:43   ` Ivo van Doorn
2008-01-21  1:52     ` bruno randolf
2008-01-21 16:05       ` Ivo van Doorn
2008-01-22 19:47         ` Luis R. Rodriguez
2008-01-22 19:54           ` Ivo van Doorn
2008-01-22 20:32             ` Luis R. Rodriguez
2008-01-22 20:51               ` Ivo van Doorn
2008-01-22 23:16             ` Adam Baker
2008-01-22 23:25               ` Ivo van Doorn
2008-01-23 14:49     ` Johannes Berg
2008-01-24  5:51       ` bruno randolf
2008-01-21  1:57   ` bruno randolf
2008-01-23 14:48 ` Johannes Berg
2008-01-23 17:22   ` Dan Williams
2008-01-24  3:49     ` bruno randolf
2008-01-24  3:26   ` bruno randolf
2008-01-24 16:55     ` Johannes Berg
2008-01-25  8:01       ` bruno randolf
2008-02-02 23:22         ` Luis R. Rodriguez
2008-02-05  1:50           ` bruno randolf
2008-02-05  1:56             ` Luis R. Rodriguez
2008-02-06 10:01             ` Johannes Berg
2008-02-06  4:34           ` Jouni Malinen
2008-02-06 18:33             ` Luis R. Rodriguez
2008-02-06 20:10               ` John W. Linville
2008-02-07  3:58                 ` Jouni Malinen
2008-02-08  9:22                   ` Luis R. Rodriguez
2008-02-12  2:00                     ` bruno randolf
2008-02-15  1:06                       ` Luis R. Rodriguez
2008-02-15  1:40                         ` bruno randolf
2008-02-07  3:52               ` Jouni Malinen
2008-02-08  9:10                 ` Luis R. Rodriguez
2008-01-24  5:43   ` bruno randolf
2008-01-24  8:51     ` Kalle Valo
2008-01-24 14:27       ` Johannes Berg
2008-01-24 14:30     ` Johannes Berg
2008-01-25  6:16       ` bruno randolf

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=200802141519.38971.bruno@thinktube.com \
    --to=bruno@thinktube.com \
    --cc=ath5k-devel@lists.ath5k.org \
    --cc=flamingice@sourmilk.net \
    --cc=jbenc@suse.cz \
    --cc=jirislaby@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@gmail.com \
    --cc=mickflemm@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).