Posts by TRuEQ & TuVaLu

Since the relocation of the servers, I have noticed a marked improvement in "download and upload" speeds. Before the relocation, the speeds were almost unbareably slow and somewhat "iffy". Now, however, I can see 50 files download and or upload in as little as 45 seconds to one minute. I don't know what the relocation team did in addition to the relocation, but things have improved in a dramatic way. Great job for the relocation team!

I guess it's me living in Sweden.
I expect things to work.
I flew a support note to MS, maybe they can make use of this. Mac and Linux has it default you said, right?

Not every network administrator, and not everyone with responsibility for a secure server, thinks that RFC1323 is universally a good thing: see http://www.forensicswiki.org/wiki/TCP_timestamps.

Would you like your bank's IT manager to reveal their security status on the web?

Each internet server, and each user-server interaction, will have its own needs and sweet spot. As it happens, SETI has a "scientific data integrity" security requirement: that probably comes rather lower than privacy/financial/military/espionage in most people's security ranking. So SETI have - whether consciously or not, I don't know - permitted visitors to use RFC1323 timestamps. And it turns out that SETI also has the particular type of over-congested link where timestamps are useful - so it's a winner for us.

A company like Microsoft will probably make decisions like this in its server division (where most money is made), rather than the consumer division. And they'll know that many of their server products are installed in small businesses by people (like me) who aren't, and don't want to be, security specialists. So, it makes sense for them to ship the products with the fancy and potentially risky features turned off: a company which grows enough to generate enough web traffic to justify optimising the network connection, is likely also to have grown enough to warrant hiring some professional network skills.

From my experience of working with charities in the UK, I'd say that a s501(c) (3) hanging off an academic institution is unlikely to be high up Microsoft's target customer list.

How many windows clients suffer from this and how many knows how to fix it?
I doubt 1%

There are, what, something like a billion copies of Windows in the world?

The vast majority will be on the default networking setting, and will still be working just fine.

A few hundred thousand will be running SETI, and guess what - the vast majority of them will be working just fine, too. My little server downstairs always has enough work for its single CPU core, because it only needs about one WU per day alongside the other projects it crunches.

The only clients you could remotely describe as 'suffering' are the few thousand, possibly a few tens of thousands, who can potentially crunch SETI faster than they can download with the default settings. OK, we can attempt to do something about that - which is what this thread has been about. But don't kid yourself that Microsoft is going to facepalm and recall every copy of Windows sold in the last 15 years.

So, will it be in the next update from Microsoft??

No & there is no reason for the majority of the computers on the planet to enable the setting.
If you need to use it.
Then turn it on.
Else if leave it alone.

So, will it be in the next update from Microsoft??

Have you, or anyone reported it to Microsoft?

Claggy

Anyone considered to use the same settings on the server as the windows clients?
I think linux and mac computors are backward compatible.

I think your answer will be found here.
http://setiathome.berkeley.edu/forum_thread.php?id=71002&postid=1344069

IMO whatever TCP congestion avoidance algorithm is in use is likely showing that "instant BW" effect for each new connection. The cause was already stated, there's more work assigned to be downloaded than can fit through the pipe.

Joe

Wouldnt be possible to throttle the splitters (or the feeder, or the scheduller or whatever is needed) in some way so they dont produce/assign more files to be transfered than the pipes can handle? I know that means less work available to be assigned but it doesnt help to have it assigned if you cant download it... Specially if they fail and need to be retried over and over again wasting a lot of bandwith...

+1

-5

I'd rather have work allocated to download, and do a few retries when i'm around, then not get any work at all.

Better yet would be to fix the problem, not work around it. They've been working around it for years, but the simple fact is we need more bandwidth.

Joseph Davies TechNet article on TCP Receive Window Auto-Tuning as implemented in Win Vista and later also describes how XP (and Win2k) handled RWIN. That's useful for deciding whether the window scaling option is needed. I'm on dial up so I'll never need RWIN larger than 65536 bytes, but I did enable the timestamps feature on the theory that the sooner the download servers know I have a slow connection the better. None of my few downloads since have broken, though even before the change the majority completed in one attempt.

The additional timestamps header is 10 bytes, but headers are always padded to a mutiple of 4 bytes so the cost is 12 bytes. The tradeoff is that when a download breaks for an HTTP error, BOINC backs off 5k bytes when resuming the transfer to wipe any HTML error information which would otherwise corrupt the download. So doing what we can to ensure no breaks is well worthwhile IMO.

Joe

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.

After uninstalling BM again after have used .52 I now have a working .28

And I do get ap's to crunch.
Better speed then before. Still get stalled transfers though.

But with SIV auto retry on.
Transfer timeouts set to 60 in cc_config.xml
and <max_file_xfers_per_project>20<
and the use of .21 in HOSTS file

I get them....

finally

Only running seti ap as gpu project.

4 tasks in 2 gpu's and a cache set for 10 days with 9 extra days.

scheduler req says not requesting new tasks.....

ehhh

4 tasks for 19 days of cache.....

anyone has a trick for how to make Boinc try to fill it's cache when running seti??

Newer boinc versions up to .52 does not do the trick.
I run .28

boinc only reqz work after last task is done...

Try setting the Max additional work buffer to 0.01 days and it should start requesting work.