Only thing I can do...no more up or down loads. Try take the pressure off a bit. See what its like tomorrow.

---

Only thing I can do...no more up or down loads. Try take the pressure off a bit. See what its like tomorrow.

Fair point and other projects can take up the idle slack until Berkeley can troubleshoot whatever the bottleneck is.

But then, if upload/download is a problem, the Boinc exponential back-off for failed transfers should do this for you automatically.

But then again #2:
2005-08-07 21:31:00 [SETI@home] Requesting 757 seconds of work
2005-08-07 21:31:00 [SETI@home] Sending request to scheduler: http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2005-08-07 21:31:03 [SETI@home] Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2005-08-07 21:31:03 [SETI@home] Started download of 16oc03aa.27639.8850.878414.23
2005-08-07 21:32:30 [SETI@home] Finished download of 16oc03aa.27639.8850.878414.23
2005-08-07 21:32:30 [SETI@home] Throughput 4171 bytes/sec

All ok here for my meagre trickle of WUs.

Regards,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Only thing I can do...no more up or down loads. Try take the pressure off a bit. See what its like tomorrow.

Fair point and other projects can take up the idle slack until Berkeley can troubleshoot whatever the bottleneck is.

But then, if upload/download is a problem, the Boinc exponential back-off for failed transfers should do this for you automatically.

But then again #2:
2005-08-07 21:31:00 [SETI@home] Requesting 757 seconds of work
2005-08-07 21:31:00 [SETI@home] Sending request to scheduler: http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2005-08-07 21:31:03 [SETI@home] Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2005-08-07 21:31:03 [SETI@home] Started download of 16oc03aa.27639.8850.878414.23
2005-08-07 21:32:30 [SETI@home] Finished download of 16oc03aa.27639.8850.878414.23
2005-08-07 21:32:30 [SETI@home] Throughput 4171 bytes/sec

All ok here for my meagre trickle of WUs.

Regards,
Martin

I was just trying to stop sending back results so it has less to do and not ask for work either. Its only a minute amount of less pressure but its the only thing I can do. Cannot think of anything else tbh.

---

Good move Ian :)

If everyone did this, it would certainly help ease the situation. I normally stock up on WUs before a planned outage and then disable network access until things have caught up afterwards. Experience has taught me this is a wise thing to do.

As a side note, it would appear, to me at least, that they handled the rush after the outage a little better this time than before indicating that things are improving.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

Good move Ian :)

... I normally stock up on WUs before a planned outage and then disable network access until things have caught up afterwards. Experience has taught me this is a wise thing to do ...

I tried this once, but overdid the stocking-up, and ended up with some that barely made the deadline. I think you need to be very careful if you're going to try this.

---

I do the same...

I get extra WU's before the outage, and try and wait till things settle down after.

If I am running short,I will connect.

PC1 has 3-4 days Wu's cached (30 ish).
PC2 also has 3-4 days (70 ish)..

I can easily wait 2-3 days...

Both PC's currently "net access suspended"...

All Wu's are due in well after I will run out...

I back off. Only two hosts, but if all the other users out there did the same, who did not need to connect "this very second" that had work for a while, It might help.

it results in a very satisfing "dump" when all the Credit finally gets granted....

---

Foamy is "Lord and Master".
(Oh, + some Classic WUs too.)

it results in a very satisfing "dump" when all the Credit finally gets granted....

Well, I always enjoy a very satisfying dump (best hour of the day) (apologies for lowering the tone... it had to be said)

But seriously, it is nice to see the credits eventually granted in one go (I have about 4 days worth waiting at the mo)

---

I have suspended BOINC seti until after the migration from classic seti is complete and things have settled down. Until the migration is complete and they have devoted all the resources presently being used for classic and applied them to BOINC seti, I fear we are stuck in a futile never ending quest trying to please both classic and boinc seti users. I wish they would just bite the bullet and close classic, deal with the problems, and eventually move on.

---

Since I'm kinda the FNG (friggin' new guy) around here, I've only seen the
trends over the last month or so. Has seti ever let things run down to a
point where all processes are base lined or equalized with other processes?
I'm making an apples to oranges comparison to a customer of ours with a base of servers receiving tons of data to process from a hoard of remote 'sites'. In their case in spite of
(painfully) many hardware swapouts and upgrades the only help when the
servers start to get choked is to throttle the incoming data and let
splitting/processing/deleting of data on the servers catch up. The deletion of files is a huge bottleneck for them. Shutting off the receipt of data can mean several hours, up to a day, of no new data being accepted, and some data being lost. But the overall performance stays high for weeks instead of days until eventually the new data begins to overtake the processing once again. A little creative timing of their 'outages' minimizes the loss of data.

Scarecrow,

The BOINC System is a rapidly moving target. This is all bad or not an issue depending on who is writing the message. The concept of BOINC is very simple. Allow multiple DC projects to be run with a minimal investment of resources. With a framework developed in open source it also means that there is an infrastructure that can be extended as needed by projects.

So, in the last two years (of which I have been a participant for about 18 months) BOINC has been evolving from a simple beta quality application framework on Windows (Command line clients were available for OS-X and Linux) with server side software developed using, for the most part, other open source tools.

With this availability we had, initially, one project that was hosted and live. SETI@Home, shortly after that we started having some of the other projects move into open beta. Now, we are in production mode on 5 projects, with additional applications for several of those projects in testing (CPDN: Sulfur something, SETI@Home: AstroPulse and SETI@Home extended/advanced/or whatever we are going to call it).

However, these new projects, and desired capabilities mean that we are still seeing changes in both the client side and server side. Live stress tests by the SETI@Home team has shown some places where you may have to be careful. At any rate. The system works, we do science, and along the way we are seeing improvements in the system on both ends. Is it perfect? Nope, not yet. Does it work? Yep. Will it continue to evolve? I would bet money on that.

Even better, there are a whole passel of new projects in open testing. Orbit@Home, The Lattice Project, Message@Home, and so on ... heck even Folding@Home has a BOINC Client now. So, if you expect huge amounts of stability ... this is not the place ... but, for all the problems, have you noticed, for the most part, if you just wait ... they go away ...

---

I run Einstein@home and climatepredictor.net with Seti, so i simply reduced the percent of resources to seti so the other two get more time. Seti is still my main reason for running boinc, so i'd like to keep it moving. Figured this might be a good alternative to stoping seti altogether.

---

Chained to the dream they got you searching for, the thin line between entertainment and war...
Zack de la Roche

Since I'm kinda the FNG (friggin' new guy) around here, I've only seen the
trends over the last month or so. Has seti ever let things run down to a
point where all processes are base lined or equalized with other processes?
I'm making an apples to oranges comparison to a customer of ours with a base of servers receiving tons of data to process from a hoard of remote 'sites'. In their case in spite of
(painfully) many hardware swapouts and upgrades the only help when the
servers start to get choked is to throttle the incoming data and let
splitting/processing/deleting of data on the servers catch up. The deletion of files is a huge bottleneck for them. Shutting off the receipt of data can mean several hours, up to a day, of no new data being accepted, and some data being lost. But the overall performance stays high for weeks instead of days until eventually the new data begins to overtake the processing once again. A little creative timing of their 'outages' minimizes the loss of data.

One of the interesting differences between most BOINC projects and most commercial projects is that work, in general, isn't that time sensitive.

Completed work will stay on your hard drive until it is uploaded and reported, so there is no great risk of lost data.

If anything, I think BOINC needs a mechanism to tell clients to slow down after an outage -- reducing the load would let the servers process near the optimal speed and throughput should increase.

---

As to the idea of the original post - me too!

In this case, I've had the network disabled since
the outage began, and just a bit ago (about 48 hours
of outage) turned it back on, and all my dozen or so
results uploaded (no retries or back-offs at all)
and even downloaded a few new units. Being able
to do this is one of the benefits of a right-sized
WU cache. Able to crunch non-stop over an outage,
including the attendant post-outage brou-ha-ha.

So, for my purposes, they seem to have "recovered".
Those results I reported were on 3 different hosts,
so I don't think the relative success of my uploads
was due to hitting at just the right moment.

I know, the program would take care of all of this without
my meddling, by itself, but I decided to play with it
for the heck of it. Just for grins. Maybe I reduced
the size of the automated traffic jam by just a few
retries.

Dave

Good move Ian :)

If everyone did this, it would certainly help ease the situation. I normally stock up on WUs before a planned outage and then disable network access until things have caught up afterwards. Experience has taught me this is a wise thing to do.

As a side note, it would appear, to me at least, that they handled the rush after the outage a little better this time than before indicating that things are improving.

Ned

I'd sure like to know how some of you are able to "stock up" on WUs. I can't get two queued up, let alone a "stock" of them. Please share the knowledge! Thanks!

---

I'd sure like to know how some of you are able to "stock up" on WUs. I can't get two queued up, let alone a "stock" of them. Please share the knowledge! Thanks!

You go to "YOUR ACCOUNT" at the top of the page. Then click on the blue "View or edit general preferences". Then you click on the "Edit Preferences" at the bottom and change the "Connect to network about every" to a number of days like 3 or so. Right now you can use up to 10 days. It will still keep connecting like it does but will increase your cache making it possible to connect further down the road if you had to.

---

Then update your project for the settings to take effect sooner rather than later!

---

I'd sure like to know how some of you are able to "stock up" on WUs. I can't get two queued up, let alone a "stock" of them. Please share the knowledge! Thanks!

You go to "YOUR ACCOUNT" at the top of the page. Then click on the blue "View or edit general preferences". Then you click on the "Edit Preferences" at the bottom and change the "Connect to network about every" to a number of days like 3 or so. Right now you can use up to 10 days. It will still keep connecting like it does but will increase your cache making it possible to connect further down the road if you had to.

THANKS!! I did what you suggested and upped the days to 5 (my son had it set at .1). It immediately downloaded a WU but it only took 1.24 minutes to compute. Still having problems with them uploading. Takes MANY tries before they finally get uploaded. But, since BOINC is still in its infancy, I'll try to be patient! Thanks for the advise.

---

I do the same...
I get extra WU's before the outage, and try and wait till things settle down after.
If I am running short,I will connect.
PC1 has 3-4 days Wu's cached (30 ish).
PC2 also has 3-4 days (70 ish)..
I can easily wait 2-3 days...
Both PC's currently "net access suspended"...
All Wu's are due in well after I will run out...
I back off. Only two hosts, but if all the other users out there did the same, who did not need to connect "this very second" that had work for a while, It might help.
it results in a very satisfing "dump" when all the Credit finally gets granted....

MOST units are not validated for about 7 days, on average, anyway, so a short cache is of no help in the long run. A study was done and this is what came out when people were deciding on how long the cache should be during a previous outage.

---

Well I unsuspended this morning 'cos I thought things were looking up. Hmmmm looks like I was wrong but cannot tell much about what is going on right now. They are suffering for sure is my guess.

---

They must be getting some done as I got a new credit total this afternoon.

---