Wireshark mailing list archives

Re: TCP Dup Ack Issues with Comcast vs. Cablevision


From: Alan Emery <ademery () us ibm com>
Date: Fri, 26 Feb 2010 10:35:55 -0600


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 SOHO
environment, I fix my wireless mode to "g" as that is compatible with all
the devices I want to have connected, but if a guest brings in a "b" mode
device, they cannot connect, but they don't downgrade the throughput of my
existing network.  Your 6-9 Mbps throughput is more typical of what I would
expect in a "b" environment.

If you can isolate the wireless AP to a switch that will allow you to
connect a local target device, or to switch ports on the AP if available,
you can look at throughput just going through the AP to a local target
device to see if the issue lies with the AP or not.

Alan Emery

IBM Global Solution Center
1177 S Beltline Road, Coppell, TX 75019


                                                                       
  From:       William Howard <wghoward () optonline net>                  
                                                                       
  To:         wireshark-users () wireshark org                            
                                                                       
  Date:       02/26/2010 09:32 AM                                      
                                                                       
  Subject:    [Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision
                                                                       
  Sent by:    wireshark-users-bounces () wireshark org                    
                                                                       






We have been investigating what seems to be an obscure issue with regards
to Comcast speeds wired vs. wireless "G" speeds on a 30/5 circuit.

Here are the symptoms:

Wired (directly to modem): Speeds are what one would expect - 25-30 Mbps
down and 4-5 Mbps up.

Wireless: Speeds are in the 6-9 Mbps.  We have tried a variety of consumer
and higher end APs/Wireless routers.  All with the same basic results - the
speeds are significantly slower.
      The wireless NIC was connected with a "good" signal at 54 Mbps.
      I verified that wireless interference was not an issue.
      I tried several different laptops to make sure that the particular
      wireless NIC was an issue.
      The AP/Router were the only items on the circuit.  Time of day did
      not matter as I tried going back and forth between wired and wireless
      - both produced consistent speeds each time.
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.

In order to dig deeper, I captured wireshark traces for both wired/wireless
on Comcast and Optimum Online circuits.  The biggest difference I could
find is that on the Comcast circuit both wired and wireless, there were
many: TCP Dup ACK packets (see below for an example)
      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.

Has anyone seen this before?  Is there a solution without changing the
client laptop?  We would like to have a solution that is hardware based
(router or firmware) rather than telling users they must all make registry
changes which makes us nervous (liability) and end-users irritated that "it
works on other networks without a problem"

Any insight on this would be greatly appreciated.

Will Howard
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users

mailto:wireshark-users-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe

Current thread: