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

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

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

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

I didn't want the server to change the client side when the clients requests work.
More like Set the windows default setting to the linux server as they where before.
Let the servers use the same RFC as the windows clients.

I must be even more "important" as I have never had this problem but upon checking my registries my rigs already had it set (don't ask as I don't know why it was when many others don't).

Cheers.

Maybe because you are using a version of Windows (if Windows it is) that was obtained from a bittorrent site? Some of those have performance tweaks built in, and the timestamp may have been one of them.

No luck there for you buddy as they all have their own OEM disks.

Cheers.

---

Well then, maybe the OEMs tweaked it?

---

Maybe because you are using a version of Windows (if Windows it is) that was obtained from a bittorrent site? Some of those have performance tweaks built in, and the timestamp may have been one of them.

No luck there for you buddy as they all have their own OEM disks.

Cheers.

If you have an OEM disk then it "should" mean that the OS was preinstalled on the computer when you bought it... which leaves room for the assumption that may be the builder has customized it.
(Ive said "should" because I dont know if you did a reinstall since you bought the hosts and also because some small builders do not preinstall the OS or even sell them along with the parts when the customers want to assemble the harware by themselves...)

---

The OEM disks are the standard OEM disks supplied by M$ itself that I get each time I build a new PC so both of you are getting way off the track here.

Cheers.

---

The OEM disks are the standard OEM disks supplied by M$ itself that I get each time I build a new PC so both of you are getting way off the track here.

Cheers.

It is possible some other software you installed, or maybe even NIC driver/software configured the setting for you.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

The OEM disks are the standard OEM disks supplied by M$ itself that I get each time I build a new PC so both of you are getting way off the track here.

Cheers.

It is possible some other software you installed, or maybe even NIC driver/software configured the setting for you.

All things are possible but different hardware/drivers and I can't see that any software that I use can do it, but I'll be updating 1 of the kids' PC's Windows from XP 32bit to 7 64bit shortly so maybe I'll find out what I'm doing differently from others (also totally different hardware/drivers again to the crunchers).

Cheers.

---

Greetings all,

We're having a problem and I need some advice on what to do about it. It pertains to what this thread is all about.

-[ snip ]-

The Tcp1323Opts will only give you a higher throughput benchmark if you were previously having a high rate of packet loss & then have a reduced rate of packet loss afterward.-[ snip ]-

Greetings Hal,

Ok. This is an area of computing that I have not spent any great amount of time in in trying to learn about. -[ snip ]-

Basically yes.
Enabling timestamps is a "fix". If the conditions is fixes don't exist then you are just adding extra data to all of your packets. Sort of like tossing a few bricks in the back of a real wheel drive car in the winter and leaving them there in the summer.

The TCPOptimizer software can change other settings that may speed up or slow down your internet connection. Vendors, such as Dell or HP, may tweak those settings to make them better optimized than the Microsoft defaults. If you used it and things got worse. Restore the previous settings or change back to MS defaults & see how things go.

Another tool I use is a program call Visual Route. It is like running a trace but provides more info.

Greetings Hal,

Ok, we unchecked the Timestamps check box: still low, no change.
We unchecked the Window Scaling check box, which was checked when we first started: still low, no change.

For the life of me, I cannot remember what the speeds were before doing the TCPOptimizer thing on the other i7. On Speedtest.net the pings were averaging 60. I believe my i7 averages around 70. That's nanoseconds... ;)

I will get the 'Visual Route' program and see what we can do with it.
[edit] Ok, maybe not. Cannot afford the program and would not get our money's worth out of it anyway. :( [/edit]

Thanks Hal! :)

Keep on BOINCing...! :)

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

Ok, we unchecked the Timestamps check box: still low, no change.
We unchecked the Window Scaling check box, which was checked when we first started: still low, no change.

If you ran TCP Optimiser & allowed it to make other changes as well as the Timestamp & Scaling ones, then those other chnages are the ones you need to undo.

---

Grant
Darwin NT

Greetings Hal,

Ok, we unchecked the Timestamps check box: still low, no change.
We unchecked the Window Scaling check box, which was checked when we first started: still low, no change.

For the life of me, I cannot remember what the speeds were before doing the TCPOptimizer thing on the other i7. On Speedtest.net the pings were averaging 60. I believe my i7 averages around 70. That's nanoseconds... ;)

I will get the 'Visual Route' program and see what we can do with it.
[edit] Ok, maybe not. Cannot afford the program and would not get our money's worth out of it anyway. :( [/edit]

Thanks Hal! :)

Keep on BOINCing...! :)

The best option is probably to select the "Windows Default" button and apply those settings. Unless you had tweaked any settings yourself before using the program it will set everything back to what it originally was.

TCPOptimizer has an option to backup current settings which I suggest everyone do before applying an changes. If something goes wrong you can go back to your previous settings that way.

Also Visual Route is free to play with for 15 days.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I used Richard's command line to add the registry entry and then edited it from 2 to 3. Made no other changes.

I have been using it on this, my daily driver, since then, and have not had any adverse effects on anything to make me want to turn it back off.
Which one can easily do by simply editing the value back to 0.

But, all is good in kittyland.....

And another round of thanks to cdemers for first posting this fix, and Richard for taking the ball and running with it.

The kitties and I thank you both.

---

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

OK, so now I rebooted all my machines after the Microsoft patch day... here a little summary of what I've got:

1. My old AthlonXP, currently the only machine crunching SETI, is still getting about 3 http errors per WU. Can't say if it would be more without the registry fix. Well, nevermind, it needs just 2-6 WUs per day.

2. My laptop: nothing special, had no real issues before and does not have any now.

3. My desktop: that's the interesting one and the actual reason why I post this. It's running also Rosetta right now, and they are apparently running also into some issues with server/bandwidth load as has been reported by many people over there.
Anyway, the TCP fix improved communication with Rosetta servers quite notably, even the message boards open a lot better, i.e. without some small breaks when loading (sometimes it would even stop loading before I applied the fix). Using a proxy was fixing all Rosetta related issues for me same as it did for SETI downloads, except for it was causing issues with uploads, which were working perfectly without a proxy.
Now comes the interesting part: as soon as I added the dword to the registry BOINC stopped using any backoffs, i.e. if it got http error, it would retry the download instantly after that. No waiting at all. And only on this machine (Win7, BOINC 6.12.34), the other two (WinXP, BOINC 6.10.18) have normal backoffs like before including also the usuall messages in the log (backing of download of...). Here nothing, just instant retry. I mean, I don't want to complain about getting rid of those 6.12-backoffs, but has anybody else noticed that? Or is it just me?


EDIT: downloaded one SETI WU on the Win7 machine, actually to check wether it will still not use any backoffs, but of course I didn't get any http error when I wanted one. It was downloading slow but "nice", i.e. at quite constant speed without any breaks or slow downs. That makes me ask one question: is it possible to check wether Windows is actually using the TCP fix? I mean actually check it, not just look into the registry? Because my AthlonXP host is still behaving like it did before while here there's clear difference.

---

Ok, now here seems to be just a little something that may point to a fix to this from the BOINC or SETI really being needed in the end unless M$ works something out with this setting.

Workunit 1182002265

Cheers.

---

Actually just having a look at some of my oldest pendings, inconclusives and errors (and not so old) on just my Q6600 alone shows a very bad pattern here that looks to be even worse for the servers (particularly the database) then those out there returning errored or invalid work.

A lot of rigs have joined up and were allocated work but then either likely couldn't get the work, or even the app's, to run them (errored out work on newer hardware could also add to this) so those tasks are just timing out because the person just plain gave up plus more of these timeouts are building on top of each other thus staying in the system longer.

I just thought that I should this throw out there as I think this may require some serious consideration or it's only going to get worse around here very quickly.

[edit]And no, a lot of those timeouts were not for AP/VLAR reasons.[/edit]

Cheers.

---

Ok, now here seems to be just a little something that may point to a fix to this from the BOINC or SETI really being needed in the end unless M$ works something out with this setting.

Workunit 1182002265

Cheers.

That error is because of a design decision by Nvidia years ago, search out -12 errors for more info, Or upgrade to x41zc as that design decision has been fixed in that app.

Claggy

Ok, now here seems to be just a little something that may point to a fix to this from the BOINC or SETI really being needed in the end unless M$ works something out with this setting.

Workunit 1182002265

Cheers.

That error is because of a design decision by Nvidia years ago, search out -12 errors for more info, Or upgrade to x41zc as that design decision has been fixed in that app.

Claggy

Sorry Claggy but you missed the point.

Take a look at the still pending w/u. ;-)

Cheers.

---

Ok, now here seems to be just a little something that may point to a fix to this from the BOINC or SETI really being needed in the end unless M$ works something out with this setting.

Workunit 1182002265

Cheers.

That error is because of a design decision by Nvidia years ago, search out -12 errors for more info, Or upgrade to x41zc as that design decision has been fixed in that app.

Claggy

Sorry Claggy but you missed the point.

Take a look at the still pending w/u. ;-)

Cheers.

Yea, it's a host that has only ever completed one Wu (in the 11 days it's been attached), likely it's 200 Wu's will time out, if it tries to compute that Wu it'll get a -12 error too,
if assuming the GPU is Fermi and not a Kepler, in which case it'll error too, anyway it'll all be fixed soon, probably in the next four weeks if things go well.

Claggy

You have it, now multiply that by a very large factor of similar rigs that connect, pickup or get allocated up 100-200 w/u's and then never report them.

I have w/u's that go back quite some time that have gone through this cycle up to 4 times now.

What I'm getting at is I can't see how the databases can't help but not get more bloated by these w/u's spending many more months in the system than is required plus that would also show that the actual number of active users and hosts much lower than indicated too.

Thus I believe that the system is being brought to its knees by this communication floor and very few people come here to find out what's going on.

Cheers.

---