A follow on question:

I switched back to running BOINC 6.10.60 because 1) my downloads were hanging which 2) kicked in the ridiculously long project backoff times in BOINC 7.X.X. The hangups have been largely eliminated by adopting the TCP fix. My transfer rates are glacial, but downloads are now consistent. For those of you running the newer BOINC Windows versions, does the TCP fix help with your backoff situation?

Yes. I run a machine with Windows 7, BOINC (currently) v7.0.58, and two GTX 670 GPUs. I spread the GPUs across multiple projects, so I don't have to download enough SETI to keep them fully occupied - but they can still get through a lot. My first request after the overnight network upgrade outage yielded something like 44 new tasks (IIRC). They just plodded down the line, slow but steady, and I've given up even bothering to check whether they arrived safely. I've never had a stuck queue since I was told about RFC1323 (take a bow, those who tracked it down), which is why I've been so enthusiastic about promoting it.

Can someone tell me more about the security issue with timestamps?

Sorry, parked this in the rush, and never came back to it.

In a word, no. As with many subjects on the internet, when you search for it, you find vastly more pananoid or ignorant questions than you find answers. I don't pretend that my original comment was rigorous, or even necessarily accurate - I was just attempting to provide some counter-examples, to suggest that reporting RFC1323 to Microsoft as if the non-default implementation was a bug was perhaps wide of the mark.

That much I already understood.

The security implication I'd picked up in my reading/research was that some *server operators* - i.e. nothing of what follows is of any concern to home users - were worried that 'black hats' could deduce from the time stamps on TCP packets how long it had been since the server was last rebooted, or even how long since security patches had been applied. If attackers knew or could deduce that a particular security patch was missing, they might be able to use the exploit the patch was designed to block, and get into the server that way.

Apart from not applying to us (if anyone should worry, it's the boyz in the lab), further thinking and reading suggests to me that the theory is bullshit.

Thanks for a clear explanation. I mostly understood it (although I don't think I would be further enlightened by clicking the link), well enough to believe that last sentence.

I now feel comfortable ignoring the issue.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

I've never had a stuck queue since I was told about RFC1323 (take a bow, those who tracked it down),

100% agree!

---

+ 1

---

I've never had a stuck queue since I was told about RFC1323 (take a bow, those who tracked it down),

100% agree!

+1

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

+1 Definetely much more consistant downloads from S@H now, thanks.

---

Worked for me! 11k-15k average now.

works like a charm ! Tried it on 1 PC last night and this morning it DL'ed all and is back to the 200 tasks limit...

---

I have been using the mod on my daily driver (Win 7 64bit) and one of my top crunchers (XP Pro 64bit) since this thread started, and have no negatives to report whatsoever.

Nothing but downloading joy on Seti, and no artifacts noticed on my usual browsing and other activities on the daily driver.

I also recommend the command line route provided by our friend Richard, as it does not require any program download or installation, and does not muck with any settings other than the one required to achieve the desired result.

Nothing but kitty purrs here.

---

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

Positive results on my machine. All downloads now complete in one continuous operation, AP's taking about 30 minutes but no lost connections. The lack of retries alone is a big win all round, good for me and good for the SETI download servers.

I'm running XP and used the command line method suggested by Richard Haselgrove, setting the single variable Tcp1323Opts to 3 to set both windows scaling and timestamps to be ON. No negative effects on any other network activity - and this is a general purpose machine, the one I'm typing this reply on :)

Just thought I let you know cleared my cache at the end of the day, then did Shift Ctrl + Enter and it worked must have used return the first time weird or what.

---

Just wanted to report that all is well here, too, as evidenced by..



Not a single one of those stalled or timed-out.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

A follow on question:

I switched back to running BOINC 6.10.60 because 1) my downloads were hanging which 2) kicked in the ridiculously long project backoff times in BOINC 7.X.X. The hangups have been largely eliminated by adopting the TCP fix. My transfer rates are glacial, but downloads are now consistent. For those of you running the newer BOINC Windows versions, does the TCP fix help with your backoff situation?

Well, in my case of BOINC 6.12.34 it helps for sure, since I applied the fix BOINC decided not to use any backoffs at all, at least not for fole transfers. Looking like that in my log:

22/03/2013 22:47:55 rosetta@home Started download of rb_03_12_36962_70171_h002__synp_aah002_07_05.200_v1_3.gz
22/03/2013 22:54:33 Project communication failed: attempting access to reference site
22/03/2013 22:54:33 rosetta@home Temporarily failed download of rb_03_12_36962_70171_h002__synp_aah002_07_05.200_v1_3.gz: HTTP error
22/03/2013 22:54:35 rosetta@home Started download of rb_03_12_36962_70171_h002__synp_aah002_07_05.200_v1_3.gz
22/03/2013 22:54:38 Internet access OK - project servers may be temporarily down.

A 0-2 second backoff is OK to me.

---

Worked great for me on W7 both 32 and 64 bit.

Had raised the simultaneous download to 8 as Cosmic below. Changed back to default 2 as is no longer needed.

I wonder if everybody making this fix also would go back to 2 would help with congestion?

---

Worked great for me on W7 both 32 and 64 bit.

Had raised the simultaneous download to 8 as Cosmic below. Changed back to default 2 as is no longer needed.

I wonder if everybody making this fix also would go back to 2 would help with congestion?

Actually, mine's set for 10. It is rare that I get more than 1 or 2 at a time anyway. It's mostly just useful for when AP doesn't get split for a few days and then I need to rebuild my cache.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Working great on my 3 windows 8 machines.

No more having to hit the retry , especially on astropulse wu's.

Thanks guys, for the info :)

Richard I just used your command prop on my Win7 and Vista machines.
Thank You. It was easy to do and it works.

I know download speed isnt what this command line is about, But watching my two computers I see that the speed is very consistent. Before I put the command line in Id start off at 10KBps and it would slow to a crawl then go to retry.

Those of you who havent done this yet, It will make a huge differance. Ive had AP retrys on both of my machines that would last days. Now they are allmost gone.

I think you have a winner.

---

[/quote]

Old James

Oh thank you! Download speeds are a blazing 10 Kbps. Instead of 2 Kbps and then the drop off of a very high cliff.

Here is a little addition to the TcpIP-Patch for XP and Server 2003 user.

When you get some errors in the eventviewer (system) like
"EventID 4226: TCP/IP hat das Sicherheitslimit erreicht, ..." or
"EventID 4226: TCP/IP has reached the security limit, ...
first ad a registry DWORD entry at
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
with the name
TcpNumConnections
and the value
hex 0x00fffffe or dec 16777214
second install the patch from this site
http://www.lvllord.de/?lang=de&url=downloads#4226patch

This two things will reverse the changes MS has made in SP2 to limit the distribution of maleware(worms) through limiting the TcpIP connections.

__W__

---

_______________________________________________________________________________

Fantastic. Thank you - it's cured all my download problems at a stroke. I have just downladed 4 days of cache in less than 30 mins with no timeouts or stalls.

Win XP Pro with 4 cores.

Mike Bunce

---