Perhaps the problem is not with SETI at the moment. A traceroute from the US east coast dies at paix.he.net (198.32.176.20). It could be a Hurricane Electric problem again. Who knows.

I don't know, but i saw similar things about 5 houres ago, when i checked the connection to seti servers from some lookingglass servers around the world - the traceroute packets on the last hopes often cycle around on two or three IPs like a merry-go-round before the reached Berkely - if they reach :-( .
My guess - a router/connection problem.
AND I DON'T WANT TO HEAR SOMETHING ABOUT YELLOW ... ;-)



__W__

Edit: Was something broken by the Earthquake "Magnitude 3.1 - SAN FRANCISCO BAY AREA, CALIFORNIA"
2011 September 29 23:47:54 UTC ? Source: http://earthquake.usgs.gov/earthquakes/recenteqsus/Quakes/nc71655651.html

---

_______________________________________________________________________________

We're baaaaaaaaaaaaaaaaack.

---

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

Woooooooooohoooooooooo! I'm getting tasks. The problem being that for a shorty it's at 13 minutes. The crunches time will be about 45 mins. Has DA put another fix in the works.

Yeah, 93 reported and only 1 downloaded...

That's Great, Vic!!

It gives me hope that someday soon I might be able to u/l and d/l cleanly again. I was able to Update a few mins ago, and that's a Big Improvement.

Lt

Since I still have the flops in my app_info, my work is still fairly close to run time.

---

Well, that didn't last long.
All of a sudden the rigs can't connect again.

---

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

We're baaaaaaaaaaaaaaaaack.

Occasionally.
For a while there i could upload- now it's a case of being able to upoload for a few minuts, then not being able to for 15min+
Won't be able to get any new work till all the previous work has been returned. Could take the rest of the day, unless things improve or die completely again.

---

Grant
Darwin NT

Well, that didn't last long.
All of a sudden the rigs can't connect again.

I was just going to ask all you American cousins to call it a night and allow us Europeans a chance to do some uploading. I've never seen uploading so slow before, 3m:54s to upload one task.

Got 11 uploaded, over a 100 left to do before I can even think of re-filling. If no go will be out of work by lunchtime.

edit] and it does seem like another nosedive on the cricket graphs.

Well, that didn't last long.
All of a sudden the rigs can't connect again.

I was just going to ask all you American cousins to call it a night and allow us Europeans a chance to do some uploading. I've never seen uploading so slow before, 3m:54s to upload one task.

Got 11 uploaded, over a 100 left to do before I can even think of re-filling. If no go will be out of work by lunchtime.

edit] and it does seem like another nosedive on the cricket graphs.

Yup....it's dead, Jim.

---

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

Oh well, It was nice while it lasted :-(

Yep, the Cricket Graph took another nose dive again. :(

Cheers.

---

Comms now back up, well I have uploaded, waiting to see if I can report/request. First attempt failed.

As I type reported ok, but no tasks available.

I'm full as Seti said the following:

1314 SETI@home 9/30/2011 10:37:12 PM This computer has reached a limit on tasks in progress

Congratulations, now plse, suspend comms, and let me get some, my cpu will start going cold in under 1 hour.

I am receiving some new tasks (although not enough to fill my cache). Problem is the estimated computation time for these new tasks. I'm running Lunatics optimized CUDA on my GT240 and the 'shorties' take slightly less than 5 minutes to complete. The new tasks I am receiving have an estimated computation time of only 58 seconds. This probably means they will error out after twice that time.
I know there have been server side changes and I was able to solve similar problems two weeks ago by removing the FLOPS entry from my app_info file.
Now something seems to have changed once again.
Is there anything I can do to prevent the tasks from being aborted because they take too long to process ? I would hate to waste the small number of tasks I do receive ...

Tom

---

I am receiving some new tasks (although not enough to fill my cache). Problem is the estimated computation time for these new tasks. I'm running Lunatics optimized CUDA on my GT240 and the 'shorties' take slightly less than 5 minutes to complete. The new tasks I am receiving have an estimated computation time of only 58 seconds. This probably means they will error out after twice that time.
I know there have been server side changes and I was able to solve similar problems two weeks ago by removing the FLOPS entry from my app_info file.
Now something seems to have changed once again.
Is there anything I can do to prevent the tasks from being aborted because they take too long to process ? I would hate to waste the small number of tasks I do receive ...

Tom

Don't worry. Tasks only error out if they take ten times as long as expected.

The current estimates are, deliberately, five times too short, to avoid reaching that error limit. Just let them run normally. As soon as the first "58 second" task has completed - which will take the normal five minutes - BOINC will realise what's going on and adjust the estimates for the remaining new tasks. You will, temporarily, have a larger cache than you expected, but again - and again deliberately - the quota limit is in place to prevent things getting out of hand.

well, at least I reported everything now, but as no AP's seem to get validated there are more problems on the way I suppose...

The machine I left running last night didn't report anything on it's own, but had to be "helped" this morning.

Still enough work though as I was so lucky to get almost 30 AP's thursday...

---

I am receiving some new tasks (although not enough to fill my cache). Problem is the estimated computation time for these new tasks. I'm running Lunatics optimized CUDA on my GT240 and the 'shorties' take slightly less than 5 minutes to complete. The new tasks I am receiving have an estimated computation time of only 58 seconds. This probably means they will error out after twice that time.
I know there have been server side changes and I was able to solve similar problems two weeks ago by removing the FLOPS entry from my app_info file.
Now something seems to have changed once again.
Is there anything I can do to prevent the tasks from being aborted because they take too long to process ? I would hate to waste the small number of tasks I do receive ...

Tom

sort of similar problem here as I have 1 AP left from when the estimates were made too high. Now this WU has a est. time of 108 hours when it just takes 12 to 13 hours to process on my CPU. At least all the other WU's seem to be "back to normal" now...

---

the 'shorties' take slightly less than 5 minutes to complete. The new tasks I am receiving have an estimated computation time of only 58 seconds.

For me the estimates are all over the place. The DCF is moving around between 0.7 & 1.5. As each GPU tasks complete, their ridiculously long completion times slowly drop, making the almost correct CPU times drop as well. They get down to about half of the actual completion time is when one finally completes & the estimates get bumped up; pushing the GPU task completion times to new heights of ridiculousness.
Hopefully Seti can stay up for the next few days & things will start to settle down.



Although things are still looking bit broken- doesn't look as though AP work is going out. And a lot of the requests for work result in none. Sometimes i get 1 or 2 WUs, occasionally i'll get 20+. But mostly it's "Project has no tasks available".

---

Grant
Darwin NT

Now i'm not getting any response from the Scheduler.

---

Grant
Darwin NT

Everything's still working at the moment....
The kitties are in there scrapping for anything the servers can send.
Not getting a lot, but enough to keep things a bit warmer in the crunching den.

---

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