DI 624 revC- severe wireless latency after consistent throughput

Discussion in 'Wireless Internet' started by lunyee, Sep 26, 2005.

  1. lunyee

    lunyee Guest


    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:

    (Firmware v2.70)
    WEP enabled

    (Driver version

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

    lunyee, Sep 26, 2005
    1. Advertisements

  2. lunyee

    speeder Guest

    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:
    even though it implements QoS only on a limited basis.
    speeder, Sep 26, 2005
    1. Advertisements

  3. 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:

    William P. N. Smith, Sep 27, 2005
  4. lunyee

    lunyee Guest

    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.
    lunyee, Sep 27, 2005
  5. lunyee

    lunyee Guest

    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. :/
    lunyee, Sep 27, 2005
  6. 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

    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

    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
    Jeff Liebermann, Sep 27, 2005
  7. lunyee

    lunyee Guest

    Could you describe how you got latency numbers?

    The latency measurements were from pinging the router from the wireless
    client (ping 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
    <1ms the entire way. Resetting the router was the only option to
    restart this process and the wireless client would then ping between
    1ms-3ms, which is what I would expect.
    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.
    lunyee, Sep 27, 2005
  8. 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:
    but 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
    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:
    If 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.


    # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    # 831.336.2558 voice Skype: JeffLiebermann
    # http://www.LearnByDestroying.com AE6KS
    # http://802.11junk.com
    # -cruz.ca.us
    Jeff Liebermann, Sep 27, 2005
  9. 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.

    # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    # 831.336.2558 voice Skype: JeffLiebermann
    # http://www.LearnByDestroying.com AE6KS
    # http://802.11junk.com
    # -cruz.ca.us
    Jeff Liebermann, Sep 28, 2005
  10. lunyee

    lunyee Guest

    What's unique about BitTorrent is that it opens up as many parallel
    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.
    lunyee, Sep 28, 2005
  11. lunyee

    speeder Guest

    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.
    speeder, Sep 28, 2005
  12. lunyee

    Craig Guest

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

    Craig, Sep 28, 2005
  13. lunyee

    lunyee Guest

    Besides higer latency numbers are you getting slower throughputs (LAN
    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!
    lunyee, Sep 29, 2005
  14. lunyee

    Craig Guest

    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, Sep 29, 2005
  15. Try running:
    netstat -s
    netstat -es
    after a session and see if there are any indications of TCP/UDP layer
    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.
    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
    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.
    Jeff Liebermann, Sep 29, 2005
  16. lunyee

    lunyee Guest

    Try running:
    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.
    lunyee, Sep 29, 2005
  17. lunyee

    speeder Guest

    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
    speeder, Sep 29, 2005
  18. 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:

    # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    # 831.336.2558 voice Skype: JeffLiebermann
    # http://www.LearnByDestroying.com AE6KS
    # http://802.11junk.com
    # -cruz.ca.us
    Jeff Liebermann, Sep 30, 2005
  19. lunyee

    John Navas Guest

    [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?
    John Navas, Oct 8, 2005
  20. lunyee

    John Navas Guest

    [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.
    John Navas, Oct 8, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.