This is a complex problem with many possible causes which requires a detailed explanation. But first some background on how IP works particularly in high speed networks like Opticomm’s.
Many Internet applications such as HTTP and FTP use a protocol called TCP/IP. As part of its congestion control strategy TCP/IP implements a mechanism called “slow start”. This is used in conjunction with other algorithms to avoid sending more data than the network is capable of transmitting. It is also known as the “exponential growth phase”.
During the exponential growth phase, Slow-start works by increasing the TCP window size each time an acknowledgment is received back from the other computer involved in the HTTP or FTP session. This happens until either an acknowledgment is not received for some segment or a predetermined threshold value is reached. If a loss event occurs, TCP assumes this it is due to network congestion and takes steps to reduce the offered load on the network. Once a loss event has occurred or the threshold has been reached, TCP enters the linear growth (congestion avoidance) phase. This is why when you start a download; it begins slowly and then increases over time until it eventually levels out.
In TCP stacks the maximum number of bytes that can be transmitting (specified by the TCP receive window size) is limited to 65,535 bytes by the 16 bit window size in the TCP header. Often the 65,535 byte value is used to illustrate the maximum theoretical throughput of TCP. In the early 1990s it was recognized that higher bandwidths were becoming available and that TCP needed to be updated to support high bandwidth, high latency networks. This resulted in the publication of RFC1323 which specified modifications to TCP to support the high bandwidth, high latency networks.
In practice however, most TCP stacks (e.g. older windows versions) do not support RFC 1323 extensions and have a standard TCP window size in the order of 8 KB. Some of the more modern operating systems (such as Windows Server 2003, Vista, Linux or Mac OSX) while they support RFC 1323 extensions, the TCP/IP configuration only allows for a receive window up to 65,535 bytes in size. However in RFC 1323 a scaling factor is used to get a larger TCP receive window size to achieve more efficient use of high bandwidth networks. Scaling up to larger TCP congestion window sizes is a part of what is necessary for TCP Tuning but is not enabled by default in some operating systems.
The introduction of Windows Vista saw a new feature called “Receive Window Auto-Tuning”. What it does is to adjust the receive windows size continually based upon the changing network conditions. You can review this Microsoft article if you are interested in further details.
However, like many Microsoft operating system this function does not always work as planned and some end-users have reported that auto-tuning can cause network performance problems with some applications and routers. You can turn it off if you experience such problems.
- Open up a command prompt.
- Enter the following command to disable auto-tuning
netsh interface tcp set global autotuninglevel=disabled
If you found that this doesn’t fix your problem, you can turn it back on.
- Open up an elevated command prompt.
- Enter the following command to enable auto-tuning
netsh interface tcp set global autotuninglevel=normal
- You can use this command to view the states of the TCP global parameters.
netsh interface tcp show global
Unrelated to the TCP receive window, the sending side should also allocate the same amount of memory as the receive side for good performance. As frequently we don’t have control over the sending side (e.g. remote third party servers), the problem with network performance can actually be the server and not the client or the Opticomm network. That is because, even after data has been sent on the network, the sending side must hold it in memory until its has been acknowledged as successfully received, just in case it would have to be retransmitted. If the receiver is far away, acknowledgments will take a long time to arrive. If the send memory is small, it can saturate and block emission.
So with that background, we now need to consider the latency between a server and a client, as latency to TCP/IP means congestion. The way TCP/IP works with the slow start means applications such as HTTP and FTP will be affected in performance irrespective of the speed of a link provided by Opticomm. Even if there is no packet loss in the network, windowing can limit throughput simply due to the time it takes from one end to send a packet and receive back an acknowledgement. Because TCP transmits data up to the window size before waiting for the packets, the full bandwidth of the network may not always get used.
So the based on the above information the maximum throughput a single FTP or HTTP session can sustain is entirely dependent on the Round Trip Time or Latency between the client computer and the server which is supplying the file. The round trip time can be check by using a simple PING command from the command prompt as follows:
- Open up a command prompt.
- Enter the following command to check the Round Trip Time
ping 172.31.250.254
Where the 172.31.250.254 is the IP address of your test server providing the HTTP or FTP transfer.
This will provide a result similar to the following:
Pinging 172.31.250.254 with 32 bytes of data:
Reply from 172.31.250.254: bytes=32 time=1ms TTL=255
Reply from 172.31.250.254: bytes=32 time=1ms TTL=255
Reply from 172.31.250.254: bytes=32 time=1ms TTL=255
Reply from 172.31.250.254: bytes=32 time=1ms TTL=255
Ping statistics for 172.31.250.254:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
The Round Trip Time is identified by the red text and the output may vary from operating system to operating system.
Depending on the result of the ping test, the best performance of a single FTP or HTTP session is as follows:
1 mS
65,262 Kbps
122,128 Kbps
337,750 Kbps
2 mS
33,793 Kbps
65,262 Kbps
205,418 Kbps
3 mS
22,799 Kbps
44,528 Kbps
147,591 Kbps
4 mS
17,203 Kbps
33,793 Kbps
115,170 Kbps
5 mS
13,812 Kbps
27,228 Kbps
94,427 Kbps
10 mS
6,957 Kbps
13,812 Kbps
49,685 Kbps
20 mS
3,491 Kbps
6,957 Kbps
25,510 Kbps
30 mS
2,330 Kbps
4,649 Kbps
17,160 Kbps
40 mS
1,749 Kbps
3,491 Kbps
12,929 Kbps
50 mS
1,400 Kbps
2,795 Kbps
10,371 Kbps
60 mS
1,167 Kbps
2,330 Kbps
8,658 Kbps
70 mS
1,000 Kbps
1,998 Kbps
7,431 Kbps
80 mS
875 Kbps
1,749 Kbps
6,509 Kbps
90 mS
778 Kbps
1,555 Kbps
5,790 Kbps
100 mS
700 Kbps
1,400 Kbps
5,214 Kbps
150 mS
467 Kbps
933 Kbps
3,482 Kbps
200 mS
350 Kbps
700 Kbps
2,614 Kbps
A full table is available at http://www.babinszki.com/Networking/Max-Ethernet-and-TCP-Throughput.html.
While the Opticomm fibre to the premises network is low latency with typical ping times of sub 5ms between the end-user’s computer and their service provider’s LNS, once it leaves our network and enters the Internet there are many issues which can affect the possible throughput. Therefore to test the throughput of an end-user’s service you may be required to run up multiple simultaneous FTP or HTTP transfers.
Even then there are other factors which can impact the results of testing from a single server to a single client computer, these include:
- Router performance – ensure your home gateway or business router is capable of running at high speed. Many current generation ADSL2+ or Cable routers are only capable of 25-30Mbps before saturating the CPU. Opticomm has a list of tested routers some like the Linksys WRT310 which support 100Mbps+ performance.
- Server performance – many FTP or HTTP servers limit the performance of their individual sessions so a single client cannot saturate the network or attempt DoS attacks.
- Server Link performance – while you may have access to 50 or 100Mbps, this does not mean the server from which you are testing has that much bandwidth availabe at any given time. Testing should be done to multiple servers simultaneously.
- Is the PC capable – Some PC’s (particularly laptops) were simply not designed to sustain 50 or 100Mbps speeds. The tell tale sign is the hard disk chattering away while downloads are being performed. The PC may also be doing other things in the background which impacts the performance of testing such a high speed network.
- The home or business network – is the network well designed for high speed; are the links all working in full duplex mode; are quality cables used; is there interference with power cables; is a wireless network being used. These are all factors inside the home or business which could impact the performance of a high speed Internet service.
In summary:
You need to run multiple tests to multiple servers at the same time and add all the results together. Its important to understand that this limitation is not of the FTTH network but of the operating systems (e.g. Windows) using the network. You will never experience this problem in a Local Area Network because latency is not an issue. Its not that you can’t push to the FTTH link to a full 100Mbps – you can and we have tested this – its you cannot do it from a single computer communicating to a single server doing a single test.
To finish, the use of testing sites such as http://www.speedtest.net and http://www.ozspeedtest.com is not recommend. These tests typically cannot cope with high speed networks and have been tuned for the typical ADSL2+ type speeds. Furthermore they are only single session tests and are entirely reliant on the available (and spare) bandwidth to these sites. So in summary it is not possible to test a 50 or 100Mbps service using TCP/IP base applications (such as FTP or HTTP) using a single computer with a single session. You will need to have a fast computer with a good Ethernet card, a well tuned TCP/IP stack and operating system and run multiple TCP/IP sessions to multiple servers.
One of the best sites for a detailed explanation of TCP/IP tuning including operating system recommendations is http://www.psc.edu/networking/projects/tcptune.
0 comments:
