Throughput with wireless & DSL

oscarBravo

(This is a strange problem, and I don't know if it's best posted here, in Wireless or in Broadband. Maybe I'll post links to this thread in those boards.)

I have a 2Mbit DSL line from Netsource - yum. When I plug my laptop directly into the supplied Allied Telesyn AT-AR250E 4-port router, I get nice connection speeds - 1.6Mbit/sec on the Giganews speed test.

I have a Demarc Technologies wireless access point connected to the router, with a 24dBi antenna linking it to a Demarc wireless bridge 10km away. Plugging the laptop into the other end of the wireless link give me only 2-300kbit/sec on Giganews. If I connect to the access point using a wireless card in the laptop, I get 700kbit/sec.

I tested the link by FTPing a file back and forth between PCs at either end of the wireless link, and I get 4-500kBytes/sec, - 4mbit/sec - about what you'd expect over 802.11b, ergo the wireless link itself is fine.

All this means there's a problem between the DSL and the wireless connection. Has anyone any idea what could possibly clobber the throughput to this extent?

spongebob

your MTU , the effective packet size could be the issue. Try to make sure its the same on the DSl and on the Wireless Net behind it.

2 values need setting, MTU and MSS .

Karl Jeacle explains some of it here

http://www.jeacle.ie/adsl/

"The Maximum Transmission Unit (MTU) is the largest size packet that a network link can carry. Ethernet's MTU is 1500 bytes. When an IP packet is carried on ethernet, the full 1500 bytes is available to carry IP information. However, when running IP over PPP over Ethernet, an extra layer is introduced. PPPoE requires an 8 byte header. This means that a host running IP over PPPoE must set its MTU to 1492.
The Maximum Segment Size (MSS) is the largest segment of user data that a TCP connection can carry. It is typically 40 bytes smaller than the underlying link's MTU. This is because a packet's IP header and TCP header are normally 20 bytes each. So when running TCP over IP on ethernet, every 1500 bytes of user data in the ethernet frame contains just 1460 bytes of TCP user data. When running TCP over IP over PPPoE, the MTU is 1492, so the maximum amount of user data that can be sent between TCP end-points is 1452 bytes.

By default, all PPPoE clients set their MTU to 1492, so a PPPoE client will open all TCP connections with MSS advertisements of 1452. The TCP stack at the other side will honour this MSS, and will never send an IP packet larger than 1492 bytes. So everything is fine on the PPPoE client. What causes some people trouble is when they try to share their DSL line by putting other PCs on a LAN behind their PPPoE connection.

When this happens, the PCs behind the client probably have MTUs of 1500, TCP will offer an MSS of 1460 to remote sites. When these remote sites try to send back packets, they run into difficulty because when the packets reach the ADSL connection, the MTU on the link is too small. An ICMP error will be generated telling them that their packets are too large and should be fragmented. This is a process known as Path MTU Discovery (PMTU-D). In theory, they should get this ICMP message and resend. In practice, this doesn't always happen. Unfortunately, many sites block ICMP, and this breaks the PMTU-D process. Mark Slemko has written a commonly referenced document on PMTU-D and ICMP.

If the client PCs have their MTU set to that of the host running PPPoE (typically 1492 - but could be lower in the case of L2TP), this problem will never happen. TCP will ensure that the MSS is set appropriately low so that all packets will get through. However, a better solution is not to change all the internal PC's MTUs, but to use a gateway with a PPPoE implementation that is aware of the problem and can dynamically modify the MSS of a client PC's outgoing TCP packets. Most modern PPPoE routers and Unix PPPoE/NAT implementations can do this. "

Also see http://www.daemonnews.org/200101/pppoe.html if the clients are *nix and check http://www.linux.ie

On Win boxes you put the optimal MTU and MSS values in the registry on the TCP/IP parameter keys thereby overriding the defaults

You probably also have to force the settings on the inside interface of the router that is connected to the DSL line in case inside systems 'take their cue' dynamically from the interface over ethernet.

Note these MS Kb articles too including service pack oddites

http://support.microsoft.com/default.aspx?scid=kb;en-us;136828

http://support.microsoft.com/default.aspx?scid=kb;en-us;301337

http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/cnet/cnbc_imp_gbmf.asp

M

oscarBravo

Ta, Muck. It gets stranger:

At the CPE end of the wireless link I have a LocustWorld meshbox - basically a wee Linux PC. It has a speed testing script called leechtest, which clocks 1.6Mbit! I checked the MTU settings on it, and all interfaces have it set to 1500. This meshbox is connected to the same switch as the PC that's only clocking 300kbit.

Similarly, a Linux laptop connecting via a wireless card to the access point is getting 1.6Mbit. The strangest thing of all is that the same Windows laptop gets completely different results when connected by ethernet to what it gets when connected wirelessly.