DI 624 revC- severe wireless latency after consistent throughput
DI 624 revC- severe wireless latency after consistent throughput. Discuss DI 624 revC- severe wireless latency after consistent throughput, on Wireless Forums.
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?
>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
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
lunyee@gmail.com wrote:
>I've noticed though that after about 6-7
>hours of consistent use, the DLink router starts becoming sluggish over
>the wireless connection.
>I did read up on problems where the router would reboot when using
>BitTorrent.
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
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. :/
>The latency I measured was from the wireless client to the router.
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?
>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.
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
> Could you describe how you got latency numbers?
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
<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.
> 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.
> Any chance that Windoze Update, NAV update, MS Anti-Spyware, etc were
> doing updates when you were testing after 6-7 hours?
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.
> However, if reproducing the problem requires 6 hours of
> traffic, it's going to be difficult to identify.
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.
>> Could you describe how you got latency numbers?
>
>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
><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.
1-3msec is normal. If it creeps up to 20-70msec, then there's
something seriously wrong. Unfortunately, I don't know exactly what.
>> 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.
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.
>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.
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.
>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.
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.
>All of the auto update features are disabled on my computer.
So much for that idea.
>> However, if reproducing the problem requires 6 hours of
>> traffic, it's going to be difficult to identify.
>Actually I can speed up the process by running a P2P app. Typically
>BitTorrent can get this reproduced in under an hour.
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: http://groups.yahoo.com/group/the_gdf/message/21143
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.
>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.
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.
>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.
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: http://vlaurie.com/computers2/Articles/dnscache.htm
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
On Tue, 27 Sep 2005 22:38:24 GMT, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote:
>>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.
>
>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:
> http://vlaurie.com/computers2/Articles/dnscache.htm
>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.
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
>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:
> http://groups.yahoo.com/group/the_gdf/message/21143
>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.
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.
>but sitting at Starbucks for 6-7 hours playing games may not be a great
>idea.
I disagree. :P
>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:
> http://vlaurie.com/computers2/Articles/dnscache.htm
>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.
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.
>> Could you describe how you got latency numbers?
>
>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
><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.
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.
>I have tried different brands as well. Linksys is one. Those had its
>own assortment of problems (packet loss).
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
"speeder" wrote...
> On 27 Sep 2005 14:20:33 -0700, lunyee@gmail.com wrote:
>
> 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.
The DI-624 with latest firmware also supports WPA2 with AES.
Re: DI 624 revC- severe wireless latency after consistent throughput
>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.
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.
>Have you tried switching channels? Download Netstumbler and verify
>what other networks are flocking around yours. Then choose a channel
>farthest from anyone.
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.
>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.
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.
>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.
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).
>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.
Nope. There is only a 5.4GHz phone in the living room (12ft away).
>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.
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.
>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.
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!
Re: DI 624 revC- severe wireless latency after consistent throughput
<lunyee@gmail.com> wrote...
> 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 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.
>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.
Try running:
netstat -s
netstat -es
after a session and see if there are any indications of TCP/UDP layer
errors.
>Does Netstumbler get
>them all? If so, that'll be quite useful.
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. http://new.remote-exploit.org/index.php/Auditor_main
>I was
>just hoping for some better stability, performance and security.
>Unfortunately I can't seem to find it.
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?
>The router and wireless client are about 20ft away. Maybe less. There
>is 1 wall between the router and client.
That should be no problem if the wall does not have any metal (foil
backed insulation) inside.
>I will try out that Netstumbler program and
>see if there are any hidden neighboring networks (hopefully it can
>detect it).
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.
>Nope. There is only a 5.4GHz phone in the living room (12ft away).
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?
>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.
Sounds more like a microwave oven. The duration is the key. 3-10
minutes around meal times usually means a microwave oven.
>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.
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
>Try running:
> netstat -s
> netstat -es
>after a session and see if there are any indications of TCP/UDP layer
>errors.
I'll try that when I get home.
>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.
So much for that idea. :/
>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.
> http://new.remote-exploit.org/index.php/Auditor_main
Cool. I'll try that out as well.
>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?
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.
>That should be no problem if the wall does not have any metal (foil
>backed insulation) inside.
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.
>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?
Oops. It's a 5.8GHz phone: Panasonic KX-TG5451S.
>Sounds more like a microwave oven. The duration is the key. 3-10
>minutes around meal times usually means a microwave oven.
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.
>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.
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).
>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.
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.
>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.
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.
>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.
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
On Thu, 29 Sep 2005 08:49:20 -0700, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote:
>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.
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
On Thu, 29 Sep 2005 19:52:55 -0300, speeder <no.spam@invalid.com>
wrote:
>On Thu, 29 Sep 2005 08:49:20 -0700, Jeff Liebermann
><jeffl@comix.santa-cruz.ca.us> wrote:
>
>>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.
>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.
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.
Re: DI 624 revC- severe wireless latency after consistent throughput
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <1128023449.992563.243670@z14g2000cwz.googlegroups .com> on 29 Sep 2005
12:50:50 -0700, lunyee@gmail.com wrote:
>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.
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.
>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).
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.
>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.
FWIW, my DI-524 Ver C1 is quite happy in a horizontal position.
>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.
Are you seeing any signficant lag when accessing the router web interface?
--
Best regards, HELP FOR CINGULAR GSM & SONY ERICSSON PHONES:
John Navas <http://navasgrp.home.att.net/#Cingular>
Re: DI 624 revC- severe wireless latency after consistent throughput
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <1127967047.100000.260240@f14g2000cwb.googlegroups .com> on 28 Sep 2005
21:10:47 -0700, lunyee@gmail.com wrote:
>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.
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.
>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. ...
Underestandable, but it's still an important troubleshooting step.
>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.
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.
--
Best regards, HELP FOR CINGULAR GSM & SONY ERICSSON PHONES:
John Navas <http://navasgrp.home.att.net/#Cingular>
Re: DI 624 revC- severe wireless latency after consistent throughput
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <1127929610.368553.21260@z14g2000cwz.googlegroups. com> on 28 Sep 2005
10:46:50 -0700, lunyee@gmail.com wrote:
>>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.
Mine (DI-624 Ver C1 with 2.70 firmware) is currently running with well over
100 open connections.
>>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:
>> http://groups.yahoo.com/group/the_gdf/message/21143
>>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.
>
>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.
Azureus is an excellent BitTorrent client where it's easy to configure the
number of connections, both per torrent, and for all torrents.
--
Best regards, HELP FOR CINGULAR GSM & SONY ERICSSON PHONES:
John Navas <http://navasgrp.home.att.net/#Cingular>
Re: DI 624 revC- severe wireless latency after consistent throughput
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <a1kjj1tbmd2atogpp0e2kca31065biepo2@4ax.com> on Tue, 27 Sep 2005 23:11:35
GMT, Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>On Tue, 27 Sep 2005 22:38:24 GMT, Jeff Liebermann
><jeffl@comix.santa-cruz.ca.us> wrote:
>
>>>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.
>>
>>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:
>> http://vlaurie.com/computers2/Articles/dnscache.htm
>>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.
>
>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, ...
Not unless you specify the -a option.
--
Best regards, HELP FOR CINGULAR GSM & SONY ERICSSON PHONES:
John Navas <http://navasgrp.home.att.net/#Cingular>
DI 624 revC- severe wireless latency after consistent throughput 
Linear Mode
