On Tue 12.02.08 12:25, bruno randolf wrote:
> On Thursday 07 February 2008 08:52:35 Johannes Berg wrote:
> > Looks fine, one last question:
> > > + if (mactime <= timestamp) {
> > > + if (CONFIG_MAC80211_IBSS_DEBUG || net_ratelimit())
> > > + printk(KERN_DEBUG "%s: beacon TSF higher than "
> > > + "local TSF - IBSS merge with BSSID %s\n",
> > > + dev->name, print_mac(mac, mgmt->bssid));
> >
> > I'd rewrite that as timestamp >= mactime and rename the two variables
> > (maybe beacon_timestamp and phy_timestamp or so?), but that's not too
> > important.
>
> i'll do that, sure.
>
> > However, in any case "<=" seems wrong, shouldn't we only
> > merge when it's actually higher? If your hardware/firmware has synced
> > properly and the PHY delay is accounted for properly etc. then every
> > beacon from the own BSS will fulfil the == part of the condition, no?
>
> true. i was not aware that the beacon timestamp is taking PHY delays into
> account and wrongly asumed that the RX timestamp should always be a bit
> later.
> (which is also what i saw on my atheros hardware: we usually get the RX
> timestamp about 60 to 300 usec later than the beacon timestamp, but it's
> quite likely that we have not calibrated everything 100% correctly.)
I did some measurements on this and can confirm that the RX timestamp
is, when stations are in sync, always a bit after the beacon timestamp.
I usually get two values - one that's met in 90% of the cases and one
for the other 10% that is 50usecs higher. Very weird!
So for example I have one station that usually gives me 345 usecs
difference and sometimes a 394 in between. Its neighbor gives me 323 and
sometimes 375. I also have other nodes that give values around 450. If
anyone's interested in the dumps say the word.
I was very disappointed by this because I thought the TSF would allow
microsecond precision. As I recall the standard says that the clock can
be "25 parts per minute" off.
Because I wanted to know if these 50 usec offsets mean that a hw sync
has happened, I took the TSC and calibrated it against the TSF to get to
microseconds(the calibration done by the scheduler for sched_clock() is
far off against the TSF). Unfortunately, I didn't get anything
conclusive from comparing adjusted TSC and TSF.
When I have more than 2 stations values aren't that constant anymore -
hw is constantly adjusting. By the way, do you know of a way to disable
hardware tsf sync on beacons?
>
> > Also, the beacon timestamp is defined as follows:
> >
> > A STA sending a beacon shall set the value of the beacon’s
> > timestamp so that it equals the value of the STA’s TSF timer at
> > the time that the data symbol containing the first bit of the
> > timestamp is transmitted to the PHY plus the transmitting STA’s
> > delays through its local PHY from the MAC-PHY interface to its
> > interface with the WM [e.g., antenna, light-emitting diode (LED)
> > emission surface].
> >
> > (IEEE 802.11 11.1.2)
> >
> > Since we define the RX timestamp to be when the first data symbol of the
> > frame hits the PHY, we here have to take into account the offset between
> > the two, at 1 MBit that's 192 (=24 bytes * 8 usecs/byte) usecs earlier
> > than the beacon timestamp.
> >
> > On the other hand, you're unlikely to hit that window, but I suppose it
> > warrants at least a comment.
>
> 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 take that into account,
> for different bitrates. what about something like:
>
> timestamp >= ( mactime + (24 * 8 / beacon_phy_rate_in_mbps ))
>
> i'll resend my patch adding that and the other proposed changes soon.
>
> bruno
> _______________________________________________
> ath5k-devel mailing list
> [email protected]
> https://lists.ath5k.org/mailman/listinfo/ath5k-devel
_______________________________________________
ath5k-devel mailing list
[email protected]
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
