Date: Wed, 27 Feb 2013 16:55:16 +0800 From: "adam.huang" <sniperpr@gmail.com> To: Mukunda Haveri <mukunda@pointred.co> Cc: freebsd-wireless@freebsd.org, freebsd-mips@freebsd.org Subject: =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=WiFi TDMA AR7161, results and moving forward Message-ID: <1BB5E063EDB64336B8482336F34B0555@gmail.com> In-Reply-To: <CAK3PU_DwXmZVR=jo-WF3DMLxaNF=hd8qWnyw6VWt0tS7iZ2XeQ@mail.gmail.com> References: <CAK3PU_C9AW3xO1mofwT1iH_bgrBDYk3zJaLMJCbiRN-jakm%2BFA@mail.gmail.com> <CAJ-Vmo=eRboDNE-5JhQWq8zvsPnGt%2B7-KjZGBcw8RdQmK2q5jw@mail.gmail.com> <CAK3PU_DwXmZVR=jo-WF3DMLxaNF=hd8qWnyw6VWt0tS7iZ2XeQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
hi, can you share your complex =46W=3F thanks. =20 =E5=9C=A8 2013=E5=B9=B42=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=884:51=EF=BC=8CMukunda Haveri =E5=86=99=E9=81=93=EF= =BC=9A > Hi, > =20 > I have been trying in vain to get 2 freebsd based systems working with = a > wlan-lan bridge. > =20 > =7C Host A =7C <---> =7C Lan-side arge0 =7C <--> =7C AP Wlan =7C <--- A= ir ------- > > =7C STA Wlan =7C <---> =7C Lan-side arge0 =7C <--> =7C Host B =7C > =20 > Is this functionality broken on the head=3F OR Am I missing something=3F= > Appreciate if somebody can help me with scripts to setup the traffic in= the > mode mentioned above. > We are using AR9280 based wireless card along with AR7161 boards from > Compex... > =20 > Thanks, > Mukunda > =20 > =20 > On Tue, =46eb 19, 2013 at 2:58 AM, Adrian Chadd <adrian=40freebsd.org (= mailto:adrian=40freebsd.org)> wrote: > =20 > > On 18 =46ebruary 2013 03:31, Mukunda Haveri <mukunda=40pointred.co (m= ailto:mukunda=40pointred.co)> wrote: > > > =20 > > > Thanks to Adrian's Wi=46i scripts, we were able to get the TDMA wor= king on > > the > > > Compex-AR7161 board. The results were surprising; we are able to do= , > > =20 > > close > > > to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in > > =20 > > non-TDMA > > > mode. We were able to achieve this, only after disabling all the de= bug > > > options in the kernel. Porting the U-Boot to the Compex-boards did = take > > > =20 > > =20 > > lot > > > of effort, but not the =22=46reeBsd=22. Many thanks to all the =22s= cientists=22 who > > > made this possible. > > > =20 > > =20 > > =20 > > Nice=21 Which wireless cards are you using=3F > > =20 > > =5B AR9280 =5D > =20 > =20 > > > Moving forward, it is observed that the TDMA throughput peaks at 9 = mbps > > and > > > refuses to move beyond. After reducing the slot duration to 1 ms, t= he > > > throughput increased to around 12 mbps. I was expecting the TDMA to= > > > =20 > > =20 > > yield a > > > better throughput because of collision-less scheme. I would like to= > > > understand if our observation is expected or if there's some inhere= nt > > > limitation within the TDMA controller. > > > =20 > > > It will be good to have some feedback from TDMers with similar > > experience or > > > better. > > =20 > > =20 > > Right now the TDMA code doesn't implement MCS rates or TX aggregation= . > > Thus you're not going to get 11n like throughput. > > =20 > > The first thing to implement is allowing for MCS rates > > (non-aggregation) and make sure all the packet duration calculations > > are being done =22right=22. > > =20 > > After that, we need to implement delayed blockack support in net80211= > > and the ath driver. That requires the stack to support handling BA > > requests/responses and ath(4) to mark all frame descriptors in a > > delayed-BA TID to be no-ack. > > =20 > > Once that's done, we can tie it all together to make it work over TDM= A. :-) > > =20 > > Thanks, > > =20 > > =20 > > Adrian > =20 > DISCLAIMER: > The information contained in this message (including any attachments) i= s confidential and may be privileged. If you have received it by mistake = please notify the sender by return e-mail and permanently delete this mes= sage and any attachments from your system. Any dissemination, use, review= , distribution, printing or copying of this message in whole or in part i= s strictly prohibited. Please note that e-mails are susceptible to change= . PointRed Telecom Ltd (including its group companies) shall not be liabl= e for the improper or incomplete transmission of the information containe= d in this communication nor for any delay in its receipt or damage to you= r system and does not guarantee that the integrity of this communication = has been maintained or that this communication is free of viruses, interc= eptions or interferences. =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > freebsd-mips=40freebsd.org (mailto:freebsd-mips=40freebsd.org) mailing = list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to =22freebsd-mips-unsubscribe=40freebsd.= org (mailto:freebsd-mips-unsubscribe=40freebsd.org)=22 > =20 > =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1BB5E063EDB64336B8482336F34B0555>