DI 624 revC- severe wireless latency after consistent throughput

Hi,

I've purchased a DI 624 revC while searching for a replacement router for my Netgear WGR614 v1. I've noticed though that after about 6-7 hours of consistent use, the DLink router starts becoming sluggish over the wireless connection. The wireless client would initially see pings fluctuate between 20-70ms. And after about 10minutes after that it would hit 200ms-400ms consistently. This tended to happen more quickly when there was consistent throughput on the router (eg. online games, BitTorrent, other P2P apps). Actually more specifically BitTorrent and P2P apps sped up the process more quickly causing this problem to surface in a matter of an hour or so.

I did read up on problems where the router would reboot when using BitTorrent. I haven't encountered that problem however. I'm using the latest firmware which claims to have fixed the problem. My setup:

DI-624 (Firmware v2.70) WEP enabled

WMP54G (Driver version 3.0.3.0)

Other than this problem and some WPA problems, the router is blazing fast. Does anyone have any ideas what might be causing this?

Thanks. K

Reply to
lunyee
Loading thread data ...

The latency I measured was from the wireless client to the router. When we measured this latency the only program that was running was World of Warcraft. I can guarantee that World of Warcraft did not saturate an

802.11g connection. That is a problem. We're very careful of watching our upstream. I'm aware of latency introduced by this and I'm fairly certain that this isn't it.

Thanks though.

Reply to
lunyee

Interesting. Thanks. I may give that a go. No other router seems to be working. Unfortunately my aged WGR614v1 is running better than the rest. It just lacks some of the newer security features. :/

Reply to
lunyee

I had every low-end router I tried fall over with heavy use on Verizon FIOS (30M/2M) with the exception of the supplied DI-624, which is running a specific firmware (2.43DDM) which apparently avoids this problem. You used to be able to download this from the Verizon FIOS support site, but now it requires IE6, ActiveX controls, and all sorts of ugly stuff.

Oh, wait, someone found a more direct pointer:

formatting link

Reply to
William P. N. Smith

Latency going from 20-70ms to 200-400ms under heavy use is NOT a problem, it's just how things are on a router that does not employ QoS. Specifically, you must ensure that your upstream is not saturated to the point where it is lagging ACK responses. The combined internet usage of all your applications on all the computers hooked to the router should not exceed ~75% of your upstream at any time. This is kind of hard to do manually if you are consuming bandwidth agressively on more than one comp.

A better replacement to your router might have been this one:

formatting link
though it implements QoS only on a limited basis.

Reply to
speeder

That can't be correct. Wireless latency between the client and the router should be about 1-3msec. At a 54Mbit/sec connection, ping usually shows zero latency when I ping the router. You were getting

20-70msec which is what I would expect if you were pinging something on the internet over a partially congested broadband connection. Could you describe how you got latency numbers?

Playing games for 6 or 7 hours? Slacker. I wished I had time for that.

How much of your upstream are you normally using? Most of the games I've seen send data in bursts during which they saturate the outgoing bandwidth. You don't see that because the traffic statistics are averages. However, if you tried to ping something on the internet while there bursty traffic, you would see very wide variations in ping times.

Any chance that Windoze Update, NAV update, MS Anti-Spyware, etc were doing updates when you were testing after 6-7 hours?

My guess(tm) is that you may have found a bug or problem in the DI-624. However, if reproducing the problem requires 6 hours of traffic, it's going to be difficult to identify. If possible, borrow a different brand or model router and try it instead. If it also does the same thing, then there's something wrong with how your testing, with your assumptions, or with your client computers. That doesn't solve the problem, but at least it narrows down the potential culprits.

Reply to
Jeff Liebermann

The latency measurements were from pinging the router from the wireless client (ping 192.168.0.1). Pretty simple test. Of course pinging external sites had higher latency but the brunt of the latency was between the router and the wireless client. My wired client was pinging How much of your upstream are you normally using?

I have a 800Kbit upstream on my DSL modem. On average we're only using about 20KB/s up. I like to keep a good buffer zone as I tend to host a website on that connection as well. The reason why I'm quite confident that it's not us choking the upstream is that if the upstream was choked, my wired client would have the same problem. Moreover, the wireless client wouldn't be experiencing lag to the router alone.

54Mbit is quite a bit larger than an 800Kbit connection. It would take a lot to saturate that.

For the more intensive games like FPS games, the burst data rate typically won't ever exceed 10KB/s per client unless the server is configured to accept higher data rates. I've run a UT server before and typical usage is 6-8KB/s for a smooth gameplay feel. Of course you can ramp this up if you'd like but it's harder to notice the differences. In any case, I doubt the games we're playing are eating up that much bandwidth. I played the same game with two wired clients and the bandwidth did not saturate.

All of the auto update features are disabled on my computer. I hate being interrupted by those features. Although I should check with my roommate's computer. I'm pretty sure he does the same, but I'll verify. I still can't quite come up with a reason as to why that would cause high latency between the wireless client and router though. Specifically if the DSL modem is the bandwidth chokepoint and not the wireless connection.

Actually I can speed up the process by running a P2P app. Typically BitTorrent can get this reproduced in under an hour. I've seen many posts about people's DI624 routers being reset after consistent throughput, but I haven't seen that actually happen to me. It's just the wireless client that gets this insane latency to the router that kills me. I've tried 2 DI624 routers from different stores and tried nearly all permutations of settings (I really wanted to get it working :P It's so damned fast.).

I have tried different brands as well. Linksys is one. Those had its own assortment of problems (packet loss). Currently I'm back to my WGR614v1 Netgear router which has been surprisingly the most reliable wireless G router I've used. It has none of these problems. Well it does get the latency problem but only after 2months of use. I'm pretty sure it's something to do with DNS caching on the router as enabling the DNS relay on the router speeds up that process as well. But I can specify the DNS servers directly through the connection and I don't have to bother resetting the router for a couple months.

Reply to
lunyee

1-3msec is normal. If it creeps up to 20-70msec, then there's something seriously wrong. Unfortunately, I don't know exactly what.

Bits and bytes? b=bits, B=Bytes. 20KB/sec is 160Kbits/sec. However, that's sufficient headroom out of 800Kbit/sec to not impact the latency very much. That's not the problem.

54Mbits/sec is the wireless connection speed, not the thruput. At best, you'll get about 25Mbits/sec thruput with a 54Mbit/sec connection. That's still way more than 800Kbits/sec, so again, that's not the problem.

Well, the traffic is not going through the router section of the DI-624 when you're playing just locally. If a local wireless client to client game works as expected, then it's not the wireless part of the puzzle. That leaves the DI-624 router section.

So much for that idea.

What's unique about BitTorrent is that it opens up as many parallel streams as it can to move its traffic. My guess(tm) is that the DI-624 can only handle about 32 streams before it complains. BitTorrent might be trying to open more. If you're running it "unchoked", it can easily open more, especially on a high bandwidth connection. There are some clues here:

formatting link
I won't pretent to understand all the BitTorrent unique buzzwords. If there's a setting to reduce the number streams, connections, users, or such, you might want to try it. My guess(tm) is that your game might also be trying to do the same thing.

Have you tried a different client computah or wireless device? If juggling all those wireless routers doesn't yield an improvement, then it's possible that the problem is being caused by the client, not the router. I guess you could test the client with a different setup, but sitting at Starbucks for 6-7 hours playing games may not be a great idea.

Well, that's really odd because DNS timeouts are usually around 30-45 seconds and not in milliseconds. Windoze clients also cache DNS lookups for about 24 hours for a successful lookup and 5 minutes for a failed lookup:

formatting link
that has an effect, I'm lost. I don't have a clue why the DNS cache would affect ping latency, especially since you're pinging by IP address which does not require a DNS lookup.

Weird...

Reply to
Jeff Liebermann

Ooops. I forgot that some versions of ping *DO* run a DNS lookup for every last lousy ping packet. For ping by IP address, it does a reverse DNS lookup. I know SCO Unix OSR5 and the BIND derived utilities do that. If the DNS lookup from the cache in the DI-624 is delayed, so will the ping results. If the system is really screwed and DNS has to go to the root domain servers to walk down the tree to the authoritative servers each time, then it would easily take the

70msecs you've observed. However, methinks that's unlikely.

I'm not sure if Windoze ping also does a DNS/RDNS lookup, but I can sniff the traffic and see for my myself, later. So, maybe there really is a connection between DNS and slothish pings. However, I doubt that would affect game traffic that does not require more than an ocassional DNS lookup.

Reply to
Jeff Liebermann

That might be it. It's worth a shot at this point. I'll check to see if I can control the number of streams. One thing that is odd though is that once the router acts up, it does so for a long time regardless of activity between the wireless client and router. After a day or so (I didn't time it exactly, but it eventually went down after we just stopped using the connection), it went back to normal until another game or P2P client was run. This time though it would immediately jump back to high latency instead of waiting 1 hr for BitTorrent or 6-7hrs for games.

I disagree. :P

I wouldn't be surprised if it was just a firmware problem. It was Netgear's first attempt at a wireless G router. They've switched chips so many times under this product. I'm tempted to try out a later version of the same router as it does seem to be the most stable thus far. I just want to clarify one thing. The DNS problem is a separate issue with my Netgear WGR614v1 router. Not the DI 624.

Essentially (as you've seen my other post as well), I've tried out the following routers:

DI 624 WRT54GS v2 WRT54GC v1 WGR614 v1

Each one has had its own problems:

DI 624 - wireless latency between wireless client and router after consistent throughput WRT54GS v2 - wireless packet loss WRT54GC v1 - severe wireless packet loss WGR614 v1 - wireless latency between wireless client and router after 2 months of use.

The WGR614 v1 (Netgear) has been the most reliable and it is the one that I believe suffers some problem with the DNS relay. I haven't had a whole lot of luck with wireless G routers thus far. We'll see if I can resolve this. It's a real bummer that everything I try has a problem in one form or another.

Thanks again for the help.

Reply to
lunyee

This is interesting and it points exclusively to your wireless setup.

Besides higer latency numbers are you getting slower throughputs (LAN or WAN side)? Packet losses? Latency could only be the tip of the iceberg. The suggestions below assume this.

Have you tried switching channels? Download Netstumbler and verify what other networks are flocking around yours. Then choose a channel farthest from anyone.

Are you using WPA, WEP or none? WPA implementation is not the most robust in these routers so for testing purposes you might want to try different security setups. If it gets better you know who the culprit is and you could try updating your wireless client drivers. Update them anyways and see if it does any good.

How close are you to the DI-624? What walls do you have between you and the client? I believe Netstumbler can detect signal intensity and signal to noise ratio (have to confirm this). For testing purposes try to put the client next to the DI-624.

Are there possible interference sources close by? Cordless phones, bluetooth devices, microwave ovens? Maybe airports, weather stations or military bases? The S radar band is between 2-4 GHz and is used by terminal air traffic control, long range weather and marine radar; the DI-624 uses 2.4 GHz.

Is there a pattern in the daytime when performance starts to decrease? There is a little app called PingPlotter that will ping continuously to a source and plot it in a chart. This could point to your neighbors or yourself turning something on at a specific time of day.

In context this also suggests that you are facing a location specific problem. You could try taking your setup to a parents or friend's house and see if the problem persists.

Reply to
speeder

The DI-624 with latest firmware also supports WPA2 with AES.

Craig

Reply to
Craig

For the wireless client, we have slower throughput on the LAN side and obviously WAN as well as a result of the LAN issues. No packet losses. It's all going through, just more slowly.

Yep. I've tried channels all over. So far I've only been able to track neighboring networks with SSID broadcast enabled. Does Netstumbler get them all? If so, that'll be quite useful. Using the DI624's auto select, it chose the same channel that I would have given the listing of neighboring SSIDs (channels 6-11). I selected channel 1. I changed it around many times to no avail. 3, 4, 8, 11. I'll give Netstumbler a try though. Thanks.

I had WEP enabled for all my tests. WPA and WPA2 didn't work for me. Even under the new 2.70 firmware. That said, I didn't put a whole lot of effort into trying to get those working as this issue was the more serious one. I didn't try out the unsecured network, mostly because if that's the problem, I'm not going to use that router in any case. I have my Netgear router that is more stable with security enabled. I was just hoping for some better stability, performance and security. Unfortunately I can't seem to find it.

The router and wireless client are about 20ft away. Maybe less. There is 1 wall between the router and client. I live in a condo (1300sqft) so distance won't be huge. I will try out that Netstumbler program and see if there are any hidden neighboring networks (hopefully it can detect it).

Nope. There is only a 5.4GHz phone in the living room (12ft away).

It happens soon after we initiate a P2P connection. Any time of day really. Obviously it happens more frequently during peak hours since those are the times when we're using the connection the most as well. But I've had it crop up during offpeak hours as well. 4am, 10am, etc.

Maybe. But my hunch is on something else. Specifically the fact that DI624 does not handle multiple simultaneous connections very well. My Netgear runs fine for 2 months before it needs a reset. The Linksys was having packet loss but latency was low. DI624 is having high latency only when there is steady activity.

Netstumbler looks promising. I'll give that a go and we'll see what we find out. Thanks!

Reply to
lunyee

Try running: netstat -s netstat -es after a session and see if there are any indications of TCP/UDP layer errors.

No. Netstumbler is an active probe AP detector. It sends a probe request and listens for the AP to respond. If SSID broadcast is off, it will not detect anything.

What you need is a passive sniffer such as Kismet and Wellenreiter (for Linux). Try downloading a "Live CD" for Linux with Kismet. No need to install Linux on your hard disk. I use "Security Auditor" based on Knoppix which is literally filled with network tools.

formatting link

I previously mumbled something about the search seems to be centered around a single client radio. What radio are you using for a client? It takes two to tango and with the large number of allegedly defective access points, methinks that there may be a problem on the client side. Are you doing all these tests with just one client wireless adapter?

That should be no problem if the wall does not have any metal (foil backed insulation) inside.

Good idea, but don't assume that Netstumber will see every network in the neighborhood. There are also plenty of non-802.11 sources of interference that Netstumbler could never see and that will require s spectrum analyzer to detect.

Don't assume that the 5.7GHz phones operate only on 5.7GHz. Many of these use 2.4GHz in one direction. That's because it's easier and cheaper to build a full duplex system with widely separated frequencies. Make and model?

Sounds more like a microwave oven. The duration is the key. 3-10 minutes around meal times usually means a microwave oven.

This is not going to be easy to isolate the cause.

Replacing the access point is an excellent way to isolating the alleged cause of the problem. However, if it's interference induced, it could easily be interfering at the client end as well as the access point. If resetting the access point, but not the client, "solves" the traffic problem, then it's most likely the access point as you suspect. However, if rebooting the client does the same thing, without resetting the access point, then it's not so definitive.

The next time it slows down to a crawl, try this test. Just walk away and do nothing for about 10-15 minutes. If it magically fixes itself, it's probably not some firmware anomaly but some form of interference. If it's still there after 10-15 minutes, then it's either a very persistent form of interference (another wireless network) or you're correct about the firmware bugs. This is not a definitive test, but it might offer a clue.

One more question. When it slows down, does it happen gradually or suddenly? Gradually is probably some kind of buffer or flow control issue in the access point induced by crappy firmware. Suddenly could easily be interference.

Also, if you're ambitious enough to try the Linux sniffer route, also try capturing some wireless traffic with Ethereal when the latency climbs high. Look for multiple retransmissions at the 802.11 layer. If that's happening, it's probably interference of some sorts.

Speaking of interference, I troubleshot one person's tale of woe down to a nearby cellular phone site. He was high enough that his house was directly in line with the antennas. The cellular system wasn't causing the problem, but the co-located WiMax experimental system was literally killing the thruput. I doubt this is the case with your system, but you might want to look around the neighborhood rooftops for new panel antennas.

Good luck.

Reply to
Jeff Liebermann

I'll try that when I get home.

So much for that idea. :/

Cool. I'll try that out as well.

Hmm. I'm not so sure I understand what you mean by what radio I'm using for a client. All these tests are going through one WMP54Gv4.0 Linksys wireless adapter. I did some searches for problems with that card and couldn't find much.

I have no idea what's inside the walls. I can check into that. All I know is that the wall between the router and the client is drywall. It's pretty hard to really describe it as a single wall though. Here's a rough attempt to draw out the layout: _____________ \\\\\\\\\\\\\\\\ _________| | | || o Client | | _________||_____________| _______| | | | __| \\\\ Kitchen | _______ | |_________| | _______| | | | o Router | | |__________|___________________|

The '' and '||' are thin doors. The '\\\\\\\\\\' is the front door. So yeah, maybe it's not really just one wall. If you draw a direct line, it's 4 walls. The image probably isn't going to turn out. hehe.

Oops. It's a 5.8GHz phone: Panasonic KX-TG5451S.

Microwave was never on when this happened. We're rarely using the connection when the microwave is going as it usually means it's dinner time. :) We've never timed duration. The duration is easily over an hour and by that point we're already too impatient and we reset the router. The one time I've seen the problem go away by stepping away from the router, I'm quite certain the router rebooted itself. As I had that pesky lil windows message saying that the connection disappeared and came back. This is consistent with several forum posts I've seen on the DI624 with 2.70 firmware.

Rebooting the client has never solved the problem. It was always the access point with the DI624 router. There were cases with the Netgear router (WGR614v1) however where resetting the client fixed it temporarily. But the problem would resurface shortly thereafter until I reset the router. At that point things would be fine for another 2 months (with Netgear router).

Yeah as I mentioned above, with the DI624 (going to keep this focused on that one router for clarity) the problem would persist for an hour by which point we got fed up and would reset the router. It could be persistent interference or firmware bugs. Not really sure. I did read a post who said he managed to fix things by setting the router vertically as it was quite warm to the touch. That fixed all the reboots. Perhaps I'll try that.

Well the problem manifests itself rather suddenly. But it takes time for us to notice the impact. The latency creeps from 1ms-3ms up to 20ms for about 5mins then shortly thereafter it would skyrocket to

200ms-400ms. Not sure if you'd call that gradual or sudden.

I'll give that a shot. We are at the same level as several surrounding rooftops. But they're mostly just convenience stores. I'm pretty sure I haven't seen anything new on the rooftops.

Thanks for all the suggestions. I'm close to giving up though. We'll see how things go.

Reply to
lunyee

I was only able to get WPA2 to work using AES encryption, not what my DLink card's default TKIP suggested. Try WPA2 with AES and see if it works.

Craig

Reply to
Craig

If that's true how come NetStumbler shows several APs near me that don't have an SSID? Am I reading this thing wrong or what? It certainly detects more than windows wireless zero configuration service.

Reply to
speeder

There are two ways that access points deal with SSID hiding. One is to broadcast the proper frame, but leave the SSID blank. The other is to not broadcast anything which also implies that these do not respond to probe requests. The one's that broadcast blank SSID's show up the way you describe.

Netstumbler does some odd things if you have an SSID set on your client to anything other than blank or "ANY". One of its bad habits is that sometimes (not always), if you set your client SSID to some value, it will return all access points that broadcast a blank SSID as if they were your clients SSID.

See comments by "Thorn" below:

formatting link

Reply to
Jeff Liebermann
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

FWIW, my DI-524 Ver C1 has never exhibited any such problems with firmware

2.70 -- it's rock solid even under long heavy loads with things like Azureus (BitTorrent client) running wide open.

Even though you've only seen this on on the WGR614v1, I think this points to a

*client* problem. I recommend testing with the different client, ideally a different card (e.g., WG511 v1) in a different computer.

FWIW, my DI-524 Ver C1 is quite happy in a horizontal position.

Are you seeing any signficant lag when accessing the router web interface?

Reply to
John Navas
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

That troubles me. WPA works fine here with 2.70 firmware on a DI-524 Ver C1. I'd be more comfortable if you eliminated all other problems. Try TKIP-PSK.

Underestandable, but it's still an important troubleshooting step.

I very much doubt that's the problem. My DI-524 Ver C1 with firmware 2.70 has no problem being pounded with a BitTorrent client (Azureas) for long periods of time. At the moment 'netstat' reports 125 open connections from this client, and ping latency to the router is a steady 1 ms.

Reply to
John Navas

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.