5

This question involves network latency as opposed to bandwidth.

I have a small remote office with a single Cisco 881W Integrated Services Router (Ethernet WAN). The WAN modem is an AdTran NetVanta 8341. The WAN service is a 5Mb symmetrical /27 "Virtual Ethernet" on dedicated copper configured over 4-wire g.shdsl.

I connect to the home server about 200 mile away via Cisco VPN client version 5.0.07.0290 running on Windows 7 x64 clients. When I physically connect a client to the LAN side Ethernet of the router, I can ping my home server with a consistent return time of 27ms. That's pretty good. However, when the same client is on the 881W WiFi access point, the ping return time 135ms average, and varies widely, from about 80ms to about 250ms. Is this "normal"? If not, how should I troubleshoot this issue?

The extra latency has a pretty extreme effect on some applications, most notably X.11 forwarding apps running on remote workstations.

3
  • Wifi retransmits at the 802.11 layer when it detects dropped packets. Very often, you'll see huge wifi latencies coming from these dot11 retransmissions, although I can't say that's the only reason. If nobody else runs with this question, I'll endeavor to respond with specifics after work tonight. Oct 23, 2013 at 12:22
  • Please check/compare the ping times by connecting a device on wired side and wifi side of the AP (local traffic) Oct 23, 2013 at 22:07
  • @BhupinderMisra, Do you mean connect a device on the router WAN port? Oct 23, 2013 at 22:49

3 Answers 3

4

First of all you need to consider that the air is a shared media. In contrast to the switched wires where collisions are rare, in the air they are quite frequent and as a result retransmissions are part of the game. A lot of clients may compete on who will send a frame first to the access point and the losers have to retransmit. It gets worse when signal from one client is stronger than others and covers them, so that the access point cannot "hear" them. Finally neighbor wirelesses can also affect you if you are operating in nearby channels or you use turbo, super etc modes that utilize a wider band and are more easily affected by interferences.

I suggest that you scan the area for other wifi signals. Try to use a less congested channel. Avoid the wide bandwidth modes, even the 11g is utilizing a wide range of frequencies to achieve the 54Mbps. If you have a lot of local wireless clients consider expanding the access points to share the load. And just to be safe, make sure no other client is not utilizing any heavy downloading software, like torrents.

3
  • OK, I'll look into these suggestions. I know that the clients to run 3x3 antennas at maximum WiFi bandwidth, that is 2.4 GHz 20 Mbit/s, 802.11n mode. Oct 23, 2013 at 17:29
  • 1
    @ThomasMcLeod Using 2.4GHz these day is risky, unless you're confident that the channels are free. Try disabling 40mhz channel width, as it's known to cause more problems than needed when you're in buildings with a lot of interfering 2.4ghz networks.
    – pauska
    Oct 24, 2013 at 7:28
  • @pauska, recent images IOS on the 881w do not allow 40MHz, so they're disabled. There is no congestion on 2.4 GHz in our area, it's low density residential. Oct 24, 2013 at 13:03
4

This could be entirely normal depending on the environment (number of users, amount of traffic, etc).

However there are definitely issues that can create this problem as well. To start with I would ensure that you have a newer image on the wireless device. Haven't worked on the 880 ISR's myself, but I believe the AP runs a separate image then the router itself (someone with experience, please correct me if I am wrong). You should find details on the Cisco web site.

Second, I would make sure that the wireless drivers are upgraded on the client devices as older drivers can be a source of significant performance problems. In Windows, this is unfortunately not always a simple process. With some wireless manufacturers, there are updates through Windows update, some provide driver updates on their website and some you may need to get the drivers from the chipset manufacturers website.

From there, try to make sure you are on an uncongested channel. You will want to use channels 1, 6 or 11 (or 1, 7 and 13 if you are in a country that allows the use of channel 13). If you don't have the tools to measure channel utilization, you may have to experiment for the best channel (the AP should be able to provide you with channel utilization on it's current channel).

A simple tool, such as inSSIDer will give you an idea of how many other networks will be overlapping with your current channel, however this isn't a complete picture as it doesn't indicate if any of those networks are busy (i.e. causing high channel utilization). Being on a channel with a very busy network will generally be worse than being on a channel with multiple non-busy networks, but often this will get you headed in the right direction. Also keep in mind that even with the right tools, you are only getting a picture of "this moment" and "this specific location" view of things.

Beyond that, there are many things you can still do to improve performance, but I don't want to turn this into a novel. For instance, you can look at dropping lower data rates (1, 2, 5.5 to start), disabling 802.11b, turning off protection mechanisms (or turning them on depending on the situation), reducing the number of SSIDs (if you have more than one), using QoS, and many more wireless tweaks. Many of these are dependent on your environment and needs though, and there is nowhere near enough information in the question to know which may be best.

4
  • The 881w AP does run a separate IOS image, and the unit is only six months old. I'll check channel usage again, but we're in a low-mid density residential area, and we typically have only one or two other SSIDs pinging the area. Oct 24, 2013 at 13:06
  • @ThomasMcLeod, unless you are inferring that you upgraded the image when you got the device, then be aware that the images on new devices are often out of date (and sometimes even deferred).
    – YLearn
    Oct 24, 2013 at 17:41
  • So I guess I need to buy one of those annoying Cisco service contracts. Oct 24, 2013 at 17:47
  • @ThomasMcLeod, at least check to see how old the current image may be...you should be able to do that without a service contract. If you decide to upgrade, you may need to get a service contract, but check the paper work that came with the device. Depending on the warranty, you may be entitled (generally or under certain conditions) to software upgrades as well.
    – YLearn
    Oct 25, 2013 at 18:38
4

These kind of latencies are typically related to power management.

What happens is that your client wifi card sleeps all the time and only wakes up typically every 204,8 ms (DTIM interval × Beacon interval).

While the station's wifi card sleeps, the AP keeps the frames that it should send to the station. Every 2 beacon, (typical value for DTIM interval), the AP includes TIM bits in its beacons that indicates if it has pending frames, and if it has, for which stations.

Power saving STAs typically wakes up only to receive this DTIM beacon, and go back to sleep if there is no frame for them, else they stay awake to request the pending frames, then get back to sleep again.

Typical test for this is to request the client to sends frames regularly (e.g. 50ms), since Wi-Fi drivers typically wakes up the wifi card immediately when there are pending frames to be sent. If ping times goes down, then power management is responsible for this.

Easiest solution is to disable Wi-Fi power management on the station. Many OS enables it by default, even for desktops computers and laptops connected to AC power.

1
  • Now this is something I hadn't thought about. Yes, power management is ON for the Intel Link 5300 cards. Oct 24, 2013 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.