Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Oldjim on March 04, 2017, 02:28:08 PM
-
I have a machine still running XP and with a sync speed of over 40Mb/s I suspect it may help but would appreciate comments before I try it
Alternative is TCP Optimizer
-
To be honest I’ve never noticed any difference when using either of those ‘optimiser’ apps on any Windows machine.
Others may have a different view.
-
If you haven't tweaked since getting fibre, I'd say it's definitely worth a go on XP. It was only on Vista and later that RWIN etc were dynamically managed.
Just a couple of thoughts - throughput would be the figure to go by, rather than sync? It makes no difference whether it's fibre or not?
Personally I found DrTCP to do the job easily, but TCP Optimizer unnecessarily complex.
-
run drtcp, increase the rwin and make sure is a multiple of mss, you can get your mss from speedguide.net tcp analyzer page.
There is no optimal rwin size for everything, hence why modern operating systems automatically dynamically adjust per tcp session. I would suggest a rwin of around 256k as a starting point. With a mss of 1452 which is the mss of most FTTC PPPOE connections try a value of 255552, disable tcp timestamps also, if they left enabled then the mss will be lower than 1452 so you would need to recalculate.
-
Tried TCP optimiser and to be honest I couldn't see any difference
-
Chrysalis, what is the OP's likely bandwidth-delay-product then? What latency?
I take it you're not a fan of TCP timestamps? (Jury very much still out at Weaver Towers.) I forget, it's been so long, could you set things like this on/off in XP? I used the relevant netsh commands for >= Vista, and didn't ever look at poss. related registry setting for XP, if any.
-
the rtt will depend on the endpoint but the default rwin for XP is extremely small unless its connected to a gigabit ethernet and even then is still quite small, a 256k window is still a substantial increase whilst still not been very large in the grand scheme of things. a 256k window should allow for 40mbit throughput from western EU and UK servers.
default rwin for XP if I remember correctly
4k for 10mbit ethernet
16k for 100mbit ethernet
64k for gigabit ethernet
also rfc1323 will need enabling.
-
It's been so long. You have to tweak the registry in WinXp, that's the only option, apart from these friendly apps?
(To automate it, you could use the REG command iirc rather than regedit, or put that in a batch file. That's what I always did in those ancient days, or used a .reg file.)
-
yes its registry editing, but drtcp does it via a user friendly gui.
so this is the ui http://www.softpedia.com/get/Tweak/Network-Tweak/DrTCP.shtml#sgal_0 (select screenshot on left, I cannot directly link to the image sorry)
input as follows oldjim
tcp receive window 255552
window scaling enabled
thats it, hit save and reboot.
-
Just to point out for others, Chrysalis, as already pointed out, has done the right value specifically for the OP only. The value is only correct if you are using IPv4, not IPv6 - but this is WinXp, so very unlikely to be using IPv6, and it's only correct if you are using this particular MTU for PPPoE. Anyone else using WinXp then please shout, as you may or may not want a slightly different number. This is because figure is a multiple of x where x depends on your circumstances.
But modern operating systems do the right thing now anyway so there is nothing to think about for post Win-Xp users.
-
I don't think the exact value is particularly essential. The RWIN sets a maximum size, if it's not large enough, it may restrict the throughput. You may know the maximum TCP MSS for your Internet connection, but this won't always be the MSS used for every server you connect to on the Internet, some servers may use a smaller MSS. The RWIN won't always be completely filled (in fact you'd want to avoid it being small enough to fill up completely), so I think the exact size is not so important.
-
@ejs - agreed. I had this idea that it was considered best to make it a multiple of the MSS, as Chrysalis did, but surely it isn't critical, as you point out.
-
The value I posted I consider a good starting point but it may turn out of course to not be big enough and then need further adjustment.
You guys are correct that the rwin serves as a limit rather than an actual window size, the sending server's congestion window is the actual size, but TCP can keep growing that window past whats needed which can cause specific downsides which I suppose is one of the reasons the recipient can cap this growth via a receive window.
My favourite everyday vista+ autotuning setting I tend to use is at highlyrestricted, which does auto tune but caps the rwin to a 256k size. Occasionally I do have to bump up to restricted tho for endpoints that have a very high latency and I need high throughput from. With so many content providers now using CDN's or at least localised server's then a super high rwin thankfully isnt as important as it used to be.
-
What happens if you use "normal" ?
For other users of >= Vista, the command is
netsh interface tcp set global autotuninglevel=normal
(btw need to run this command as an admin, it is system-wide, not "for the current user")
And
netsh interface tcp show global
shows you what the current TCP auto-tuning settings are.
* If you have a truly ancient router or firewall then you might need to change the Windows settings above in order to thoroughly _cripple your throughput_ to prevent the tragic firewall or router from munging your packets all the time and causing unreliability, misery, and stress. Nice. Far better to run, not walk, to bin said duff firewall or router. (Straight modems are not an issue.) This is because many years ago there were some bug-ridden routers and firewalls that did not understand internet standards and freaked out in all kind of strange subtle and horrid ways if your o/s used a vital standard feature called 'window scaling'. Many were fixed by firmware updates. I can't imagine that there are still any such devices around nowadays though unless perhaps lurking in the darkest recesses of cupboards / attics or eBay. So I don't know why I'm giving this warning. Better be safe I suppose.
-
normal and restricted are the same with the one difference that restricted ramps up in a more conservative manner, both have the same upper limit which I think is 16meg, experimental allows to go over 16meg.
-
Thanks Chrysalis
Will change to the numbers suggested although before I do this page seems to suggest a value of 580,000 which is a lot higher https://community.plus.net/t5/Library/Guide-To-RWIN-amp-MTU/ba-p/1322233 also - and this contradicts both of these values - isn't the limit you can put in the field 65,535 as it is a 2 byte field or does the program do something with windows scaling - a value of 4 perhaps
-
windows scaling increases the byte limit.
you can try the higher value its up to you, I just suggested that as a starting point.
-
Oldjim - correct this is a two byte wide field, but window scaling means that it is to be reinterpreted as something shifted left n places, so this is how you get the big values. The wider (shifted) result value that you can enter clearly has to be a multiple of 2n bytes and it has been suggested that you make the thing a multiple of MSS as discussed earlier, a slight tweak, not critical, if my understanding is correct (very rusty). I have heard of window scale shift values that are quite high, they are not always the smallest values that will reach a particular result. ( eg << 8 even though the result is nowhere big enough to need it.)