[Martin Visser <martinvisser99@xxxxxxxxx>]

Not sure exactly what is going on, but if you are seeing duplicate ACKs from the server (the one showed had a source TCP port of http, or I guess 80, so I assume it is from the server), this like indicates the ACKs from your client are not reaching the server in a timely fashion. Is there anything you are doing to cause outbound congestion?

In order to some basic testing I would try to get an understanding of round-trip delay to your local LAN, your service provider and then on to your target server. This might help you understand where the bottleneck is occurring. You do this during your trials by simple ICMP ping, or even better use a tool like tcping or hping to more easily measure the SYN/SYN-ACK response time. Doing this simultaneously will and plotting the variation with throughput will guide you to the contributary cause.

Just remember that all 802.11 wireless networks are "virtually" full-duplex but physically half-duplex in nature. In essence the radio can only transmit OR receive at any one time.

(Way back doing 802.11b testing I could get 6Mbps down/0Mbps up, or 3M/3M or any combination).

Also 54Mbps is the physical throughput, with encoding and error connecting, the available bandwidth to IP traffic is going to be only about 25Mbps.  (In my testing above at 802.11b 11Mbps carrier, the actual goodput was 6Mbps).

Regards, Martin

MartinVisser99@xxxxxxxxx

On Sat, Feb 27, 2010 at 3:57 AM, William Howard <whoward@xxxxxxxxxxxxxxxxxx> wrote:

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 Connecticut and Massachusetts areas.

 

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
Sent: Friday, February 26, 2010 11:36 AM

To: Community support list for Wireshark

Subject: Re: [Wireshark-users] TCP Dup Ack Issues with Comcast vs.Cablevision

 

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

William Howard ---02/26/2010 09:32:29 AM---We have been investigating what seems to be an obscure issue with regards to Comcast speeds wired v

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

---

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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

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