Optimising your connection - first draft for a sticky

[Rik]

Comments, corrections and suggestions welcomed.

How can I achieve the best speed from my connection?

Since I first connected my own computer to another, way back in 1984, comms has always been a black art. Back then, the big issue was agreeing a communications protocol – my first modem had a choice of tones, and you had to find out what the remote computer was using before you had a chance of exchanging any information. Standards were adopted reasonably quickly, and, with the advent of the internet, life became much simpler in that respect.

However, ADSL brings with it a new challenge, that of 'tweaking' or optimising the settings on your computer to get the best throughput from your connection.

Let me say from the outset, there is no single set of values which is right for everyone. Each connection has its own characteristics, and a set of values that worked well with one ISP may not be ideal for another. In other words, if you want to tweak, you have to be prepared to experiment and test. It's also worth noting that the benefits obtained from tweaking are often, perhaps usually, marginal, so before you start, make a note of your present values, which the two utilities mentioned later will display for you.


So, what is tweaking about?

Essentially, it's about adjusting two values in Windows (sorry, can't tell you a thing about Macs ).

The first is known as MTU (Maximum Transmission Unit). This is the largest amount of data that can be transferred in one physical frame on the network. For TCP (Transmission Control Protocol) MTU can range from 68 to 1500 bytes. Larger MTUs provide for lower overhead (fewer headers) in most circumstances, but can lead to packet fragmentation and, therefore, more overheads. For more detailed information about MTU, visit Wikipedia here.

In theory, Windows adjusts MTU automatically, in practice this does not seem to happen. If you are sending a packet which is larger than the network can accommodate, it will become fragmented into two separate packets, and this will slow down your connection. To establish the optimal MTU manually, you need to run repeated ping tests to a website you use frequently (it is worth doing the test with more than one site, eg one in the UK, one in the States).

Hit Start > Run, then type CMD and press <ENTER>. You will see a DOS-like command screen. Here, type ping www.bbc.co.uk -l 1500 -f (note there is a space between the –l and the figure, and that it's a lowercase L not the figure 1) and press <ENTER>.

You will get a response that looks something like this:

ping www.bbc.co.uk -l 1500 -f

Pinging www.bbc.co.uk [212.58.224.126] with 1500 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 212.58.224.126:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Repeat the exercise, reducing the value after the –l switch, until you get a figure which doesn't induce fragmentation:

ping www.bbc.co.uk -l 1458 -f

Pinging www.bbc.net.uk [212.58.224.126] with 1458 bytes of data:

Reply from 212.58.224.126: bytes=1430 time=54ms TTL=250
Reply from 212.58.224.126: bytes=1430 time=57ms TTL=250
Reply from 212.58.224.126: bytes=1430 time=55ms TTL=250
Reply from 212.58.224.126: bytes=1430 time=54ms TTL=250

Ping statistics for 212.58.224.126:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 54ms, Maximum = 57ms, Average = 55ms

In this example, 1458 is the optimal MTU setting.

Having established MTU, we now need to set Windows to use it (I advise always leaving your router 'wide open' at 1500, and control MTU from within Windows). To do this, you can either manually edit the registry or, better, use one of the free tools available on the 'net to do the job for you. There are two which are widely recommended, one is DrTCP, available here, the other is TCP Optimizer, available here. Of the two, I prefer the latter as it has a natty function built into it to discover the Maximum MTU, and thus save you doing all those manual pings.

The next figure to adjust is RWIN (TCP Receive Window). This is a buffer that determines how much data the receiving computer is prepared to get at one time.

An RWIN value that's too large will result in greater loss of data if a packet is lost or damaged, whilst an RWIN that is too small will be very slow, as each packet will have to be acknowledged before the next packet is sent. RWIN is one of the most important parameters in tweaking any TCP/IP connection. For more detailed information, see Wikipedia here.

In adjusting RWIN, you should look to use a figure which is a multiple of MSS (maximum segment size). The MSS is an important consideration in internet connections. TCP and IPv4 headers are 20 bytes long each, whereas an IPv6 header is 40 bytes long, so the MSS is equal to MTU - 40 when using IPv4 (currently the norm), and MTU - 60 when using IPv6.

Both DrTCP and TCP Optimizer will allow you to set RWIN, and both come from sites which will recommend figures, or ranges to you:

DSL reports

Speed guide.net

Again, I find the SpeedGuide.net site works better for me, and it has a bunch of other tools, including a security scan and key generator for WEP/WPA.

After arriving at your ideal settings for MTU/RWIN, I advise a visit to Netmonitor.org, to use their TweakTester. If this reveals packet loss, then you can usually reduce or eliminate the loss by reducing RWIN.

To find out how effective your tweaking is, you need to have recorded a reasonably large number of speed tests before you start, and then compare them to the values you obtain with your tweaking. As I've said, patience is required and the differences may be small.

[Lance]

Hit Start > Run, the type CMD and press <ENTER>.

Fourth para under "So, What is tweaking about?" Should read ...Run, then type...

Also, would it be worth just adding you may wish to make a note of your current settings etc?

In general, looks like sound advice!

Lance

[Rik]

Correction made, suggestion, adopted. Thanks, Lance.

[Lance]

Nae bother

[Rik]

To coin a phrase...

[jupiter]

When you give the ping command do you need to clarify that it is letter l which is being entered, not number 1?  They do not always look as different as the font of this message shows them.

[Rik]

Fair point, Jupiter. Numbers are always an issue with on-screen fonts. I'll just go and modify...

[CaptainSlow]

Just tried it as a cut and paste from above and got:

Ian>ping www.bbc.co.uk -l 1500 –f
Bad parameter -f.

<shrug>

[Rik]

Didn't test with cut'n'paste, something in the Word formatting didn't translate. Thanks for the heads up, now modifying... Sorted!

[CaptainSlow]

Didn't test with cut'n'paste, something in the Word formatting didn't translate. Thanks for the heads up, now modifying... Sorted!

cool!

[Rik]

Positively iced...

[CaptainSlow]

Rik, can you help please;

having tried your cut and paste thing and used it in a dos box, I found that a whole lot easier than the optimiser to get a feel for what was happening.

However, I set the new proposed MTU each time, rebooted and then retry, using the new number, only to then find this is too high again! What gives?

I got down to nearly 1200 that way earlier while tinkering, but that seems awful low numbers for this century!

Then just for the hell of it tried 1024+40 at one point, and that got interesting results, then picked a x16 for rwin and while it's strange to say the least, it's quite good too!

What thoughts on trying slightly weird numbers? I was thinking memory is a lot faster than it used to be, and so are CPUs, so what about skinny buffers, and letting the CPU really rip into it? It's not as detrimental as intuition would suggest it might be oddly.

[CaptainSlow]

For some reason or other I can not edit the above post.

I just wanted to add that it does not matter too much now. I'm stuck with 1460 as the highest I can set the MTU to. After some searching this seems a fairly common problem.

It's stopping me getting back to my highest ever speed test at a place I use a fair bit, but in truth it's not a lot slower than that astonishing moment! 

That aside I have just seen the fastest ever header request on my regular news server. I just set up a load of what looked like busy groups, no matter what was in them as it was a lot of headers I was after. I normally expect to see about 114-115KBps for a header request, and on some barmy instances it might hit 117KBps, well I just watched 118KBps as a low/average and up to 121.5 KBps. No complaints there, and this with some slight connectivity issues in general still. Looks like things are really picking up here, I'm not that fussed to see over 120KBps as that has always been a personal goal, and now it's cracked.

I'm also now seeing some nice low pings to IDNet itself; 13s&14s a lot of the time 17&18 are the slower ones on average, get the odd howler of 158 but it doesn't last for long and shows up less and less as it goes along. I reckon that's not too bad myself. Settled on the default RWIN to go with the above MTU in the end as that seemed the most reliably achievable.

[wrtpeeps]

Im slightly confused, how can i find my optimum RWIN 

[Rik]

For some reason or other I can not edit the above post.

You have the ability to edit a message for 30 minutes after posting, then it becomes 'fixed in stone'.

[Rik]

Im slightly confused, how can i find my optimum RWIN 

By experimentation, using numbers which are multiples of MSS (MTU - 40). Start off with a number around the 64k mark, then speedtest and check for packet loss with Tweak Tester. If there's no packet loss, increase the number, if you're getting packet loss, decrease it.

[Rik]

having tried your cut and paste thing and used it in a dos box, I found that a whole lot easier than the optimiser to get a feel for what was happening.

However, I set the new proposed MTU each time, rebooted and then retry, using the new number, only to then find this is too high again! What gives?

Everytime you lower MTU, the ping test will give you a lower figure before it fragments, eg if you have MTU at 1458 (Miriam's recommended value), then packets will start to fragment at 1431. Or have I misunderstood the question?

I understand what you say about smaller buffers with fast CPUs, but generally speaking, all modern CPUs are fast enough to cope with the packets as they arrive, the real issue is about optimising the traffic flow on the network in order that it can deliver fast enough to keep up with your CPU.

[CaptainSlow]

I think I didn't explain it quite adequately.

What I am saying is that you can use the dos box version to find an acceptable MTU. Having set the acceptable MTU and rebooted with it set, on rerunning it, it claims the number it just agreed upon, is now too big! This has to be a flaw, and the only fix being not to retest for confirmation once you've set a new figure! 

As for the buffering, I'm just seeing that smaller also seems to mean faster and crisper connection, today's CPUs don't seem to need a buffer. In the general run of things I read that if you check more often that packet transactions are done and valid then it could slow things down; well with older CPUs that might have been true, but the smallest I'm running tests on just now is a P4 1.8a Northwood (not very new tech but a classic CPU for all sorts of reasons), and it's easily holding it's own with the smallest buffer, it does not have to wait a preset time, as The Reading for the Optimiser suggested, before moving on to the next, so it all happens a bit quicker, whether it be a good or bad packet with a resend. The wait is a bit like a time out, but having a "mini buffer" means it it knows about a problem long before any kind of timeout competes! Seems it's quicker to find out about success or failure of a transmission early and deal with it via a resend if required than waiting for a preset length and maybe then resending on top of that.

Don't know if it's right for all CPUs of course, might not be, but that's what I am seeing here. It could also be that it's quicker for another reason that I have not noticed, but this is what fitted after I noticed what was quickest and then wondered why that might be. As you rightly say, experiment with it, find what works for your set up, that after all is what tweaking is about really.

For a "chance find" that one has worked very well for me!

[Rik]

What I am saying is that you can use the dos box version to find an acceptable MTU. Having set the acceptable MTU and rebooted with it set, on rerunning it, it claims the number it just agreed upon, is now too big! This has to be a flaw, and the only fix being not to retest for confirmation once you've set a new figure! 

Once you set MTU to something less than 1500, the fragmentation will occur at a lower figure, as I said, for a local MTU of 1458, fragmentation will show up with a packet size of 1431, whereas at 1500, it would be 1473. So, once you've decided on, and set, a lower MTU, re-testing will give misleading results. Or have I still not understood what you're saying? 

Don't know if it's right for all CPUs of course, might not be, but that's what I am seeing here. It could also be that it's quicker for another reason that I have not noticed, but this is what fitted after I noticed what was quickest and then wondered why that might be. As you rightly say, experiment with it, find what works for your set up, that after all is what tweaking is about really.

For a "chance find" that one has worked very well for me!

There are so many variables, especially with Windows boxes, that the only way I know is to test your own setup and find what works best for you. On a good connection, there may be no perceptible difference, but when you have a poor line, as I do, you can tweak a few extra kB/s out of it. It's very much an 'anorak' pursuit though.