Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jul 2009 20:38:51 +0200
From:      Marten Vijn <info@martenvijn.nl>
To:        Sam Leffler <sam@freebsd.org>
Cc:        mobile@freebsd.org
Subject:   Re: ath0 / wlan0 on 8.0
Message-ID:  <1247251131.5235.147.camel@mvn-desktop>
In-Reply-To: <4A5601CB.3060809@freebsd.org>
References:  <1247090347.10461.7.camel@mvn-desktop> <4A5601CB.3060809@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2009-07-09 at 07:42 -0700, Sam Leffler wrote: 
> Marten Vijn wrote:
> > hi all,
> >
> > When benchmarkmarking an ath0 card an I get these errors.
> > After a could (~10) no traffic is possible anymore.
> >   
> 
> "no traffic is possible" doesn't say enough.  

Retested for beta-1 
- ping does not respond any more.
- the client loses associations.

see: http://www.youtube.com/watch?v=sfE-YskT7XM
for a screen cast


> Do you see beacons from the ap? 

- I still see beacon frames


> Are interrupts being received on the ap? Are you out of 
> resources like mbufs? 

What are the command to produce this information?

> I have seen, for example, things like nightly 
> cron scripts accidentally left to run and kill operation.

Not very likey, It an NET4826, just rebooted, 
this very reproducable it 1 or 2 test runs. 

> 
> > What does this message mean?
> >
> > ath0: stuck beacon; resetting (bmiss count 4)
> > ath0: stuck beacon; resetting (bmiss count 4)
> > ath0: stuck beacon; resetting (bmiss count 4)
> >   
> 
> It means 4 consecutive beacon intervals went by w/o the ap being able to 
> xmit a beacon frame.  When this happens the driver does a h/w reset of 
> the chip and continues.  You can raise this threshold but if it's 
> happening a lot you should understand why.

To much traffic that leads to a dos. I am aware that I create a lot
of traffic. That's why it is benchmark. 

> >
> > # uname -a 
> > FreeBSD  8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Jun 29 21:44:19 CEST
> > 2009     root@master:/usr/obj/nanobsd.node_ap_64M/usr/src/sys/KERNEL
> > i386
> > #
> >
> >   
> The only 8.0 log under "crashes" does not point to a system crash.
> 
> I didn't see information on the wireless setup (e.g. ifconfig commands 
> to setup and/or status to show final operating syste).  Does this happen 
> on all channels?  What else is running on the machine with the ap?  What 
> is the network traffic mix (e.g. tx vs rx)?

I created a new report for 8.0.beta-1 on the site with more info:

http://bsd.wifisoft.org/trac/wiki/crash4  

all (UDP) traffic created on the clients and flows to the server (one
jail per client)  

> I know several groups using the Alix board in similar configs to run 
> production ap's with >10 users but you will need to tune the system for 
> best operation. 

I had 50~60 users concurrent on ap's on ApacheCon Amsterdam in spring.
Ap's did fail every couple of hours/days. That workable for 10 ap's, but
not for > 100.

> Under extreme wireless network load the PCI bus becomes 
> a bottleneck and causes the host to be unable to setup each beacon frame 
> in real-time to satisfy NextTBTT requirements. 
>  Look at how the SWBA mechanism works in the driver and the hw.ath.hal.sw_brt and 
> hw.ath.hal.dma_brt tunables.

Could you give my pointers for documentation/stuff to read? (it will
take me some time to read and maybe understand it. my background not
technical)

> Otherwise stuck beacon conditions can be caused by the ap not getting 
> access to the wireless medium due to it being busy.  You should sniff 
> traffic around the time of a problem for clues.  There are also h/w 
> registers you can observe (e.g. with athregs) to see how busy the medium 
> is from the POV of the ap.  There have been chip bugs related to this 
> condition but doing a reset should always restore operation. 

> If this 
> isn't happening should be able to diagnose what's going with the 
> existing facilities (e.g. athdebug msgs). 

nice! I will rebuild the nanobsd img's to use
/usr/src/tools/tools/ath/*

> Understand however that building a product ap is nontrivial and the FreeBSD ath driver can 
> easily be optimized better for this purpose.

I am not building a product, I am using FreeBSD wifi / networking env
and as show case of working Opensource Software. IHMO the benchmarking
could help harden to wlan drivers and FreeBSD based accesspoints. 

I expect to double the clients in the benchmark in the coming weeks.
Then I will do more testing. Please let know how I can support to create
usable (debug) output.

thanks for your reply,
Marten


> 
>     Sam
> 
-- 
http://martenvijn.nl                 Marten Vijn 
http://martenvijn.nl/trac/wiki/soas  Sugar on a Stick
http://bsd.wifisoft.org/nek/         The Network Event Kit
http://har2009.org                   13th-16th August 
http://opencommunitycamp.org         26th Jul - 2nd August




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1247251131.5235.147.camel>