I do not think bandwidth has anything to do with this since I'm at UC Berkeley.

Have you stopped in to see if they need a hand? Or are you having any problems with a slowdown on the web?

---

PROUD MEMBER OF Team Starfire World BOINC

I wonder if this is something of a self solving condition. A (bad) analogy -- in the current ongoing recession, unemployment numbers seem to be getting better -- as an increasing number of people despair of getting work and no longer look for work. Here, in current ongoing data flow recession, perhaps eventually the numbers will seem to get better as an increasing number of people despair of the system running properly and efficiently and detatch from SETI and either uninstall BOINC or move on to projects perhaps a bit less problematic.

---

Consensus, backed by source code, is that it represents the filling of a local buffer.

Yes, never trust the source code ;-) Bottom line, call it a visual layer of re-direction that they could instrument off of for the sake of some Warm-n-Fuzzy UI re-assurance.

However, we here at SETI are blessed by small upload file sizes:

A lot of us have said the same things (it's not the size of the upload file, it's that the back end is mercilessly being hammered and has other woes as well), and then drill down on some of the subtle nuances. In this instance, it's why those In-Progress UL files that indicate "100%" are back at square zero on the next go round. There is defensive code in the progress bar which actually stops the bar at 100% --> because of a situation with a header <-- but ahhhh, it would set it to 100% under any circumstance where bytes sent EEXCEED the size of the file to begin with. So on a hunch, I was looking for a situation where a RESEND of the buffer may have come back up the pipeline, thus the same buffer gets counted twice (ergo, without that defensive code, progress might go up to ++600% before failing). Alas, I didn't find a quick smoking gun, sluething it got complex quickly, so I left it as it was ;-)

I do not think bandwidth has anything to do with this since I'm at UC Berkeley.

Have you stopped in to see if they need a hand? Or are you having any problems with a slowdown on the web?

and the fact that data transfers don't go though the campus network.

---

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

In situations such as the current one, why don't they just disable all the splitters and let the output queue drain (assuming it is able to). I don't remember the interdependencies of the boinc system, but surely that must serve to reduce the loading while they work on the problem.

I suppose if the servers were organized for this scenario, they could even shut down the power on one or more of them, or re-task them for debugging.

Or, although this may take more effort in the long run, just turn off the MB splitters. That should reduce the bandwidth loading at least.

Yes, people won't be happy if they can't sustain their RAC. But do I really need to mention how silly that objective is (in real life). And they will return when the system is fully up again because we are all addicted to this project (why else would you be reading these boards?).

(And turn off the message boards for a while; hang a big sign out saying "Gone Fishing" or some such.)

2/19/2010 11:05:59 AM SETI@home Reporting 237 completed tasks, not requesting new tasks
2/19/2010 11:06:21 AM Project communication failed: attempting access to reference site
2/19/2010 11:06:23 AM Internet access OK - project servers may be temporarily down.

Still waiting, hopefully this will all be fixed by tonight.

I have had some uploaded but now the schedular is causing trouble with either getting internal server error or the old project servers may be down message. ON this machine I have one left to do which makes four to upload even though two are at 100% and I have got finished uploading message in my message board. So will do another BOINC project whilst this is sorted out.

---

I have another task about to complete in the next 10 minutes, I'll let you know how the upload/report goes. Finally I have nothing in my upload or report queue.

Nope, multiple retry attempts on the upload finally went thru, but I now have 4 tasks ready to report again.

---

"Life is a tragedy for those who feel, and a comedy for those who think."

"I never get into an argument that I cannot win."

Duplicate post removed.

---

"Life is a tragedy for those who feel, and a comedy for those who think."

"I never get into an argument that I cannot win."

Cricket graph is flatlining - hopefully it's a sign of some affirmative action on the part of staff, and not an indication of more problems.

Also just noticed that Thumper and the primary science database are off line. Possibly related?

Just confirms the horrible suspicion I've had all along: SETI is just here for the science, not to keep us credit-hounds happy.

---

Also just noticed that Thumper and the primary science database are off line. Possibly related?

Just confirms the horrible suspicion I've had all along: SETI is just here for the science, not to keep us credit-hounds happy.

Thats a + in my book, maybe someone realizes something is wrong, or we killed it.

---

Official Abuser of Boinc Buttons...
And no good credit hound!

Here's another observation, with this outage confirming previous observations: a BOINC upload seems to have a greater chance of success if it's a newly-finished task, than if it's an old one which has tried several times before.

That's something i've noticed as well.

---

Grant
Darwin NT

Oooooops... New strategy is needed. I just lost about 100 completed jobs because they wouldn't and still haven't uploaded.
Oh well. I guess it's back to letting BOINC handle it all.

Let them upload, and cross your fingers. The odds are good that you'll get them in before the work can be reissued, crunched and returned -- and you will get credit.

---

Here's another observation, with this outage confirming previous observations: a BOINC upload seems to have a greater chance of success if it's a newly-finished task, than if it's an old one which has tried several times before.

That's something i've noticed as well.

Is that just an artifact of the current random success of uploads, plus backing off of re-sends? For several days I had about 5 pending uploads hanging around, and completed about 10 a day. That means in any given time period I had twice as many new completions as old pendings. If they all go through with equal probability, I would expect to see twice as many successful uploads of new tasks per time interval than of old pending transfers.

I think the longer the pendings stay around, the longer Task Manager backs off the time between attempted re-sends, which would also tend to make the pendings look slower and slower.

---

All my uploads went through within the last 18 hours, all without me pressing a button. BOINC did it's job and I'm happy.

---

All my uploads went through within the last 18 hours, all without me pressing a button. BOINC did it's job and I'm happy.

What about your reports? I have all my uploads out of the way (without intervention), but my "ready to report" list is growing.

---

"Life is a tragedy for those who feel, and a comedy for those who think."

"I never get into an argument that I cannot win."

All my uploads went through within the last 18 hours, all without me pressing a button. BOINC did it's job and I'm happy.

What about your reports? I have all my uploads out of the way (without intervention), but my "ready to report" list is growing.

The ones from last night are gone. I have new downloads that have finished and uploaded, but are still waiting to report.

[Edit] Hold on, upon double-checking my logs, these are the same ones from last night still trying to report.

---

Here's another observation, with this outage confirming previous observations: a BOINC upload seems to have a greater chance of success if it's a newly-finished task, than if it's an old one which has tried several times before.

That's something i've noticed as well.

Is that just an artifact of the current random success of uploads, plus backing off of re-sends? For several days I had about 5 pending uploads hanging around, and completed about 10 a day. That means in any given time period I had twice as many new completions as old pendings. If they all go through with equal probability, I would expect to see twice as many successful uploads of new tasks per time interval than of old pending transfers.

I think the longer the pendings stay around, the longer Task Manager backs off the time between attempted re-sends, which would also tend to make the pendings look slower and slower.

Nope.

As Richard posted older stuck uploads take more retries before they finally go through- i've noticed this whenever there's been a big backlog of uploads. After a lot of button abuse i was able to get all of my uploads to go through, and the oldest ones in the queue were the last ones to eventually upload; and they took a lot of manual re-tries on my part.

Now, uploads are going through without manual intervention, but it's taking as many as 12 retries before that happens, and i've noticed the upload speeds are often [i]less[i/] than 1kB/s. For me it's usually around 30kB/s.

---

Grant
Darwin NT

Thought this would be over by now........


Watch this a couple of dozen times.....and if that don't work,


Stuff that in your Gorilla.

---

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