Windows TCP Settings - Follow up - Help with server communication


log in

Advanced search

Message boards : Number crunching : Windows TCP Settings - Follow up - Help with server communication

Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 . . . 14 · Next
Author Message
msattler
Volunteer tester
Avatar
Send message
Joined: 9 Jul 00
Posts: 37315
Credit: 499,527,234
RAC: 511,949
United States
Message 1344015 - Posted: 8 Mar 2013, 8:03:44 UTC - in response to Message 1343920.
Last modified: 8 Mar 2013, 8:10:27 UTC

@Richard - Maybe as a note at the end of the sticky...

For those people that do not want to run TCPoptimizer and only want to enable only RFC1323 can do so by the following.

Windows Vista/7/8 Machines can use the following commands in an administator command window to active RFC1323 Window Scaling and Timestamps.

netsh int tcp set heuristics enabled
netsh int tcp set global timestamps=enable

And make sure to reboot afterwards.

I used those commands on my daily driver, a Win 7 rig.
Seems to have worked, a stalled AP download completed without further stalls.
Checked the registry, and it did add the 1323 dword.
It was, however, set to 2 instead of to 3. Dunno what the difference is.
And don't know if those commands would work on my 8 XP based rigs.

EDIT...
I found it.
2 enables timestamps only.
3 enables timestamps and scaling.
Mebbe I should edit it to 3?
And the XP question remains.
____________
******************
Crunching Seti, loving all of God's kitties.

I have met a few friends in my life.
Most were cats.

Cosmic_Ocean
Avatar
Send message
Joined: 23 Dec 00
Posts: 2204
Credit: 8,014,983
RAC: 4,124
United States
Message 1344017 - Posted: 8 Mar 2013, 8:32:18 UTC - in response to Message 1343971.

But I'll still complain about Vista's file transfer performance over my network compared to XP and Win7 (but then again there's still plenty more to complain about with Vista).


Vista had this "feature" where if you were playing any kind of multimedia at all (music, videos, internet streaming), it would throttle the network communications to something like 50-100 packets/second (maybe it was a bit more than that) so that CPU load for processing the transfer would not eat into playback performance, which even on gigabit would end up only allowing you to transfer at 30-50mbit across the LAN.

There was a registry entry that you could go in and set to 0xFFFFFFFF that would effectively disable the feature, though technically it was still enabled.. it is just really difficult to get one machine to push 4.2 billion packets/second across the network.

I don't know if there was a later update to fix that or make it a bit more relaxed, but I do know that "feature" is completely gone in 7.



As for being on win7 and the current 1323 registry entry.. I have set mine to 3, but I have not rebooted yet nor have I gotten any new APs. Just for a test, I put the same entry on an XP machine that just browses the web and checks email, and I don't see any difference there. This machine has been doing great with the proxy that I configured last week, so maybe I'll disable the use of a proxy and wait to see what happens.
____________

Linux laptop uptime: 1484d 22h 42m
Ended due to UPS failure, found 14 hours after the fact

Lionel
Send message
Joined: 25 Mar 00
Posts: 543
Credit: 198,021,926
RAC: 164,251
Australia
Message 1344019 - Posted: 8 Mar 2013, 8:34:55 UTC - in response to Message 1343978.

Lionel what can I say but, at least T.A., Grant. several others plus ourselves now know why I've been getting work all these many months when you guys have been battling.

[Edit]But what I've done differently across 4 different versions of Windows I can't tell you.[/Edit]

Cheers.


Wiggo, I know, what can I say other than I am amazed. It's good luck to you :)

Anyway, I am now looking forward to the next scheduled outage and/or shorty storm to see what happens.

Lionel

____________

Grant (SSSF)
Send message
Joined: 19 Aug 99
Posts: 5566
Credit: 51,371,430
RAC: 40,970
Australia
Message 1344021 - Posted: 8 Mar 2013, 9:06:33 UTC - in response to Message 1344015.

netsh int tcp set heuristics enabled
netsh int tcp set global timestamps=enable

I used those commands on my daily driver, a Win 7 rig.
Seems to have worked, a stalled AP download completed without further stalls.
Checked the registry, and it did add the 1323 dword.
It was, however, set to 2 instead of to 3.


Ah, i used the command lines as well & i didn't check that.
Just edited my systems- doing the same ISP speed test it still starts the download off slow, but builds up to speed much faster than before. For uploads, it gets up to speed much faster, and also the final speed is faster than it was with the value at 2 instead of 3.
I've set NNT again & well see how a bunch of downloads go now.
____________
Grant
Darwin NT.

Richard Haselgrove
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8275
Credit: 44,954,896
RAC: 13,717
United Kingdom
Message 1344029 - Posted: 8 Mar 2013, 10:20:44 UTC

Guys - I know this is getting to be a long thread already, but we covered all of this at the beginning. Time for a recap.

This thread is not about raw download speeds. Don't bother looking for that, or reporting it.

It is about downloads running smoothly and continuously, without stalls and backoffs. Actually, it might help with server replies too, though we haven't specifically been looking for that.

It works, because we're using proper internet tools for coping with long, slow, and congested lines between us and Berkeley. Anyone who is lucky enough to have a fast, clear line won't need it.

Most of us Windows users (especially home users, rather than people working for big organisations) do need it, because of a slightly strange decision made by Microsoft. Although they gave Windows the ability to cope with Internet congestion (*see below) way back in Windows 2000, they didn't turn it on. All we're doing is flicking Bill Gates's switch for him. And, because it's been in Windows since W2K, yes, I expect it to work exactly the same in XP too - though none of my XP machines need so many downloads that I've bothered to test yet. That will come in due course.

* The congestion we're talking about is when a single big long file coming down the line gets confused, and stops. That's the classic SETI problem. Loading a complicated web page usually involves loading lots of little tiny files, which is a different problem entirely. This fix probably won't help much, but it might.

Two things remain to test from recent posts, then.

1) Does cdemers' "netsh" command line, setting Tcp1323Opts to 2, work well enough by itself? Or do we need Tcp1323Opts=3, with Window scaling enabled too? I have an alternative command line which does that (thanks to PMer), but I need to check some extra options before posting.
2) Somebody with a fast WinXP box take her for a spin, please, and report back.

Richard Haselgrove
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8275
Credit: 44,954,896
RAC: 13,717
United Kingdom
Message 1344039 - Posted: 8 Mar 2013, 11:43:09 UTC
Last modified: 8 Mar 2013, 12:20:21 UTC

OK, starting to look into the Windows XP situation - I'm using Windows XP Home, but I don't think Pro will be different in this area.

1) The netsh command doesn't work - well, it's there, but it doesn't use the same syntax, and it doesn't have the subcommands we're using here. Even in Windows 7, you would need to use both the commands given, and I'm getting worried that one might overwrite the other.

2) The easier command line tool, which we've tested on XP, Vista and 7, is

REG ADD "HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "Tcp1323Opts" /t REG_DWORD /d 3 /f

That needs an elevated command prompt (log on as an administrative user in XP: use "Run as Administrator" in Vista/7), and it won't have any effect until the next reboot.

Now off to see if it unblocks the line on a fast-ish machine.

Edit - yes, it works on XP. I set it by pasting the command line in this post, and rebooting. Got 40 new tasks (all shorties, so this is obviously a good time to test). Downloaded without a single backoff. Took nearly 20 minutes, but that's still faster than I can crunch them.

Terror Australis
Volunteer tester
Send message
Joined: 14 Feb 04
Posts: 1627
Credit: 200,823,562
RAC: 63,049
Australia
Message 1344045 - Posted: 8 Mar 2013, 12:23:22 UTC - in response to Message 1344029.
Last modified: 8 Mar 2013, 12:33:34 UTC

2) Somebody with a fast WinXP box take her for a spin, please, and report back.

I suspect there may be a difference between the XP and Win7 versions of netsh

I tried both of cdemer's netsh commands on my "fast WinXP box"

netsh int tcp set heuristics enabled
netsh int tcp set global timestamps=enable


and in both cases I got a "The following command was not found" error. Going through the netsh sub commands one by one, in both cases it's the last commands that are missing. i.e. the "heuristics" and "global timestamps" options.

Checking the registry, I found that TCPOptimiser had set the TCP13230 option to dword 3

T.A.

Edit: I see Richard came to the same conclusion while I was testing and typing :S

Richard Haselgrove
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8275
Credit: 44,954,896
RAC: 13,717
United Kingdom
Message 1344046 - Posted: 8 Mar 2013, 12:32:39 UTC - in response to Message 1344045.

I suspect there may be a difference between the XP and Win7 versions of netsh

Yes. Compare:

http://technet.microsoft.com/en-us/library/cc754516(v=ws.10).aspx (Vista, 7, Server 2008)
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netsh.mspx?mfr=true (2000, XP)

juan BFB
Volunteer tester
Avatar
Send message
Joined: 16 Mar 07
Posts: 4616
Credit: 233,287,446
RAC: 340,962
Brazil
Message 1344047 - Posted: 8 Mar 2013, 13:03:02 UTC
Last modified: 8 Mar 2013, 13:07:07 UTC

One probabily "stupid" question, there is not a simple command that could made in the server side that make the job? Or at least eliminate the need of the changes in the windows hosts? My point is, others projects works fine without need to make this ajust in the client side, so that is possible. Is easy to make the ajust in one server than who knows 200K clients?, and sure a lot of users never read the threads so they will not make the ajust at all, besides of those who don´t whant/know who to do.

Maybe you Richard could talk with Matt and see if that is possible. Probabily all we need is a simple change in the configuration on the server side.
____________

msattler
Volunteer tester
Avatar
Send message
Joined: 9 Jul 00
Posts: 37315
Credit: 499,527,234
RAC: 511,949
United States
Message 1344054 - Posted: 8 Mar 2013, 14:01:05 UTC - in response to Message 1344039.

OK, starting to look into the Windows XP situation - I'm using Windows XP Home, but I don't think Pro will be different in this area.

1) The netsh command doesn't work - well, it's there, but it doesn't use the same syntax, and it doesn't have the subcommands we're using here. Even in Windows 7, you would need to use both the commands given, and I'm getting worried that one might overwrite the other.

2) The easier command line tool, which we've tested on XP, Vista and 7, is

REG ADD "HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "Tcp1323Opts" /t REG_DWORD /d 3 /f

That needs an elevated command prompt (log on as an administrative user in XP: use "Run as Administrator" in Vista/7), and it won't have any effect until the next reboot.

Now off to see if it unblocks the line on a fast-ish machine.

Edit - yes, it works on XP. I set it by pasting the command line in this post, and rebooting. Got 40 new tasks (all shorties, so this is obviously a good time to test). Downloaded without a single backoff. Took nearly 20 minutes, but that's still faster than I can crunch them.

Yup, it works on XP Pro x64...
Had 3 AP WUs trying to download with little success. Did the command line just as you posted and rebooted.
Voila. Not fast, as you have mentioned, about 6-7kbs, but they plodded through to completion. And the important thing for that host was...they did not go into retry status, so the host was able to request and get more work for the GPU whilst the APs were downloading. Before that, the AP downloads were going into retry status round robin, and no work was being requested.

____________
******************
Crunching Seti, loving all of God's kitties.

I have met a few friends in my life.
Most were cats.

Terror Australis
Volunteer tester
Send message
Joined: 14 Feb 04
Posts: 1627
Credit: 200,823,562
RAC: 63,049
Australia
Message 1344058 - Posted: 8 Mar 2013, 14:22:34 UTC - in response to Message 1344047.
Last modified: 8 Mar 2013, 14:27:53 UTC

One probabily "stupid" question, there is not a simple command that could made in the server side that make the job? Or at least eliminate the need of the changes in the windows hosts? My point is, others projects works fine without need to make this ajust in the client side, so that is possible. Is easy to make the ajust in one server than who knows 200K clients?, and sure a lot of users never read the threads so they will not make the ajust at all, besides of those who don´t whant/know who to do.

Maybe you Richard could talk with Matt and see if that is possible. Probabily all we need is a simple change in the configuration on the server side.

From my limited knowledge of networking, I would guess that this is a "client side" problem rather than a problem with the server.

It has already been noted that Windows machines are effected while Linux boxes and Macs suffer relatively few problems.

I suspect it has more to do with the Windows default settings (i.e. time stamping turned off) than anything else. M$ probably has a reason for this but to find out what it is, you'll have to ask Bill.

The reason why other projects are not effected or barely effected is because their servers do not suffer from the same stress as a SAH does. If the other projects had a "Cricket graph" you would see that their bandwidth is not constantly pegged at maximum throughput.

T.A.

Profile HAL9000
Volunteer tester
Avatar
Send message
Joined: 11 Sep 99
Posts: 3571
Credit: 98,028,305
RAC: 77,966
United States
Message 1344062 - Posted: 8 Mar 2013, 14:47:35 UTC - in response to Message 1344047.

One probabily "stupid" question, there is not a simple command that could made in the server side that make the job? Or at least eliminate the need of the changes in the windows hosts? My point is, others projects works fine without need to make this ajust in the client side, so that is possible. Is easy to make the ajust in one server than who knows 200K clients?, and sure a lot of users never read the threads so they will not make the ajust at all, besides of those who don´t whant/know who to do.

Maybe you Richard could talk with Matt and see if that is possible. Probabily all we need is a simple change in the configuration on the server side.

Various documentation from Microsoft does state that Windows will use the TCP1323Opts options if the other end requests it. There are two explanations I like.
One comes from a Server 2003 document:
"The default behavior is as follows: do not use the Timestamp and Window Scale options when initiating TCP connections but use them if the TCP peer that is initiating communication includes them in the SYN segment."
The other comes from a Windows CE document:
"By default, this value does not initiate options but provides them if requested."
So it may be possible to enable this option on the servers to have Windows hosts use it once connected.

However Microsoft suggests setting the value to 1 or 3 for better performance.
____________
SETI@home classic workunits: 93,865 CPU time: 863,447 hours

Join the BP6/VP6 User Group today!

Richard Haselgrove
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8275
Credit: 44,954,896
RAC: 13,717
United Kingdom
Message 1344069 - Posted: 8 Mar 2013, 15:37:33 UTC - in response to Message 1344062.

One probabily "stupid" question, there is not a simple command that could made in the server side that make the job? Or at least eliminate the need of the changes in the windows hosts? My point is, others projects works fine without need to make this ajust in the client side, so that is possible. Is easy to make the ajust in one server than who knows 200K clients?, and sure a lot of users never read the threads so they will not make the ajust at all, besides of those who don´t whant/know who to do.

Maybe you Richard could talk with Matt and see if that is possible. Probabily all we need is a simple change in the configuration on the server side.

Various documentation from Microsoft does state that Windows will use the TCP1323Opts options if the other end requests it. There are two explanations I like.
One comes from a Server 2003 document:
"The default behavior is as follows: do not use the Timestamp and Window Scale options when initiating TCP connections but use them if the TCP peer that is initiating communication includes them in the SYN segment."
The other comes from a Windows CE document:
"By default, this value does not initiate options but provides them if requested."
So it may be possible to enable this option on the servers to have Windows hosts use it once connected.

However Microsoft suggests setting the value to 1 or 3 for better performance.

Thanks - those all help to add to our understanding of what's happening.

The trouble is, the servers don't initiate contact with us: it's (I think) always our clients which call the server. [If the servers were to call us, we'd be wading through pages of 'how to' set up port forwarding on every known router on the planet].

So, the "use if requested" behaviour makes most sense for a server - and it seems that the SETI servers have the Linux equivalent already configured.

I don't think there's likely to be any way in which SETI, as a project, can access the client registry on Windows machines and make changes at that low level - and it would probably be roundly criticised as a security risk or a hacking exploit if it attempted any such thing. The one possibility might be to ask BOINC to include it into the BOINC installer, when the user is present and is explicitly giving permission for system changes to be made.

The full text of that final 'Microsoft suggests' document is interesting:

Recommended value:
1 (also consider setting to a value of 3 if high packet loss / retransmits are occurring).

We are (exactly) suffering 'high packet loss / retransmits', so I think we can safely say Microsoft is recommending a value of 3 for SETI users.

I have written - a couple of days ago - to Matt and Eric, to alert them to what's going on (and I followed up with a link to this thread yesterday). My email was more of a courtesy alert that server workload might increase yet again, and a suggestion that - if they were happy the servers could cope - the TCP suggestions could be endorsed and promoted more widely through Technical News - or possibly even via BOINC's 'Notices' mechanism. So far, I've only had an acknowledgement from Eric, which I hope he doesn't mind me quoting:

Yeah, I got it but haven't had time to understand it yet. It's on my radar.

:-D

juan BFB
Volunteer tester
Avatar
Send message
Joined: 16 Mar 07
Posts: 4616
Credit: 233,287,446
RAC: 340,962
Brazil
Message 1344075 - Posted: 8 Mar 2013, 16:15:14 UTC

I understand but my point is probabily less than 10% of the users read the threads and could do that but the rest 90%? probabily will still have high packet loss / retransmits and continue to put more stress on the bandwidth.

Something probabily more easy to so is Matt put a warming on the front page, so anyone who see the page and use windows will know there is a fix to that, maybe in the news? Or by an e-mail to all windows users, i belive that is easy to do.

Just a sugestion.
____________

Profile TRuEQ & TuVaLu
Volunteer tester
Avatar
Send message
Joined: 4 Oct 99
Posts: 326
Credit: 17,069,286
RAC: 16,902
Sweden
Message 1344079 - Posted: 8 Mar 2013, 16:51:51 UTC

Could the windows update people provide a win fix for this next thursday if possible?

And woops all windows machines that runs boinc won't suffer from this anymore.

Profile TRuEQ & TuVaLu
Volunteer tester
Avatar
Send message
Joined: 4 Oct 99
Posts: 326
Credit: 17,069,286
RAC: 16,902
Sweden
Message 1344080 - Posted: 8 Mar 2013, 16:58:07 UTC - in response to Message 1344075.

I understand but my point is probabily less than 10% of the users read the threads and could do that but the rest 90%? probabily will still have high packet loss / retransmits and continue to put more stress on the bandwidth.

Something probabily more easy to so is Matt put a warming on the front page, so anyone who see the page and use windows will know there is a fix to that, maybe in the news? Or by an e-mail to all windows users, i belive that is easy to do.

Just a sugestion.



Alot of years ago I did some tests by increase the packet sizes in server/client configuration level. That help to increase packet size and increased speeds on large files.
More then 10 years ago though...

Maybe that is worth trying here with client/server software if possible today.

Profile Cliff Harding
Volunteer tester
Avatar
Send message
Joined: 18 Aug 99
Posts: 825
Credit: 46,519,116
RAC: 14,978
United States
Message 1344084 - Posted: 8 Mar 2013, 17:20:49 UTC

My network connection is via Verizon's FIOS at 50MPS/25MPS, and is optimized as such according to Verizon, so I was a little concerned about looking into this. I took the chance, bit the bullet and am glad I did. Currently in the process of downloading 110 AP tasks, which started at 11:27 Philly time and have no drops, retries, etc. Speeds range from 4.48 to 6.97. Times are averaging @ 10 min each at 8 files at a time. Will be doing my other machine later today.

Cudos to Cdemers for bringing this to our attention.
____________


I don't buy computers, I build them!!

Richard Haselgrove
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8275
Credit: 44,954,896
RAC: 13,717
United Kingdom
Message 1344085 - Posted: 8 Mar 2013, 17:21:48 UTC
Last modified: 8 Mar 2013, 17:22:59 UTC

OK, now we've had a good laugh, can we keep this thread clear for serious, hard, technical appraisal and constructive feedback, please?

[edit: sorry, not referring to you, Cliff - unfortunate timing there]

msattler
Volunteer tester
Avatar
Send message
Joined: 9 Jul 00
Posts: 37315
Credit: 499,527,234
RAC: 511,949
United States
Message 1344087 - Posted: 8 Mar 2013, 17:28:18 UTC - in response to Message 1344085.
Last modified: 8 Mar 2013, 17:31:04 UTC

OK, now we've had a good laugh, can we keep this thread clear for serious, hard, technical appraisal and constructive feedback, please?

[edit: sorry, not referring to you, Cliff - unfortunate timing there]

Well, I am sure that the option shall not be pushed in the next MS update...LOL.

But, one has to be curious why it was chosen not to enable it by default.
Does anybody know of a downside?
For example, does it limit transmission speeds when one is NOT dealing with a congested network connection?
____________
******************
Crunching Seti, loving all of God's kitties.

I have met a few friends in my life.
Most were cats.

Profile Cliff Harding
Volunteer tester
Avatar
Send message
Joined: 18 Aug 99
Posts: 825
Credit: 46,519,116
RAC: 14,978
United States
Message 1344088 - Posted: 8 Mar 2013, 17:33:09 UTC - in response to Message 1344085.

OK, now we've had a good laugh, can we keep this thread clear for serious, hard, technical appraisal and constructive feedback, please?

[edit: sorry, not referring to you, Cliff - unfortunate timing there]


Apology accepted..

This topic with all of its changes and such started 2 days ago and many have applied the changes to their machines, so the question is -- Has anyone noticed any problem with Synergy, georgem, and vader handling the extra load? The extra load being no drops, retries, etc.
____________


I don't buy computers, I build them!!

Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 . . . 14 · Next

Message boards : Number crunching : Windows TCP Settings - Follow up - Help with server communication

Copyright © 2014 University of California