Dan, The reason that PSP clients "grind to a halt" with long Beacon intervals can be sussed out with a bit of effort. Think of what happens with a TCP connection. The sender shoots out a bunch of packets, to fill the window negotiated at the setup of the connection. Then the sender has to sit and wait for TCP ACKs to return from the receiver, before it can send a single byte more.
Put an AP between the sender and the PSP client that is the receiver and that window-full of bytes sits in the AP until the PSP client wakes up and pulls the packets out, one packet at a time. Then the client's protocol stack processes the packets and sends back the TCP ACKs. Typically, the client sees nothing more to send and goes back to sleep until the next time the AP tells it there are packets buffered for it (by setting the bit in the TIM enumerated by the client's association ID (AID) in the next Beacon). This is the best case. If the sender is a bit late getting its packets out and misses the transmission of the Beacon, those packets will sit fir a full Beacon interval, waiting to be announced in the following Beacon. So, the soonest the client can receive another packet from the sender is right after the next Beacon. With a typical window size of 8 kbytes, here are some maximum TCP throughputs for various Beacon intervals. Beacon interval Throughput 100 kus 80 kbytes/sec (10 window-fulls per second) 200 kus 40 kbytes/sec 500 kus 16 kbytes/sec 1000 kus 8 kbytes/sec (can anyone say 56k modem ;^) I hope this has been helpful. -Bob Bob O'Hara Black Storm Networks 110 Nortech Parkway San Jose, CA 95134-2307 Phone: +1 408 941 0500 Mobile: +1 408 218 4025 Fax: +1 810 277 4718 email: [EMAIL PROTECTED] -----Original Message----- From: Dan Lanciani [mailto:ddl-bawug@;danlan.com] Sent: Sunday, October 27, 2002 12:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [BAWUG] FreeBSD box as Acess Point without SSID broadcast |While Russell is correct, there are reasons to not beacon SSID. One possibly good reason to disable broadcast SSID is simply to avoid confusing clients that you do not want to connect (and that have no desire to connect to you). My clients started acting odd when a neighboring motel set up some public access points in spite of the fact that my clients were set up to use only my own SSID. It turned out that they were getting hung up timing out on association attempts with these public access points (and counting up SSID mismatches) when they should have been talking to my access point. Clearly it's pretty stupid of the firmware to keep trying the wrong SSID on an access point that is willing to tell its SSID, but that's what they did. The resulting delay caused the client in my car to fail to associate with my own access point before I turned into the driveway, confusing my home automation system. I ended up restricting the clients to my specific access points which is kind of a pain since MAC addresses have to be everywhere... |That is, |to keep junk out of the air. I'm not sure it accomplishes this one. As far as I can tell, most access points that allow you to disable "broadcast SSID" mean that they will not accept the null (= broadcast) SSID from clients in probes. The setting does not change the rate of packets generated at idle. Having just ordered one of the sniffer boxes advertised here recently, maybe I'll be able to see for certain soon. :) (For some access points--like the ones mentioned above-- allowing broadcast SSID seems to make them accept any SSID rather than just the null and configured ones. At least in some contexts. Very confusing...) |In a congested environment (like here in |Cambridge) this can make a difference. At the least, set your beacon |interval to something reasonable (2 per second is good). I've experimented with long beacon intervals and they kill PSP clients. I don't quite understand what is going on yet, but the clients just sort of grind to a halt if the beacon interval is significantly longer than the default 100Kusec on my Aironet access point. |I think a patch to allow disabling the beacon would be a good idea. How do you convince the clients that the lack of beacons doesn't indicate that the access point is dead? The active beacon seems to be on of those unfortunate things which wasn't absolutely necessary for DSSS in the first place (active probes are fine, no?) but which has come to be depended on for a variety of functionality. Some of that could be changed, but PSP's dependence is pretty deep... Dan Lanciani ddl@danlan.*com -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
