[packman]

Lately, I've been running some experiments to try to discover why it is that my Win2K machine takes so long (2 - 5 secs) to resolve a website and begin to download the first page. I'm using 2M bit ADSL broadband, PPoA, via a router-modem, with my single Win2K machine attached via Ethernet. I also notice exceedingly slow downloads from FTP sites. Apart from that, my raw download and upload speeds are very good.

I decided to run the Tweak test at www.dslreports.com (Tests + Tools) but, frankly, the test didn't go all that well and trying new values for the TCP Window, TTL and MTU, in DrTCP, was extremely frustrating, as you have to re-boot each time.

The best values for those three (in their order) that I ended up with were:

32767
254
1492

However, I'm far from convinced that these numbers are optimised, especially the TTL value.

Has anyone else on this forum who uses Win2K experimented with DrTCP and, if so, what values for TCP Window, TTL, MTU, etc did you end up using?

[theefool]

Change the Maximum Transmission Unit (MTU) Size (Windows NT/2000/XP)
http://www.winguides.com/registry/display.php/280/
Optimize Broadband Cable Modem and DSL Connections (Windows 2000/XP)
http://www.winguides.com/registry/display.php/645/

[Sampson]

I wish I knew the magic number to give you. Actually, the default in Windows is generally good enough. I want to say that it is 65540 or some such. TTL is around 64. The only time that I found changing these values was beneficial was when I began running browsers through a proxy. On one XP machine those values are 514024 and 64. On one of the W2K machines, it is 256960 and 64. Since you are using PPoA, 1492 (or 1490) should be right.

Having said that, since I am on a cable modem and not ADSL, the slowdown in resolution (in downloading a page) is, more often than not, a function of the strength of your signal and the "noise" in the line than anything else. Making the Rwin value larger, it seems to me, allows larger packets to be sent without the error checking such that it seems faster since the "noise" doesn't cause the computer to ask for a repeat as often. The problem is that when it does have to repeat a sent packet because of excessive noise, it takes longer.

You might also want to try (and I'll bet you already have) ipconfig:
IPCONFIG /all Display full configuration information.
IPCONFIG /release [adapter]
Release the IP address for the specified adapter.
IPCONFIG /renew [adapter]
Renew the IP address for the specified adapter.
IPCONFIG /flushdns Purge the DNS Resolver cache. ##
IPCONFIG /registerdns Refresh all DHCP leases and re-register DNS names. ##
IPCONFIG /displaydns Display the contents of the DNS Resolver Cache. ##

In the end, it may be the telephone line and crossover noise that has become a problem for your signal.

[packman]

Thanks, theefool, those references are very helpful. By modding the Registry, I've now reduced the TTL value to 128.

Actually, the [Adapter ID] in the Registry is not easy to identify, to change or add the MTU value, because if you've got several different modem connections still installed (as I have), eg dial-up modem connections, they're also just alphanumeric Registry folders and you can't tell which is which.

Regarding the actual MTU value, whilst that Winguides article recommends 1500 for ADSL using PPoA, there seem to be lots of users who maintain that a lower figure is required, anything from about 1454 to 1492.

Sampson, that's an interesting theory about line noise and how it might be causing retransmissions.

[ross_aveling]

There is a simple way that you can actually work out what the best MTU setting is for your connection. It involves finding out the largest packet size that can be sent without it becoming fragmented; and then adding 28 to this value (for IP/ICMP overheads) and that's your optimal MTU setting.

Use ping with the following switches;

ping -f -l [packet size] [Public IP Address]

Try starting with a lower packet size, say 1000 and work your way up in small increments. If the transmission of the packet is unsuccessful, ping will return 'Packet needs to be fragmented but DF set'. Continue increasing the size until you get a return ping. Also try and ping one of your ISP's public IP addresses (their main website address perhaps).

In my case (I'm also 2mbit over PPPoA) the largest packet size was 1430, so adding 28 give me an MTU size of 1458.

Hope this helps.

[packman]

Ross,

I've seen that Ping command quoted elsewhere and, previously, I've tried it but I kept getting 'bad command'. I used an uppercase 'F'; maybe that was the problem. And is that an uppercase 'I' (eye), or a lowercase 'l' (el)?

What's 'Public IP Address'? Do you mean 'the LAN IP address of the router'?

You say you arrived at a figure of 1458 for your MTU. But is that with Win2K, or with WinXP? It'd help get me into the right ballpark.

How do you know which are the smallest and largest packet sizes?

[theefool]

According to this:
http://www.microsoft.com/windows2000/en/server/help/ping.htm
you should be able to use the -f for ping.

lowercase f and lowercase l not the number one.

You can do a ping -? to get a list of the switches that are available.....

[packman]

Ross,

I've now successfully done the pings. Using first my router's LAN IP address, I got a figure of 1472. It was also the figure for successfully pinging my ISP's DNS address (had to temporarily enable that in the NAT firewall).

Adding the magic number 28 to that gives me - surprise, surprise - 1500, which is the default value for Win2K/XP.

My overall basic settings are now:

RWIN = 32767
TTL = 128
MTU = 1500

[Hmm, I'm still getting delays of 2 - 7 secs when I click on a website address, before the browser resolves and then captures it. That remains a mystery].

[packman]

As a follow-up, what are:

TCP MSS value?
Cell Rate (normal, peak, and sustained)?
Maximum Burst Rate?

Is TCP MSS the same as MTU?
Is Max Burst Rate the same as TCP Window (RWIN)?

[I'm just wondering whether the slow resolution of websites I'm getting is due to settings in my router (such as above) being perhaps in conflict with settings in Windows. At present, all values in my router for the above are left blank, which I presume will render default values].

[Sampson]

Ah, you are using a router. Do you also have a software firewall running on your computer in addition to the router?

I am sure that you went through these steps, but normally, you would first power down the computer, then turn off router and modem. Then, connect the modem directly to the computer. Turn on the modem and let it sync with your provider. Turn on your computer. This will allow it to connect with your ISP. If you have a software firewall running you may have to adjust its settings. Do your ping tests. When satisfied, power down the computer - then the modem. Reconnect your modem to the router. Power up the modem. After it is synched power up the router. Finally, power up the computer. If you are running a software firewall, it might also popup and you will have to accept the new default settings.

Check out your hosts file. Some folks use this to eliminate software ads. Unfortunately, certain spyware programs also use it for redirection. Generally, it has only one entry.

The reason I asked you to run ipconfig is to flush the entries from the DNS cache. Your ISP provides the "translation" for this cache such that when you type google.com into your url it has a database that translates this to the numeric address. That database is put into a cache for your machine to speed up the translation.

If you are running a software firewall behind your router, check your rules to see if there is a conflict.

Cookies - how do you have them defaulted? Some sites want you to have their cookie on your machine and they put in a delay penalty if you choose not to accept it or if you have concretely denied it.

Finally, ADSL is dependent upon how far your connection is from the local "base". The further you are from it physically, the greater the delay because of signal strength.

[Sampson]

One other thought. If there is a tech support for your ISP/modem provider, ask them to run two tests on your modem. The first test is from them to your modem. The second test is from them to your (computer/router)through the modem. The first test will tell them of packet drops to the modem; the second test will actually test the ethernet port from the modem to your computer/router. You can have a perfectly pristine test on the first and a drop in the second. What that means is that the ethernet connection on the modem may be messed up. If the first test shows packet or signal drops - it is the telephone line crossover and a signal problem.

[packman]

Yes, I'm using a software firewall as well but it's never given rise to any conflicts. As for the order of turning on things, I've already explored that and it doesn't affect this delay problem. Tests on the Ethernet connection show no problems, either. As for getting my ISP to test out my connection, well, pigs might fly. Regardless, there's software in the router that tells me something of the quality of the line and, whilst that's not brilliant (I'm about 5km from the exchange), it doesn't show any lost packets or collisions.

As for the delay being caused simply through distance, I think you need to look at your physics again, as a delay of 2 - 7 secs would mean I'd be 1000s of miles away! It's clearly nothing to do with 'distance from exchange' per se.

No, the delay is either due to noise on the line and subsequent retransmissions, a conflict of the settings in my router with those in Windows, or it must be due to some sort of resolution problem. Other owners of the same router have the same problem, but not all, by any means.

[Sampson]

Sorry. By local "base" I meant that DSL has a 10 mile range away from the telephone exchange or retransmission station. Depending on your home or office's physical placement in relation to the phone exchange, affects the strength of the signal.

[packman]

I don't know where you're getting your figures from, Sampson, but here in the UK, the 'feasible distance' at present for 2M bit/sec ADSL is notionally 3.5km. That's about 2ml. Some ISPs have arrangements with the infrastructure provider (sometimes they're one in the same people, sometimes they're not) where ADSL can be swapped to RDSL. The latter still operates in ADSL mode but extends the capability to about 5.5km. If you're situated that sort of distance away, or even further, the signal will not only be more attenuated and therefore more difficult to keep in sync with the user's modem but also the line will be more susceptible to noise (with the same result), the overall outcome being that more retransmissions of packets will take place. Thus, you're more likely to get a lower overall data rate than the advertised nominal one.

Actually, even though I'm somewhere between 4 and 6km from the exchange, my raw maximum download rate is 1.89M bits/sec, which is pretty good for a nominal 2M bit connection. And, as far as I'm aware, that's on pure ADSL, not RDSL.

Actually, the attenuation problem (and here I speak as a retired professional electronics engineer) is normally two-fold: pure volt-drops due to length of line and numbers of joints in the line, and frequency-dependent attenuation (analogue bandwidth of the line, down to capacitance and inductance /ft of the line). Thus, the further you move away from the exchange, the greater the overall attenuation. Interestingly, for analogue voice calls, the equipment at the exchange would apply AGC (automatic gain control), which would ensure that your phone would always operate reasonably well, even though you were situated an appreciable distance away. But there's a limit to the amount of AGC that can be applied. I've no idea if AGC is employed in DSL and cable broadband; I somehow doubt it.

[If my memory serves me correctly, electrical signals propagate in copper wires at about 0.7nanoseconds /ft. Roughly estimating, that means that there'd be a delay of about 10 microseconds between the exchange and my router-modem].

[Sampson]

Thank you. That clears that up and it is one more theory that can be eliminated from your delay.

[packman]

As I say, I'm pretty well convinced it's a software problem of some sort - maybe a wrong configuration setting in the router that's affecting the resolution of each website's address, or an inherently-slow processor in the router (though I couldn't imagine it to be THAT slow). That said, I don't altogether rule out the possibility of it being caused by noise on the line, as statistically you'd find that SOME users get this problem and SOME don't, and that's exactly what's happening, according to tech forums around the world on this particular router-modem. However, noise tends to be spurious and therefore wouldn't affect EVERY website acquisition on EVERY single occasion.