Forum

Environment:

Vehicle Assembly Plant with approximately 13 access points in client use area with layout geared to co-locate APs for higher throughput. Antenna selection is poor (in my opinion) for a co-located infrastructure. Patch antennas are primarily used with some yagi antennas. There are multiple competing networks serving different uses with different SSIDs. Multiple vendors in-use (Cisco, Telxon) with multiple OS's (Linux, Windows CE, others). All clients appear to be 802.11b devices but there are some 802.11g APs being turned on day by day. No one group has full control of the WLAN. Tons of metal, concrete, and changes to the environment every day.

Application:

Complex real-time processing system which begins with two main servers and then 10+ "runtime" servers that have redundacy. Systems are brand new, fast, 3GHz machines. I believe 1GB of memory. Handheld Windows CE devices process input from the floor in real-time with a limited cycle time along with 1-2 additional clients at the same time. (All 2-3 clients are a set working together, all communicating in infrastructure mode). 1 of the clients in the set is utilizing embedded Linux with Cisco 350 radio card linux drivers. All clients mentioned use Cisco 350 radio cards.

Issue:

Majority of traffic is moving at 2Mbps/5.5Mbps and devices are not roaming well without experiencing unacceptable latency or lock-ups. There may be issues with the Linux driver (for those devices utilizing them). There are a high number of errors at times as well as broadcasts. Airopeek NX is reporting a multitude of issues....

Questions:

If using a WLAN with approximately 70+ clients all doing real-time transactions, what type of settings would be recommended with regards to fragmentation, etc. I do understand that our effective throughput is not 11Mbps and that it has taken a further hit with WEP turned on. Also, can anyone shed light on this Warning on a Cisco 1200 Series AP (12.02T1):

Station [IProbe]<mac address> Associated with Encryption, then attempted to send an Unencrypted packet to [AP Name]<mac address> (length 83)

After checking at least one AP, the fragmentation threshold is set at the maximum 2338 for a range of (256 - 2338). Access points are also utilizing only one antenna not taking advantage of diversity.

I've noticed that some of the consumer AP's coming out lately only have one antenna versus two. This seems counterproductive towards dealing with multipath - is there a valid reasoning to utilize only 1 antenna?

If not mentioned before, I have observed that the their is significant channel overlap coming particularly from a competing network, with different SSID, which utilizes channels 3 and 9 primarily.

Infrastructure Update: All of the AP's now have an added 2nd antenna to allow for diversity on the Cisco 1200 APs. Although 2 formal site-surveys have been done, they were not very good one. I believe at one point there was a site survey template available on this site - does anyone still have it? One AP's antenna's were changed to an Omni from a patch to provide better coverage.

What I'm particularly focusing on now are the clients that are using a Cisco Linux driver for 350 radio cards. I still continue to see APs reporting Station srchost Associated with Encryption, then attempted to send an Unencryted packet to
desthost (length pktLen)
srchost: MAC address of source host
desthost: MAC address of destination host
pktLen: Length of the 802.11 packet received, in octets I'm logging these messages and they appear to be coming primarily from the linux driver clients.

Throughput Analysis: The throughput that was seen prior to the infrastructure being changed above sucked big time. When analyzing the conversations between clients the max throughput seen was under 5kbps. The good majority of the packets sent are VERY small, under 64K (50%) and under 128K (40%). I believe the fragmentation thresholds on the APs are set to their max value.

Topology Background: Client/Server Architecture with approximately 15 Cisco APs going back to 2 switches then up another switch configured to contain everything into a VLAN. Th servers go through another switch in the same VLAN up to same main switch where the VLAN is configured so they do reside on the same network.

All Cisco 1200 APs have now been updated to the IOS versioning of software in order to allow for implementation of better Cisco management software (long term). A neighboring 802.11 FHSS system is being revised to reduce/eliminate interference. A legacy system internal to the plant utlizing an Intermec AP on channel 3 has been migrated into the new WLAN and the AP removed. On-going full site-survey's are being done utlizing Eckohau software. Existing APs antenna alignments adjusted for better coverage along with more sensible power levels to reduce channel overlap.

The average delay I'm seeing in the RF conversations is still relatively slow in my opinion and I'm concerned that one of the proprietary RF clients is too slow resulting in an "TCP Stuck Window" problem. Now I'm investigating changes to the TCP Window settings and buffer settings at the application and OS levels in order to optimize performance for the system.