Thread: [Madwifi-devel] ath_beaconinit vs ath_beacon_tasklet: which one controls the beacon generation
Status: Beta
Brought to you by:
otaku
From: warshi n. <ish...@ya...> - 2004-07-24 06:15:28
|
hi, I am trying to create my own beacon generator so that i can control the beacon interval in master mode. To achieve this i disabled the HAL_SWBA interrupt and created a beacon generator that runs on a timer. The beacon generator code replicates the code for handle_beacon_tasklet in the madwifi driver. But i face the following problems: 1. While listening for the beacons from another machine, i notice the beacon interval being rounded to 102.4 ms. Even if i set the timer to 50ms the beacons still come out every 102.4ms. 2. When i remove ath_hal_beaconinit function call this problem does not occur. The beacon interval is 50ms. But i face another problem. There are long gaps of 58 seconds between some of the beacons i.e. after receiving say 200 beacons with the interval i set, there is a long gap till the next beacon is sent. My question is does the fimrware control the beacon generation or should the driver create the beacon frames for transmission? If i disable the ath_hal_beaconinit the card seems to "sleep" for a 30-50 seconds. I would appreciate any help to this problem. ishwar __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
From: Sam L. <sa...@er...> - 2004-07-25 02:42:38
|
On Jul 23, 2004, at 11:15 PM, warshi nimara wrote: > hi, > I am trying to create my own beacon generator so that > i can control the beacon interval in master mode. To > achieve this i disabled the > HAL_SWBA interrupt and created a beacon generator that > runs on a timer. The beacon generator code replicates > the code for handle_beacon_tasklet in the madwifi > driver. Seems like you'd do better to just change the timers that fire SWBA. > > But i face the following problems: > > 1. While listening for the beacons from another > machine, > i notice the beacon interval being rounded to 102.4 > ms. Even if i set the timer to 50ms the beacons still > come out every 102.4ms. You don't indicate how you are sending beacons. If you use the beacon transmit queue then they will be gated by the beacon timers. In normal operation the SWBA is posted to the host based on the timers configured by ath_hal_beaconinit. The interrupt is delivered early enough for the host to setup the beacon frame on the beacon xmit queue. The frame then gets sent at the correct time. > > 2. When i remove ath_hal_beaconinit function call this > problem does not occur. The beacon interval is 50ms. > But i face another problem. There are long gaps of 58 > seconds between some of the beacons i.e. after > receiving say 200 beacons with the interval i set, > there is a long gap till the next beacon is sent. See above. The gaps are probably the beacon timers wrapping. > > My question is does the fimrware control the beacon > generation or should the driver create the beacon > frames for transmission? If i disable the > ath_hal_beaconinit the card seems to "sleep" for a > 30-50 seconds. I would appreciate any help to this > problem. Repeat after me, "THERE IS NO FIRMWARE, THERE IS NO FIRMWARE". How about you start by explaining what you're trying to do. "create my own beacon generator" doesn't tell me enough. Sam |
From: warshi n. <ish...@ya...> - 2004-07-25 05:51:44
|
hi, Thanks for the reply Sam. That explains a lot. Here is what i am trying to do: I need to generate beacons across a group of access points that are in sync with each other. I need to correct the drift of the clock (which i am assuming is in the card - pls correct me if i am wrong) which is pretty significant over a day. I am trying to solve this problem by using NTP and the system clock. Before i send the beacon to the beacon queue, i check the time using do_gettimeofday and correct the drift if any. If the drift is negative by 2 or 3 ms, the next timer for beacon is set late to offset the drift. A postive drift is corrected by setting the next timer early. I am running NTP on all the access points to make sure gettimeofday is as accurate as possible. As u deduced, i was using the beacon queue to send the beacons. So if i don't call the ath_beaconinit and fill the queue with beacons sent at intervals controlled by me, what will happen? Could you explain the timer wrapping problem more? i didn't get it. I am guessing the only way to avoid the problem is to make the beacon queue a HAL_TX_QUEUE_DATA so that the beacon packets are sent as soon as i write them to the queue than waiting till the beacon timer. I tested this and it looks okay. Would this approach work? Would i be losing on performance/priority be using the DATA queue. ....and "THERE IS NO FIRMWARE" gotcha chief. ishwar --- Sam Leffler <sa...@er...> wrote: > On Jul 23, 2004, at 11:15 PM, warshi nimara wrote: > > > hi, > > I am trying to create my own beacon generator so > that > > i can control the beacon interval in master mode. > To > > achieve this i disabled the > > HAL_SWBA interrupt and created a beacon generator > that > > runs on a timer. The beacon generator code > replicates > > the code for handle_beacon_tasklet in the madwifi > > driver. > > Seems like you'd do better to just change the timers > that fire SWBA. > > > > > But i face the following problems: > > > > 1. While listening for the beacons from another > > machine, > > i notice the beacon interval being rounded to > 102.4 > > ms. Even if i set the timer to 50ms the beacons > still > > come out every 102.4ms. > > You don't indicate how you are sending beacons. If > you use the beacon > transmit queue then they will be gated by the beacon > timers. In normal > operation the SWBA is posted to the host based on > the timers configured > by ath_hal_beaconinit. The interrupt is delivered > early enough for the > host to setup the beacon frame on the beacon xmit > queue. The frame > then gets sent at the correct time. > > > > > 2. When i remove ath_hal_beaconinit function call > this > > problem does not occur. The beacon interval is > 50ms. > > But i face another problem. There are long gaps of > 58 > > seconds between some of the beacons i.e. after > > receiving say 200 beacons with the interval i set, > > there is a long gap till the next beacon is sent. > > See above. The gaps are probably the beacon timers > wrapping. > > > > > My question is does the fimrware control the > beacon > > generation or should the driver create the beacon > > frames for transmission? If i disable the > > ath_hal_beaconinit the card seems to "sleep" for a > > 30-50 seconds. I would appreciate any help to this > > problem. > > Repeat after me, "THERE IS NO FIRMWARE, THERE IS NO > FIRMWARE". > > How about you start by explaining what you're trying > to do. "create my > own beacon generator" doesn't tell me enough. > > Sam > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic > Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 > today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail |
From: Sam L. <sa...@er...> - 2004-07-28 04:07:15
|
On Jul 24, 2004, at 10:51 PM, warshi nimara wrote: > hi, > Thanks for the reply Sam. That explains a lot. > > Here is what i am trying to do: I need to generate > beacons across a group of access points that are > in sync with each other. I need to correct the drift > of the clock (which i am assuming is in the card - pls > correct me if i am wrong) which is pretty significant > over a day. I am trying to solve this problem by using > NTP and the system clock. Before i send the beacon > to the beacon queue, i check the time using > do_gettimeofday and correct the drift if any. If the > drift is negative by 2 or 3 ms, the next timer for > beacon is set late to offset the drift. A postive > drift is corrected by setting the next timer early. I > am running NTP on all the access points to make sure > gettimeofday is as accurate as possible. Why do you want all AP's to send beacons at the same time? > > As u deduced, i was using the beacon queue to send the > beacons. > So if i don't call the ath_beaconinit and fill the > queue with beacons sent at intervals controlled by > me, what will happen? Could you explain the timer > wrapping problem more? i didn't get it. Frames on the beacon queue are sent out when a h/w timer triggers. Prior to this trigger the host gets a SWBA interrupt so it has a chance to construct and post the frame to the queue. ath_hal_beaconinit sets up the h/w timers resets the TSF to start it counting. If you don't call ath_hal_beaconinit then obviously this stuff won't happen. I'm not sure if something else will kick the timers into action but if so then the hardware won't be properly setup and any frames you post to the queue will be gated (i.e. transmitted) at unknown times. > > I am guessing the only way to avoid the problem is to > make the beacon queue a HAL_TX_QUEUE_DATA so that the > beacon packets are sent as soon as i write them to the > queue than waiting till the beacon timer. I tested > this and it looks okay. Would this approach work? > Would i > be losing on performance/priority be using the DATA > queue. If you transmit beacon frames from a different queue then they may be delayed and/or not transmitted at proper intervals. There's some magic that happens for beacons to insure, for example, that timestamps in the outgoing frames are accurate. I still don't understand why you want all your ap's synchronized but you pretty much have to do it at the point where you call ath_hal_beaconinit since after that time intervals are fixed. Posting the beacons entirely from software is likely to result in jitter that may not be tolerated by stations (especially in an ibss). Sam |