Windows TCP Settings - Follow up - Help with server communication

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

To post messages, you must log in.

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

AuthorMessage
Cosmic_Ocean
Avatar

Send message
Joined: 23 Dec 00
Posts: 3027
Credit: 13,516,867
RAC: 13
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:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)
ID: 1344017 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
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

ID: 1344019 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13715
Credit: 208,696,464
RAC: 304
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
ID: 1344021 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
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.
ID: 1344029 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
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.
ID: 1344039 · Report as offensive
Terror Australis
Volunteer tester

Send message
Joined: 14 Feb 04
Posts: 1817
Credit: 262,693,308
RAC: 44
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
ID: 1344045 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
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)
ID: 1344046 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
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.
ID: 1344047 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
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.

"Freedom is just Chaos, with better lighting." Alan Dean Foster

ID: 1344054 · Report as offensive
Terror Australis
Volunteer tester

Send message
Joined: 14 Feb 04
Posts: 1817
Credit: 262,693,308
RAC: 44
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.
ID: 1344058 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
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 [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 1344062 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
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
ID: 1344069 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
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.
ID: 1344075 · Report as offensive
Profile TRuEQ & TuVaLu
Volunteer tester
Avatar

Send message
Joined: 4 Oct 99
Posts: 505
Credit: 69,523,653
RAC: 10
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.
ID: 1344079 · Report as offensive
Profile TRuEQ & TuVaLu
Volunteer tester
Avatar

Send message
Joined: 4 Oct 99
Posts: 505
Credit: 69,523,653
RAC: 10
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.

ID: 1344080 · Report as offensive
Profile Cliff Harding
Volunteer tester
Avatar

Send message
Joined: 18 Aug 99
Posts: 1432
Credit: 110,967,840
RAC: 67
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!!
ID: 1344084 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
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]
ID: 1344085 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
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?
"Freedom is just Chaos, with better lighting." Alan Dean Foster

ID: 1344087 · Report as offensive
Profile Cliff Harding
Volunteer tester
Avatar

Send message
Joined: 18 Aug 99
Posts: 1432
Credit: 110,967,840
RAC: 67
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!!
ID: 1344088 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1344094 - Posted: 8 Mar 2013, 17:58:43 UTC - in response to Message 1344088.  
Last modified: 8 Mar 2013, 18:01:47 UTC

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.

Well, at risk of invoking the curse of the yellow fluffy thing, I've had a scout round Cricket and setistats.

The only bad thing on either set of graphs (that I can see) is the falling-off in the number of AP tasks ready to send over the last 9 hours or so - but it's OK, it's just that we've finished splitting all the current tapes on the SSP. And people have obviously been collecting them, so that's actually a good thing.

Downloads were obviously in extended backoff during this week's maintenance (just before this thread started), because we never dipped throughout the whole outage. It will be interesting to see next week whether we've had enough readers to make a difference next time round.

That's why I included Matt in my 'heads up' email, in case he saw something bad on the server and wanted to call us off. But I'd say, so far, it's all looking good.
ID: 1344094 · Report as offensive
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 . . . 14 · Next

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


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.