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)

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

---

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

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.

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.

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

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)

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.

---

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.

---

"Time is simply the mechanism that keeps everything from happening all at once."

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.

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[

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

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.

---

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.

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.

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!!

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]

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?

---

"Time is simply the mechanism that keeps everything from happening all at once."

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!!

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.