Boring is good. Just want the Gods of reliability now.

LOl....and higher limits would be a joy too.

---

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

Boring is good. Just want the Gods of reliability now.

LOl....and higher limits would be a joy too.

+10^100

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

And sort out the DCF problem.

---

Grant
Darwin NT

Crickets maxed out again!!
Not sure if it's due to AP's,or
Marks return to the message boards.;)

Welcome back Mark.

john 3760

---

Crickets maxed out again!!
Not sure if it's due to AP's,or
Marks return to the message boards.;)

Welcome back Mark.

john 3760

LOL....I don't think even I post quite enough to boost the ol' Crickets.

---

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

Looks like the stuck tape is still blocking the splitters after I reported it in the last problem thread before this one. Looks like it has been blocking 2-3 MB splitters for over one week. It needs to be fixed.

---

Scheduler fail.

Just when there were hundreds of APs accumulating :@

---

Scheduler requests from all 5 boxes are failing with http errors.

Uploads are still going through Ok.

The blue line on the Crickets has taken a nose dive too.

T.A.

Scheduler requests from all 5 boxes are failing with http errors.

Uploads are still going through Ok.

The blue line on the Crickets has taken a nose dive too.

T.A.

Up again now...

---

For those who haven't noticed.. you should have a non-zero "number of completed tasks" on your application details for each host now. I asked a question through the back channels and it ended up being a simple PHP fix. Many thanks to those involved on that one.

I was somewhat surprised at how many tasks my single-core machine has done. Then I got a crazy idea.. let's go look at mark's computers.. pick the one with the highest RAC.. wow that's a lot of completed tasks.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

The replica databsse server is disabled,yet it is 0 seconds

behind the master . How can that be ?


Something is up

john3760

---

The replica databsse server is disabled,yet it is 0 seconds

behind the master . How can that be ?


Something is up

Last status was '0' when it was disabled (by staff)??

Did you happen to notice the time since last update (not the status page time, the "As of" 'm' or 'h' displayed to the right of the '0') ??



But, what a diff 5 hrs makes...

I see the replica 50k secs behind now and losing ground steadily.

Maybe Jocelyn has been assigned some extra duties??

Lt

Looks like the stuck tape is still blocking the splitters after I reported it in the last problem thread before this one. Looks like it has been blocking 2-3 MB splitters for over one week. It needs to be fixed.

Has anyone messaged DA or Jeff to notify them that tape 01oc11aa is stuck?

---

Has anyone messaged DA or Jeff to notify them that tape 01oc11aa is stuck?

You think they dosen't watching status page? :) I'm sure they well known of the problem, but no wonder of it because of no serious happened and three of MB-splitters are enough, even for shortie storm...

---

Well, I don't care HOW many splitters are running....I can tell you this.
My top rig is losing cache steadily. And if I am losing cache, a lot of other rigs are as well. Even though server status shows over 200k WUs ready to send, the scheduler/feeder combo is not getting the job done. Otherwise, bandwidth would be saturated right now.

Something is not happy in serverland right now.

---

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

I'm still bouncing off the limits here. :(

Cheers.

---

Well, I don't care HOW many splitters are running....I can tell you this.
My top rig is losing cache steadily. And if I am losing cache, a lot of other rigs are as well. Even though server status shows over 200k WUs ready to send, the scheduler/feeder combo is not getting the job done. Otherwise, bandwidth would be saturated right now.

Something is not happy in serverland right now.

Mine is a bit slower than yours, I am just about holding cache when running on regular WU's but when I give it a nudge and it starts spitting out any shorties it has accumilated in the last 24 hrs cache levels will drop and only very slowly raise when its finnished shorty bashing.

---

Kevin

Even though server status shows over 200k WUs ready to send, the scheduler/feeder combo is not getting the job done. Otherwise, bandwidth would be saturated right now.

if the server status page is saying :

Data Distribution State SETI@home #

Results ready to send : 200,711

and my BOINC Manager says:

2012-01-26 05:08:10 | SETI@home | Sending scheduler request: To fetch work.
2012-01-26 05:08:10 | SETI@home | Reporting 1 completed tasks, requesting new tasks for CPU
2012-01-26 05:08:12 | SETI@home | Scheduler request completed: got 0 new tasks
2012-01-26 05:08:12 | SETI@home | Project has no tasks available

then certainly one of these 2 or a server between both has a very long nose ^^

That's just that the feeder (up to 100 tasks) was empty when the request got in. A few seconds later it would have restocked with fresh 100 tasks and you'd have gotten some.
If we are still sending out a lot of VHAR, each request needs more tasks to get the same amount of preocessing time as if it were mid AR, so the feeder is empty most of the time, making it harder to get tasks assigned. and because everybody is getting a lot of tasks (when you get them) they are horribly hard to get down as well.
Shorties storms don't make for happy servers.

Even though server status shows over 200k WUs ready to send, the scheduler/feeder combo is not getting the job done. Otherwise, bandwidth would be saturated right now.

if the server status page is saying :

Data Distribution State SETI@home #

Results ready to send : 200,711

and my BOINC Manager says:

2012-01-26 05:08:10 | SETI@home | Sending scheduler request: To fetch work.
2012-01-26 05:08:10 | SETI@home | Reporting 1 completed tasks, requesting new tasks for CPU
2012-01-26 05:08:12 | SETI@home | Scheduler request completed: got 0 new tasks
2012-01-26 05:08:12 | SETI@home | Project has no tasks available

then certainly one of these 2 or a server between both has a very long nose ^^

That's just that the feeder (up to 100 tasks) was empty when the request got in. A few seconds later it would have restocked with fresh 100 tasks and you'd have gotten some.
If we are still sending out a lot of VHAR, each request needs more tasks to get the same amount of preocessing time as if it were mid AR, so the feeder is empty most of the time, making it harder to get tasks assigned. and because everybody is getting a lot of tasks (when you get them) they are horribly hard to get down as well.
Shorties storms don't make for happy servers.

You are missing my original point.....(now obscured since AP is filling the pipe again).
If the feeder and scheduler are working together properly, they are fully capable of saturating the bandwidth with MB tasks only, and that was nowhere near happening. And current MB work being issued does not appear to be a shorty storm anyway.

---

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

You are missing my original point.....(now obscured since AP is filling the pipe again).
If the feeder and scheduler are working together properly, they are fully capable of saturating the bandwidth with MB tasks only, and that was nowhere near happening. And current MB work being issued does not appear to be a shorty storm anyway.

Oh, I'm sorry, I just wanted to put across that 'no tasks available' with ready to send high is empty feeder, I didn't check SSP or cricket.

Why the feeder is empty is a different issue and yes, if people have trouble getting tasks when the bandwidth is not maxxed that points at more severe problems than just being unable to keep up with demand.