Date: Sat, 30 Dec 2006 19:50:29 -0200 From: JoaoBR <joao@matik.com.br> To: Sam Leffler <sam@errno.com> Cc: freebsd-stable@freebsd.org Subject: Re: ath0 timeout problem - again Message-ID: <200612301950.29821.joao@matik.com.br> In-Reply-To: <4596CE08.3090104@errno.com> References: <200612282002.11562.joao@matik.com.br> <4596CE08.3090104@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 30 December 2006 18:37, Sam Leffler wrote: > JoaoBR wrote: > > 572 cabq frames transmitted > > 11 cabq xmit overflowed beacon interval > > > > > > media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b <hostap> > > So one other thing came to mind. If your ap is operating in 11b and you > have many multicast frames q'd up for power save stations then they can > effectively saturate the network if they are being trasnmitted at a low > tx rate (which they would be). This can effectively DOS your wireless > network because the frames are burst immediately following the beacon. hum, let's see ... this is an ISP environment as unlikely the AP goes to sleep while rx/tx the client station either we block incoming traffic, we sell internet access so there will no access = to=20 the station which might match the case you brought up, the station request= =20 access to a site and get reply, when the station "sleeps" (if) then there i= s=20 no considerable tx to it > The driver limits the burst interval so it does not overflow into the > next beacon but it's allowed to fill all available time to the next > beacon frame (something I've considered changing for just the reason I > described). This has always been an issue. You might try rate limiting > these frames or just hack the driver to violate the spec and not buffer > them for tx after the beacon (to see if your problem goes away). ok I understand, this certainly is another point we have problems with but = we=20 did exactly what you mentioned.=20 The tx buffer on the AP, once getting used is never released even if never= =20 getting to fill it up to the configured limit - this I consider so far a=20 problem but not related to the problem we discuss but let me ask, certainly the same problem could come up when for instance = the=20 client has a bad signal (bad caox or connector, antena misplaced or local=20 interference) and the AP can not tx to this station in this exact moment wh= en=20 his signal drops right?=20 > > Further, if you have a machine with a crappy pci bus (such as !4801 > soekris boards) it's entirely possible that you are hoarding the bus > with these long transmits s.t. other problems are occurring. I do not > recommend building ap products out of such equipment. (No disrespect to > the 4501, et al they just had substandard pci bus operation.) > ok, like said before we use PCs and the MBs we use are pretty reliable beca= use=20 on POPs where this special case of traffic do not appear we have them up fo= r=20 months even with higher traffic as I mentioned before. thank you for your availability to help. =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612301950.29821.joao>