On 28 Apr 2005 17:40:19 GMT, Bert Hyman <(E-Mail Removed)> wrote:
>Just recently, I've started seeing all sorts of errors at the TCP/IP
>level.
All sorts? Could you be a bit more specific? Different types of
errors have rather specific causes. Run in an MSDOS window:
netstat -es | more
and see if there are any errors that are a high percentage of packets
sent or received. It's the TCP and UDP statistics at the bottom.
Anything less than about 0.5% is considered excellent.
>Both Ethereal (a Windows packet trace utility) and a number of
>Websites running the Web100 network diagnostic tool
>(http://www.web100.org) show numerous
How numerous? As a percentage of traffic passed please. Web100
tweaks the hell out of the TCP/IP timing. It allegedly dynamically
optimizes a server for traffic to given PC. It may NOT do a decent
job of optimizing two or more connections to the same machine. Also,
running the timing to the bitter edge of collision and overrun is not
my idea of reliable operation. I guess anything is justified in the
search for more performance, but methinks sacrificing reliability is
not a great idea. Web100 settings may be stable on a wired
connection, but wireless conditions tend to change. The question is
how good is the dynamic optimization.
>instances of "packet out of
>order", "duplicate ACK" and "retransmission request", but only on the
>wireless link. My desktop machine, which is plugged directly into the
>single ethernet port on the GT701 shows no such errors.
Well, let's take them one at a time. It's kinda difficult without
real numbers but you can fill in the guesswork.
"Packet Otto Order" means that a series of packets arrived with one
missing. The missing packet was later re-transmitted and of course
arrive after earlier packets with earlier sequence numbers. TCP is
quite good at re-assembling out of order packets. This should not
affect thruput but is an indication that some packets are getting
lost.
"Duplicate ACK" is the same thing as above, where the TCP
acknowledgement packet was lost instead of the sent packet. The
effect is the same as the packet is sent twice and acknowledged twice.
Again, this is an indication of packet loss.
"Retransmission request" is the mechanism by which TCP retransmits
lost packets. In will generate a retransmission error for lost
packets in BOTH direction. Therefore, a single lost packet may cause
the entire (variable) window size of packets to be resent as one
error, but the number of packets to be resent may be up to 7 times
larger.
I would say you have a lost packets problem at the TCP layer. It's
very difficult to get data on lost packets at the MAC (hardware)
layer. Some "managed" access points have this feature. Others
display it on the status page. By the time it gets to the TCP layer,
where it's visible to netstat and other diagnostics, the MAC layer may
have initiated several retransmissions. Hard to tell from here.
Incidentally, there's no requirement that packets go via any
particular path between the computah and the access point. If you
cleverly have BOTH the wired and wireless connections active at the
same time, packets can go via either path. This can create some
rather bizarre looking statistics. One at a time until you figure out
if anything is broken.
My astute guess is that there's nothing wrong if the errors are a
sufficiently small percentage of the packets sent. There's also a
possibility that the errors are cause by co-channel interference,
microwave ovens, cordless phones, and such. Being close does not
prevent inter-symbol interference from these devices. However, my
best guess is that the web100.org software might be causing a problem.
>Usually when I'm using the wireless connection, and specifically when
>I was testing this problem, I'm within 8 feet of the AP and can look
>right at it, so signal strength is very good. The Actiontec's admin
>Web pages show no errors.
Well, it the access point shows no errors, then all the errors are at
the TCP layer and/or all on the client radio end. It would be fun to
try the same test using streaming audio or video which use UDP that
does not require an ACK and therefore should not show any ACK or
packet loss errors.
>I can replace either the GT701 or the 2200BG for $60, but before I
>start spending money, is there any reasonable way to determine what
>the actual problem is?
Sure. Drag your laptop to the local free wireless hot spot and run
the same test. If it has the same errors, then the problem is in the
laptop. If the problem magically goes away, it's in the access point.
Similarly, you can drag a borrowed laptop to your access point and
repeat the same tests.
>I don't have easy access to another WiFi network or I'd have tried
>that already :-)
What island do you live on?
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice
http://www.LearnByDestroying.com
#
(E-Mail Removed)
#
(E-Mail Removed) AE6KS
Similar Threads
Linear Mode
