I didn’t want to clutter up the e-mail
with all of the different things that were done to eliminate the wireless
AP/wireless speed as the source of the problem. The AP is set to G only
and we used a sniffer to eliminate other sources of interference including 2.4
Ghz phones and the like. As mentioned below, we are connected at 54 Mbps
with a “good” signal. The APs we tested were plugged directly
into the circuit but it didn’t matter if they were plugged directly in or
if they were through a router. It also didn’t matter which
manufacturer of the AP/Router was used (Linksys – 3 types, Colubris/HP -2
Types, and Netgear -2 types) – the symptoms were still the same. We did setup a “mini-Speedtest”
server using the available software from SpeedTest.net – we did not see
the speed issues when going wireless or wired to that server – regardless
of what equipment was put in-between the wireless client and the server.
This is one of the things we did as we honed in on the fact that this issue was
only present at Comcast sites – sites with Cablevision or other providers
do not exhibit this issue. Until the registry settings were changed –
the speeds were consistently 6-9 Mbps. After changing the settings –
the speeds improved to 15-19 so the wireless speed is not the overriding
factor. What is concerning me is the quantity of
TCP Dup Acks seen in the traces. We have since done another test at
another person’s home Comcast circuit that is 30/5 and on this particular
setup – the TCP Dup Acks are not present and the speeds with/without the
registry settings are equivalent at the 16-18 Mbps range. So it appears
that certain Comcast locations do not have this issue. We have not tested
at all of our Comcast sites but where we are seeing this is in the My primary concern is the volume of TCP
Dup Acks and why we might be seeing these given that they are present in both
the wired and wireless traces at the sites where the wireless speeds are slow
(without the registry changes). Has anyone else seen this? Our initial conversation with Comcast for
one site in particular went about as expected – basically they said if
you are getting the speeds wired – go pound sand…. I would have liked to believe this was
strictly a wireless issue but the facts/tests point toward Comcast in several
regions. William Howard From:
wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Alan Emery This may be more related to a setting on the wireless
access point. If the wireless AP is not set to a fixed mode such as
"g" or "n", and it "hears" the presence of a
"b" device associated or not, it will go into a compatibility mode
and effectively run at the lower "b" rate. In my
What we did discover is that when testing the same equipment on a
cablevision/optimum online 30/5 circuit, the problems virtually disappear.
Wired speeds are equivalent to Comcast but wireless speeds were in the 15-19
Mbps range. TCP [TCP Dup ACK 17802#55] http > apc-3052 [ACK]
Seq=8154484 Ack=307815 Win=206848 Len=0 SLE=370595 SRE=447975 SLE=331175
SRE=335555 I have seen the "tcp
optimizers" and they have produced good results and have improved the
Comcast speeds to 12-16 Mbps but it seems very odd that only Comcast seems to
suffer from packets arriving out of order (or whatever is causing this) but
Cablevision does not. I don't like the idea of having to change a client device
when it seems like this problem lies within the Comcast network. |
- References:
- [Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision
- From: William Howard
- Re: [Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision
- From: Alan Emery
- [Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision
- Prev by Date: [Wireshark-users] Question regarding SCSI dissectors
- Next by Date: Re: [Wireshark-users] Filter retransmitted packets
- Previous by thread: Re: [Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision
- Next by thread: Re: [Wireshark-users] End to End VoIP delay calculation (Interarrival jitter)
- Index(es):