On Sunday 20 January 2008 11:12:11 Derek Smithies wrote: > On Sat, 19 Jan 2008, Luis R. Rodriguez wrote: > > On Jan 18, 2008 7:50 AM, Bruno Randolf <bruno@xxxxxxxxxxxxx> wrote: > > > + * always extend the mac timestamp, since this > > > information is + * also needed for proper IBSS merging. > > > + * > > > + * XXX: it might be too late to do it here, since > > > rs_tstamp is + * 15bit only. that means TSF extension > > > has to be done within + * 32.768usec = 32ms. it might be > > > necessary to move this to the + * interrupt handler, > > > like it is done in madwifi. + */ > > > > I'm trying to understand this a bit more and am confused. The TSF > > timer is based on 1MHz clock so it has a resolution of 1 microsecond > > (us). For 15 bits that would mean 32768 us so don't you mean it should > > be done within 32.768 ms instead of usec (or us)? > > Hi, > it is a typo. it's just a different way to use a "." to denote 1000. americans might write 32,768usec, im not sure, different styles worldwide... what i mean is 32768us equals about 32ms. i'll remove that dot to make it unambigous. > You are correct. It should be done within 32.768 ms. On a high end laptop, > it is almost guaranteed that the bottom half will process the packet > within 32 ms. However, on an embedded box (low spec cpu) that has a > temporarily high load, 32 ms is a short time, and the timestamp may have > wrapped around. this is unfortunate. i know that this might happen, and that's why i included this comment. i was just too lazy to make the same act as is done in madwifi (lopping thru all rx descriptors in the interrupt handler). the current code is sufficient for IBSS testing right now. also even if we move TSF extension into the interrupt handler this will not help in all cases. there are situations in IBSS mode - when a HW merge (= automatic HW TSF update upon receipt of a beacon with a higherr TSF and the same BSSID) happens - where the rx timestamp is apparently based on the old TSF, before the HW TSF is updated. in that case we cannot extend the timestamp in any meaningful way. i'm not sure how we should handle this. > On Sat, 19 Jan 2008, Luis R. Rodriguez wrote: > Right now we only use mactime and even RX_FLAG_TSFT within mac80211 in > rx.c on ieee80211_rx_monitor() for IEEE80211_RADIOTAP_TSFT so right > now these changes would seem to do nothing. Should we be using this > for something else -- if so what is it? see my "[PATCH] mac80211: enable IBSS merging". it is used there to decide wether we have to merge IBSS on receipt of a beacon. strictly speaking it would be sufficient to extend the rxstamp only for beacons and in monitor mode, but i thought checking for these cases is more overhead, so why not extend TSF all the time... bruno - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
