Thread: [Madwifi-devel] Long distance problems - Atheros 5211
Status: Beta
Brought to you by:
otaku
From: Marcin P. <pi...@cl...> - 2003-12-26 12:10:48
|
Hello, Using the madwifi driver at 3.7 km distance produces duplicate packets, and the transfer rates are down to ~1MBit, both in turbo and normal modes. Apparenly, there is a ?bug? in the driver/hal, possibly the card does not wait for enough time for ACK packet to arrive after TX operation. In addition to my mail sent on 6th December, I noticed that every successfull TX is coupled with error in ifconfig stats... TX packets:150027 errors:148351 dropped:0 overruns:0 carrier:0 .. TX packets:150039 errors:148363 dropped:0 overruns:0 carrier:0 .. TX packets:150049 errors:148373 dropped:0 overruns:0 carrier:0 .. TX packets:150354 errors:148678 dropped:0 overruns:0 carrier:0 What's worth noting: At the distance of 2.2 km, the bug shows _only_ in normal (turbo = 0) mode, at 3.7 km - both. IP fragmentation also shows interesting behaviour: [root@...]# ping -n 192.168.8.9 -s 1472 PING 192.168.8.9 (192.168.8.9) from 192.168.8.8 : 1472(1500) bytes of data. 1480 bytes from 192.168.8.9: icmp_seq=1 ttl=64 time=2.12 ms 1480 bytes from 192.168.8.9: icmp_seq=2 ttl=64 time=4.20 ms 1480 bytes from 192.168.8.9: icmp_seq=2 ttl=64 time=32.8 ms (DUP!) 1480 bytes from 192.168.8.9: icmp_seq=3 ttl=64 time=0.939 ms 1480 bytes from 192.168.8.9: icmp_seq=3 ttl=64 time=42.4 ms (DUP!) 1480 bytes from 192.168.8.9: icmp_seq=4 ttl=64 time=1.56 ms 1480 bytes from 192.168.8.9: icmp_seq=5 ttl=64 time=1.39 ms 1480 bytes from 192.168.8.9: icmp_seq=6 ttl=64 time=0.923 ms [root@....]# ping -n 192.168.8.9 -s 1473 PING 192.168.8.9 (192.168.8.9) from 192.168.8.8 : 1473(1501) bytes of data. 1481 bytes from 192.168.8.9: icmp_seq=1 ttl=64 time=79.5 ms 1481 bytes from 192.168.8.9: icmp_seq=2 ttl=64 time=69.6 ms 1481 bytes from 192.168.8.9: icmp_seq=3 ttl=64 time=81.0 ms 1481 bytes from 192.168.8.9: icmp_seq=4 ttl=64 time=80.8 ms 1481 bytes from 192.168.8.9: icmp_seq=5 ttl=64 time=78.0 ms 1481 bytes from 192.168.8.9: icmp_seq=6 ttl=64 time=66.7 ms 1481 bytes from 192.168.8.9: icmp_seq=7 ttl=64 time=63.0 ms 1481 bytes from 192.168.8.9: icmp_seq=8 ttl=64 time=74.8 ms Such huge difference between 1500 and 1501 byte packets is far from normal. Is this related to ACK timing? If yes, can I increase this value? Both links are standing by for testing. The cards are working perfectly at short ranges, even with the same signal levels. Thanks in advance -- Marcin Pilch ath_hal: 0.9.6.3 wlan: 0.7.2.0 BETA ath_pci: 0.8.4.0 BETA ath0: Atheros 5211: mem=0xdfee0000, irq=9 |
From: Marcin P. <pi...@cl...> - 2003-12-28 22:26:23
|
> > There was some discussion going on earlier about changing the slot time. > You can find the default settings in the ah.h file if I remember > correctly. The defaults were 9us and 20us. Have you tried increasing > these? In the changelog for the ah.h file it mentions the following > implement ah_setSlotTime for 5211 parts. > I need to tackle this after the first of the year also and would be > interested in knowing what you find out. > Jim > I tried changing these values (from 21 to 100+), and I tried calling the ah_setSlotTime from several places inside the driver. +if (ah->ah_setSlotTime(ah, HAL_SLOT_TIME_20)==AH_TRUE) + printk("success - setting slot time\n"); else + printk("failure - setting slot time\n"); According to the discussion about changing the slot time you mentioned (available at http://sourceforge.net/mailarchive/forum.php?thread_id=3483397&forum_id=33958 ) we need to change the slot time _and_ the ack time. There is also a note, that it works only on Atheros 5212, but ah_setSlotTime always returned AH_TRUE in my case. Where should I put ah_setSlotTime call, and what about setting the ack time? Thanks again, -- Marcin Pilch |
From: Jim T. <ji...@te...> - 2003-12-30 04:49:29
|
Marcin Pilch said: > >> >> There was some discussion going on earlier about changing the slot time. >> You can find the default settings in the ah.h file if I remember >> correctly. The defaults were 9us and 20us. Have you tried increasing >> these? In the changelog for the ah.h file it mentions the following >> implement ah_setSlotTime for 5211 parts. >> I need to tackle this after the first of the year also and would be >> interested in knowing what you find out. >> Jim >> > > I tried changing these values (from 21 to 100+), and I tried calling the > ah_setSlotTime from several places inside the driver. > > +if (ah->ah_setSlotTime(ah, HAL_SLOT_TIME_20)==AH_TRUE) > + printk("success - setting slot time\n"); else > + printk("failure - setting slot time\n"); > > According to the discussion about changing the slot time you mentioned > (available at > http://sourceforge.net/mailarchive/forum.php?thread_id=3483397&forum_id=33958 > ) we need to change the slot time _and_ the ack time. There is also a > note, that it works only on Atheros 5212, but ah_setSlotTime always > returned AH_TRUE in my case. > > Where should I put ah_setSlotTime call, and what about setting the ack > time? I am sure where you would set the ah_setSlotTime call but I was digging around at the Star-OS site as they are also working in the Atheros 5212 and 5211 and they had posted the following concerning ack timing When adjusting the ACK values, use these guidelines: Atheros ar5212 cards - default ACK values: 802.11b mode: 450. 802.11a mode: 180. 802.11g mode: 180. Atheros ar5211 chards - default ACK values: 802.11a mode: 180 802.11b mode: 230 The values above represent the hardware defaults for the cards we have. When you wish to adjust for a longer link, increase the numbers beyond the values shown. Setting the value back to 0 will use the card's default. For example, if you wish to extend a 5.8 link, try using a value of 400 or more as a starting point. All values are 1/4 of a microsecond (usec). 100usec equals an ACK value of 400. Has anybody else on the list made any headway on this yet? Jim |
From: Jose M. <jos...@ul...> - 2004-02-17 20:24:44
|
Hi Marcin, Jim Did you find where to place the call to ah->ah_setSlotTime function. I am trying to change this time slot inside the "ath_attach" function. The function call does return AH_TRUE when set to a value >= 9 us, and AH_FALSE when set to < 9us. There is no call to the setSlotTime function anywhere in the driver, so I am wondering if there is a way to confirm what timeslot value is in use (there is no getSlotTime function in the ah structure). I wonder if the hal overwrites this value when switching modes or something. Also, have you figure out how to set the ack time. There is no function in the hal to do that (or maybe there is?) jim> I am sure where you would set the ah_setSlotTime call but I was jim> digging jim> around at the Star-OS site as they are also working in the Atheros jim> 5212 jim> and 5211 and they had posted the following concerning ack timing Could you guys share with the group where to set the timeslot and your findings about the ack time? Thanks Jose this for the 5212 driver, On Sun, 2003-12-28 at 17:25, Marcin Pilch wrote: > > > > There was some discussion going on earlier about changing the slot time. > > You can find the default settings in the ah.h file if I remember > > correctly. The defaults were 9us and 20us. Have you tried increasing > > these? In the changelog for the ah.h file it mentions the following > > implement ah_setSlotTime for 5211 parts. > > I need to tackle this after the first of the year also and would be > > interested in knowing what you find out. > > Jim > > > > I tried changing these values (from 21 to 100+), and I tried calling the > ah_setSlotTime from several places inside the driver. > > +if (ah->ah_setSlotTime(ah, HAL_SLOT_TIME_20)==AH_TRUE) > + printk("success - setting slot time\n"); else > + printk("failure - setting slot time\n"); > > According to the discussion about changing the slot time you mentioned > (available at > http://sourceforge.net/mailarchive/forum.php?thread_id=3483397&forum_id=33958 > ) we need to change the slot time _and_ the ack time. There is also a > note, that it works only on Atheros 5212, but ah_setSlotTime always > returned AH_TRUE in my case. > > Where should I put ah_setSlotTime call, and what about setting the ack time? > > Thanks again, > > -- > > Marcin Pilch > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel |
From: Sam L. <sa...@er...> - 2004-02-19 05:32:36
|
On Feb 17, 2004, at 12:20 PM, Jose Mortensen wrote: > Hi Marcin, Jim > > Did you find where to place the call to ah->ah_setSlotTime function. > I am trying to change this time slot inside the "ath_attach" function. > The function call does return AH_TRUE when set to a value >= 9 us, and > AH_FALSE when set to < 9us. There is no call to the setSlotTime > function > anywhere in the driver, so I am wondering if there is a way to confirm > what timeslot value is in use (there is no getSlotTime function in the > ah structure). I wonder if the hal overwrites this value when switching > modes or something. The hal doesn't change the slot time. I can't recall if the setting is preserved across chip resets. I'm not sure you mean by a "mode switch or something". > Also, have you figure out how to set the ack time. There is no function > in the hal to do that (or maybe there is?) There is no function to change the ack timeout; this is the often requested feature that's not been done yet. > jim> I am sure where you would set the ah_setSlotTime call but I was > jim> digging > jim> around at the Star-OS site as they are also working in the Atheros > jim> 5212 > jim> and 5211 and they had posted the following concerning ack timing > > Could you guys share with the group where to set the timeslot and your > findings about the ack time? See above. Sam |
From: Jose M. <jos...@ul...> - 2004-02-20 19:47:01
|
Hi Sam Thanks for the answer. On Thu, 2004-02-19 at 00:27, Sam Leffler wrote: > On Feb 17, 2004, at 12:20 PM, Jose Mortensen wrote: > > > Hi Marcin, Jim > > > > Did you find where to place the call to ah->ah_setSlotTime function. > > I am trying to change this time slot inside the "ath_attach" function. > > The function call does return AH_TRUE when set to a value >= 9 us, and > > AH_FALSE when set to < 9us. There is no call to the setSlotTime > > function > > anywhere in the driver, so I am wondering if there is a way to confirm > > what timeslot value is in use (there is no getSlotTime function in the > > ah structure). I wonder if the hal overwrites this value when switching > > modes or something. > > The hal doesn't change the slot time. I can't recall if the setting > is preserved across chip resets. I'm not sure you mean by a "mode > switch or something". > I mean when the card is in "auto" mode scanning frequencies from 11A to 11B. A dn B have different timeslot settings (9 and 20 us) so could it be that the hal overrites this setting when switching?. > > Also, have you figure out how to set the ack time. There is no function > > in the hal to do that (or maybe there is?) > > There is no function to change the ack timeout; this is the often > requested feature that's not been done yet. > Could you point me to the place, where the ack timeout is handled. I could modify the source to hard code it to a different value or create an interface for it. could it be on: if_ath.c: ath_mgtstart(struct sk_buff *skb, struct net_device *dev) { .... if ((wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK) == IEEE80211_FC0_SUBTYPE_PROBE_RESP) { /* fill time stamp */ u_int64_t tsf; u_int32_t *tstamp; tsf = ath_hal_gettsf64(ah); /* XXX: adjust 100us delay to xmit */ tsf += 100; tstamp = (u_int32_t *)&wh[1]; tstamp[0] = cpu_to_le32(tsf & 0xffffffff); tstamp[1] = cpu_to_le32(tsf >> 32); } .... } I need to to some long distance tests, so this is very important for us. > > jim> I am sure where you would set the ah_setSlotTime call but I was > > jim> digging > > jim> around at the Star-OS site as they are also working in the Atheros > > jim> 5212 > > jim> and 5211 and they had posted the following concerning ack timing > > > > Could you guys share with the group where to set the timeslot and your > > findings about the ack time? > > See above. > > Sam > Thanks for your help Jose |
From: Mathieu L. <Mat...@so...> - 2004-02-23 07:30:57
|
On Fri, 2004-02-20 at 20:40, Jose Mortensen wrote: > Could you point me to the place, where the ack timeout is handled. I > could modify the source to hard code it to a different value or create > an interface for it. Sam meant to say that even though the hardware supports this, this feature is not exported by the HAL which means you cannot use it. Since you most likely do not have the source code for the HAL (it is not public and can only be obtained through proper contract/NDAs with atheros), you cannot modify its source code. I hope this helps, Mathieu -- Mathieu Lacage <mat...@so...> |