Re: [ath9k-devel] tcpdump Data Rate 802.11n
Pieter ROBYNS uhasselt.be> writes: > > > > > Hi Ashutosh, > My guess is that the rate control algorithm overrides your modifications somewhere in the code, since you mentioned that sometimes you get the results you expect. You could try fiddling with /sys/kernel/debug/ieee80211/phyx/rc/fixed_rate_idx in debugfs in order to disable rc, or modify the driver directly. If that's not the cause, then I don't know what the problem is unfortunately. I think a bug in tcpdump is unlikely. > Kind regards, > Pieter > > 2015-02-04 21:33 GMT+01:00 Ashutosh Dhekne gmail.com>: > > > > Hi Pieter, > I am modifying the data rate directly from the driver. So unless the hardware is doing some modifications, the data rate should be the one I set (in a round robin fashion). > > Do you know about any problems with tcpdump causing such inconsistent rate being reported? > > Thanks and Regards, > -Ashutosh > > > On Wed, Feb 4, 2015 at 12:03 PM, Pieter ROBYNS uhasselt.be> wrote: > > > Hi Ashutosh, > Perhaps there is a lot of interference on the channel, which causes your driver to lower the data rate. Did you disable rate control? > Kind regards,Pieter Robyns > > > 2015-02-04 18:11 GMT+01:00 Ashutosh Dhekne gmail.com>: > > > > > > > > Hi All, > I am sending broadcast UDP data using a round robin of 802.11n MCS 0,1,2,3 data rates (6.5Mbps, 13Mbps, 19.5Mbps, 26Mbps). However, the tcpdump output at the receiver looks very strange. It shows some packets as 1Mbps and works correctly some times. > > Does anyone know why this might be happening? > Here is a snapshot of TCP dump:10:57:01.173316 2734594330us tsft 2462 MHz 11g -14dB signal antenna 0 6.5 Mb/s MCS 0 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17927, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.173345 2734594516us tsft 2462 MHz 11g -16dB signal antenna 0 13.0 Mb/s MCS 1 20 MHz lon GI 0us IP (tos 0x0, ttl 64, id 17928, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.275286 2751440865us tsft 2462 MHz 11g -15dB signal antenna 0 19.5 Mb/s MCS 2 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17929, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.275310 2751440967us tsft 2462 MHz 11g -14dB signal antenna 0 26.0 Mb/s MCS 3 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17930, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.275643 2751441058us tsft 2462 MHz 11g -15dB signal antenna 0 6.5 Mb/s MCS 0 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17931, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.275654 2751441244us tsft 2462 MHz 11g -16dB signal antenna 0 13.0 Mb/s MCS 1 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17932, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.275657 2751441369us tsft 2462 MHz 11g -15dB signal antenna 0 19.5 Mb/s MCS 2 20 MHz lon GI 0us IP (tos 0x0, ttl 64, id 17933, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.378071 2734798918us tsft 2462 MHz 11g -16dB signal antenna 0 6.5 Mb/s MCS 0 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17935, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.378103 2734799105us tsft 2462 MHz 11g -15dB signal antenna 0 13.0 Mb/s MCS 1 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17936, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.378108 2734799230us tsft 2462 MHz 11g -15dB signal antenna 0 19.5 Mb/s MCS 2 20 MHz lon GI More Data 0us IP (tos 0x0, ttl 64, id 17937, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.378111 2734799329us tsft 2462 MHz 11g -15dB signal antenna 0 26.0 Mb/s MCS 3 20 MHz lon GI 0us IP (tos 0x0, ttl 64, id 17938, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.480790 2734934023us tsft 1.0 Mb/s 2462 MHz 11g -17dB signal antenna 0 More Data 0us IP (tos 0x0, ttl 64, id 17939, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.482021 2734935233us tsft 1.0 Mb/s 2462 MHz 11g -17dB signal antenna 0 More Data 0us IP (tos 0x0, ttl 64, id 17940, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1.44292 > 255.255.255.255.2050: UDP, length 4210:57:01.483165 2734936381us tsft 1.0 Mb/s 2462 MHz 11g -16dB signal antenna 0 More Data 0us IP (tos 0x0, ttl 64, id 17941
Re: [ath9k-devel] MAC Layer Retransmissions during the same TXOP
Georgios Kyriakou nyu.edu> writes: > > Hey all, > I don't know if this is the best place to ask, thus I apologize in advance. > > Back in the day I was messing around with MadWifi and, if I remember properly, after a packet was transmitted if the sender did not receive an ACK in SIFS time after the completion of the transmission, the sender would attempt a retransmission using the same or lower rate (multi rate retransmissions) without going into the backoff/contention phase. > > I spent some time going through the 802.11-2012 protocol trying to find relevant information without any luck. Is anyone familiar with that concept? Is it implemented that way in ath9k? Is this what the protocol implies? > > Any pointers/suggestions are greatly appreciated. > > Thank you, > George > > > ___ > ath9k-devel mailing list > ath9k-devel lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > It always goes through backoff phase in case of acknowledgement loss. I'm not sure about Minstrel but Atheros RC used to assign lower rates for retransmissions ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Setting Backoff values
According to the best of my knowledge, even in case of missing Acks, backoff window gets increased. On Thursday, July 24, 2014, Stratos Keranidis wrote: > Dear Adrian, > > We are running some tests to see how the frame transmission attempts evolve > in cases that the medium is used only by a single terminal. > > In a low-quality link, we configure the 54 Mbps legacy rate > and observe that although the frame delivery rate is quite low (30%), > the transmission attempts reach the maximum values. > > This can only be explained by the CW reset policy that you mentioned in > the previous mail, > which in cases of missing ACKs, the CW is reset to CWmin for newly > arriving frames, > and is only doubled across Retransmissions of the same frame. > > Is this policy consistent with the policy described in the standard, which > specifies that the CW is reset to CWmin only upon a successful transmission? > > Thank you, > Stratos. > > > > > -- Sent from Gmail Mobile ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] How to lock AMPDU length at a specific value?
yup, block-ack window limit appears to be the main culprit behind your reduced ampdu lengths. Check ath_tx_form_aggr, there is an if-condition specifically checking whether your are exceeding block-ack window or not. If your sending rate is quite high then increased lossess might trigger this condition quite frequently ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Playing with queue sizes in ath9k
Check the struct ath_txq. It's defined in ath9k.h. You might find it helpful ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Infrastructure mode support for 5/10 Mhz channels
Sergey Ryazanov gmail.com> writes: > > 2013/11/29 Kamran Nishat gmail.com>: > > Hi, > Hi > > > Does anyone ever use used 5/10Mhz channel in infrastructure (AP/client) > > mode. If yes then can you tell me ur Atheros cards versions and rate control > > you used. > > > Few years ago, we tested 5/10MHz channels in infrastructure mode (AP + > several STA) with cards based on AR9280 chip. We used OpenWRT firmware > on both sides of link. All stations were located near the AP (500 > meters or so) and we get a very good throughput with account of > reduced channel width, something around 37 mbps in one direction. > > > I have done this with openwrt with AR9160. But throughput were very bad even > > for very short range. > Could you provide your results, may be they are not so bad. > > > Simon advised me not to mix openwrt nodes with linux nodes for 5/10Mhz > > channel. so Now I ma trying to connect with all Linux nodes on as AP others > > as STA. > Simon is right, OpenWRT realization and pure Linux realization are incompatible. > I have same issue, infact I and Kamran are co-workers. Which exactly OpenWrt firware did you use? We used Attitude Adjustment running on Ubiquiti LiteStation-SR71. I have a hunch that low processing power might be a bottleneck, because we didn't get more than 50 Mbps even at 20 MHz channel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] about ath9k single hop performance
marcus muffin gmail.com> writes: > > > > Hi Muhammad, > > > > > Thanks for your reply. I think there could be 2 solutions. > > > 1. Using multi radio in ap (one channel for receive and other channel for sending) > > > 2. What do you think if I only disable the datalink retry (but keeping the block ack for rate control in 802.11). > > > Do you think both work well? > > > Marcus > > > 2013/11/13 Muhammad Ruwaifa Anwar gmail.com> > marcus muffin gmail.com> writes: > > > > Dear all, > > I am trying to disable acknowledge in mac layer to improve udp performance > of a 3-node network. (i.e. sender -> relay ( ap mode) -> receiver). all > stations are ath9k + mac80211. > > > > For single wireless link (sender to ap or ap to receiver with iperf test). > the udp performance will improve by doing above mentioned ( i.e. 10% > improvement of udp speed, with larger packet loss in application layer since > there is no retry for frames but in general the raw throughput increases). > But when it comes to 2 links (i.e. udp directly from sender to receiver, > also with iperf test), it becomes very unstable and sometimes the > performance drops (I don't understand this part, disabling ack makes a > single wireless link faster but why not the case of two links disabled ack > simultaneously? ). > > > > Best Regards, > > Marcus > > > > > > ___ > > ath9k-devel mailing list > > ath9k-devel lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > > You might be getting lot of collisions. If you have disabled acks, it means > that mac layer has no way of telling that a frame loss has occured, so it > wont increase its backoff window values. This will result in more > collisions. > Secondly, rate control is totally dependant on block acks. Choosing optimal > rate in abscence of acknowledgement information is not possible > ___ > ath9k-devel mailing listath9k-devel lists.ath9k.orghttps://lists.ath9k.org/mailman/listinfo/ath9k-devel > > > > > > > ___ > ath9k-devel mailing list > ath9k-devel lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > Regarding solution 1, even if you have different chanels for sending and receptions. You can't obviously do both of these tasks at the same time with same device. If you can somehow completely isolate both sending and reception than this looks nice About solution 2, according to the best of my knowledge, exponential increase of window is managed by hardware, not by the driver. I don't know you are you going to implement this. Otherwise, this looks good if you are okay with dealing with missed frames at application layer A wild thought, why don't you increase the initial backoff window size (cwmin), so that collisions are less likely to occur PS, if you implement any of your two solutions, do share your implementation details ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] about ath9k single hop performance
marcus muffin gmail.com> writes: > > Dear all, > I am trying to disable acknowledge in mac layer to improve udp performance of a 3-node network. (i.e. sender -> relay ( ap mode) -> receiver). all stations are ath9k + mac80211. > > For single wireless link (sender to ap or ap to receiver with iperf test). the udp performance will improve by doing above mentioned ( i.e. 10% improvement of udp speed, with larger packet loss in application layer since there is no retry for frames but in general the raw throughput increases). But when it comes to 2 links (i.e. udp directly from sender to receiver, also with iperf test), it becomes very unstable and sometimes the performance drops (I don't understand this part, disabling ack makes a single wireless link faster but why not the case of two links disabled ack simultaneously? ). > > Best Regards, > Marcus > > > ___ > ath9k-devel mailing list > ath9k-devel lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > You might be getting lot of collisions. If you have disabled acks, it means that mac layer has no way of telling that a frame loss has occured, so it wont increase its backoff window values. This will result in more collisions. Secondly, rate control is totally dependant on block acks. Choosing optimal rate in abscence of acknowledgement information is not possible ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR5416 Message in Message (MIM)
Kamran Nishat gmail.com> writes: > > > Hi Do u know ar5416 does support Message in Message (MIM) in case of interfering signals Carrier Sense. MIM means means if a recv is looked on one packet and another packet is started coming with higher strength. many Atheros cards leave the weaker signal and start recv the new stronger signal.Regards, > > Kamran > > > > ___ > ath9k-devel mailing list > ath9k-devel lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > Same problem, Did you get any answer? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Setting Backoff values
Ruwaifa Anwar gmail.com> writes: > > We tried changing backoff value range through this function in mac.c > > REG_WRITE(ah, AR_DLCL_IFS(q), > SM(cwMin, AR_D_LCL_IFS_CWMIN) | > SM(qi->tqi_cwmax, AR_D_LCL_IFS_CWMAX) | > SM(qi->tqi_aifs, AR_D_LCL_IFS_AIFS)); > > Setting using 1,1 in place of cwMin and qi->tqi_cwmax respectively is giving > almost the same throughput as with 1, 1023. Doesn't this mean, backoff window > range is not changing properly? What is the correct way to do this. > By calculating number of MPDUs successfully completed per unit time. Secondly i want to claritfy one more thing As you said in previous posts that this alters backoff window for all frames in a queue. What happens if there's a long retry, will hardware still use the given values or use exponentially increased values of cwmin and cwmax ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Setting Backoff values
We tried changing backoff value range through this function in mac.c REG_WRITE(ah, AR_DLCL_IFS(q), SM(cwMin, AR_D_LCL_IFS_CWMIN) | SM(qi->tqi_cwmax, AR_D_LCL_IFS_CWMAX) | SM(qi->tqi_aifs, AR_D_LCL_IFS_AIFS)); Setting using 1,1 in place of cwMin and qi->tqi_cwmax respectively is giving almost the same throughput as with 1, 1023. Doesn't this mean, backoff window range is not changing properly? What is the correct way to do this. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
