Re: [Madwifi-devel] Handover optimizations
Status: Beta
Brought to you by:
otaku
From: Emil I. <emi...@ya...> - 2005-10-29 13:59:55
|
Hey Hakim, > ieee80211_state_name[ic->ic_state], ic->ic_state, > xtime.tv_sec % 10, xtime.tv_nsec / 1000); > > Can't understand here ???? Oh! This was a part of a debug print that I had and forgot to remove in what I sent. Please disregard it and sorry for being that distracted. > if(ic->ic_state == IEEE80211_S_SCAN){ > //set the time to fire in a ms; > mod_timer(&sc->sc_scan_ch, > jiffies + ((HZ * 1) / 1000)); > > And here ???? At that point the timer was set to fire in "dwelltime" ms, which is 200 by default and 100 at the least. So this line simply reschedules the timer to fire in 1 millisecond. To be honest I set it to fire in a millisecond rather than 0 ms as I was not certain of the behaviour that the timer would have for a 0 value and I was afraid that it would be ignored. Now that you mention it however I checked it out and timer.h says: * Timers with an ->expires field in the past will be executed in * the next timer tick. so I guess 0 should be fine and the mod_timer line should be mod_timer(&sc->sc_scan_ch, jiffies); once again sorry for that. One other thing that I forgot to mention in my previous mail. Currently setting a new essid reinits the card: net80211/ieee80211_wireless.c: int ieee80211_ioctl_siwessid(struct ieee80211com *ic, struct iw_request_info *info, struct iw_point *data, char *ssid) { ... ret = IS_UP_AUTO(ic) ? -(*ic->ic_init)(ic->ic_dev) : 0; return ret; } This adds 6 or 7 extra miliseconds to a handover that is otherwise around 10 (i.e. in the case when both freq and essid are specified and no scan is needed). The thing is that I can't really see why is this re-init needed since changing the essid would start a scan anyway if no freq is specified and in the case of specifying a new freq, ieee80211_ioctl_siwfreq would do the re-init itself. I've commented out the reset in my local sandbox and everything seems to be ok for both cases (when setting the channel besides the essid and when only setting an essid). Any thoughts? Thanks Emil > > > } > > > Can you please explain more precisely what's done here! > > Thanks Hakim > > On 10/27/05, *Emil Ivov* <emi...@ya... > <mailto:emi...@ya...>> wrote: > > Hello guys, > > Since you seem to be moving forward to a new code base I decided to send > out modifications that we've done on the current code base in order to > speed up the handover process. > > Now what bothered us most is the fact that when a probe response was > received on the desired frequency from with the desired essid, it did > not end the handover. To resolve this I added a probe_response handler > in the net80211 layer and made sure that scanning is ended once the > right probe response has been received. > > I've pasted the code with some explanations (thought it would be better > than simply sending a patch since the changes are really minor) so that > you see what I mean. > > net80211/ieee80211_var.h: > struct ieee80211com { > ... > + void (*ic_prespreceived)(struct ieee80211com *); > ... > } > > and the corresponding macros: > > #define IEEE80211_PRESPRECEIVED(_ic) do {\ > _ic->ic_prespreceived(_ic); \ > }while(0) > > > > the definition in ath/if_ath.c goes like this: > > static void ath_prespreceived(struct ieee80211com *); > > > and has the following body declared farther in the same file > > + static void ath_prespreceived(struct ieee80211com *ic) > + { > + struct net_device *dev = ic->ic_dev; > + struct ath_softc *sc = dev->priv; > + > + ieee80211_state_name[ic->ic_state], ic->ic_state, > + xtime.tv_sec % 10, xtime.tv_nsec / 1000); > + > + if(ic->ic_state == IEEE80211_S_SCAN){ > + //set the time to fire in a ms; > + mod_timer(&sc->sc_scan_ch, > + jiffies + ((HZ * 1) / 1000)); > + } > + } > > > and of course initialization in > > int ath_attach(u_int16_t devid, struct net_device *dev) > { > ... > ic->ic_newassoc = ath_newassoc; > > + ic->ic_prespreceived = ath_prespreceived; > > ic->ic_updateslot = ath_updateslot; > ... > } > > > This code is called upon reception of a beacon or a probe response in > ieee80211_input.c: > void > ieee80211_recv_mgmt(struct ieee80211com *ic, struct sk_buff *skb, > struct ieee80211_node *ni, > int subtype, int rssi, u_int32_t rstamp) > { > ........ > if (wme != NULL) > ieee80211_saveie(&ni->ni_wme_ie, wme); > if (wpa != NULL) > ieee80211_saveie(&ni->ni_wpa_ie, wpa); > /* NB: must be after ni_chan is setup */ > ieee80211_setup_rates(ic, ni, rates, xrates, IEEE80211_F_DOSORT); > > + //if we got a probe response - we should cancel any scan timers and > + //go on with the scan instead of waiting for another dwelltime ms. > + if(ni->ni_chan == ic->ic_des_chan > + && memcmp(ni->ni_essid, ic->ic_des_essid, ic->ic_des_esslen)==0) > + { > + //do some dbg output in case this is a handover > + if(ic->ic_state == IEEE80211_S_SCAN) > + { > + IEEE80211_PRESPRECEIVED(ic); > + } > + } > break; > ........ > } > > > Finally, to speed the process a little more we've made sure that a probe > request (well actually 2 probe reqs since one of them tends to be lost > in traffic every now and then) gets sent every time when we're doing a > handover. > > ieee80211_proto.c: > static int > ieee80211_newstate(struct ieee80211com *ic, > enum ieee80211_state nstate, int arg) > { > .... > case IEEE80211_S_SCAN: > .... > switch (ostate) { > .... > case IEEE80211_S_SCAN: > .... > ic->ic_flags & IEEE80211_F_ASCAN, > ni->ni_chan->ic_flags & IEEE80211_CHAN_PASSIVE, > xtime.tv_sec % 10,xtime.tv_nsec/1000); > //i've commented the check since all channels seemed to be declared > //passive and forgot to look into the reason later on. > /* if ((ic->ic_flags & IEEE80211_F_ASCAN) &&*/ > /* (ni->ni_chan->ic_flags & IEEE80211_CHAN_PASSIVE) > == 0) {*/ > //a single probe request might often get lost. sending 2 > // seems to work for a relatively sufficient number of > //cases. > + IEEE80211_SEND_MGMT(ic, ni, > + IEEE80211_FC0_SUBTYPE_PROBE_REQ, 0); > IEEE80211_SEND_MGMT(ic, ni, > IEEE80211_FC0_SUBTYPE_PROBE_REQ, > 0); > /* }*/ > break; > > > > Do you think there's any chance of adopting these lines or providing > similar behaviour in the main stream driver? > > Thanks > Emil > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > <mailto:Mad...@li...> > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > <https://lists.sourceforge.net/lists/listinfo/madwifi-devel> > > |