Something just doesn't add up right...

Results ready to send 183,652 1,640 9m
Current result creation rate 27.8027/sec 0.2383/sec 5m

7/5/2010 12:40:16 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:40:20 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:40:20 PM SETI@home Message from server: Project has no tasks available
7/5/2010 12:40:36 PM SETI@home Sending scheduler request: To fetch work.
7/5/2010 12:40:36 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:40:43 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:40:43 PM SETI@home Message from server: Project has no tasks available
7/5/2010 12:40:58 PM SETI@home Sending scheduler request: To fetch work.
7/5/2010 12:40:58 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:41:07 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:41:07 PM SETI@home Message from server: Project has no tasks available

---

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

I have downloaded some WUS just checked and I have got client detached when I have not is there a problem?

---

Something just doesn't add up right...

Results ready to send 183,652 1,640 9m
Current result creation rate 27.8027/sec 0.2383/sec 5m

7/5/2010 12:40:16 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:40:20 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:40:20 PM SETI@home Message from server: Project has no tasks available
7/5/2010 12:40:36 PM SETI@home Sending scheduler request: To fetch work.
7/5/2010 12:40:36 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:40:43 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:40:43 PM SETI@home Message from server: Project has no tasks available
7/5/2010 12:40:58 PM SETI@home Sending scheduler request: To fetch work.
7/5/2010 12:40:58 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:41:07 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:41:07 PM SETI@home Message from server: Project has no tasks available

Hiamps buddy.....this has been discussed sooooooooo many times here before. Surprised you have never caught it.

There are lots of WUs ready to send, but they only get loaded into the feeder one batch at a time. And are being sent out as fast as the bandwidth will allow. Then the feeder has to be refilled. When you connect and the feeder is between cycles, you get the no tasks available message. You just have to happen to connect at the moment that the feeder has just been refilled to get some for your rig.

---

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

Something just doesn't add up right...

Results ready to send 183,652 1,640 9m
Current result creation rate 27.8027/sec 0.2383/sec 5m

Something about those Results ready to send, are send to the download servers at a rate where it can't keep up with demand and therefor are empty at times.

I think the status for that is missing, I think be course it changes so quick all the time it wouldn't make sense showing it.

(This is my attempt on explaning something I know just about nothing about :) )

Okay, I tried reading through the past 50 posts and just skipped to the end. I suppose since I'm running AP-only, I could possibly provide some insight to those spikes. I was able to very rarely get work (0 and 1 tasks) during the low periods, but during the spikes is when I was able to get three new WUs at a time, and could just about get one every time I asked for one. The Catch-22 is since the bandwidth is maxed, there are HTTP errors and slow download rates, so BOINC won't ask for new work until the downloads are actually in progress instead of "connect failed."

So it's possible that those spikes were in fact AP distribution since it was a lot easier to get them during the spikes.

---

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

Something just doesn't add up right...

Results ready to send 183,652 1,640 9m
Current result creation rate 27.8027/sec 0.2383/sec 5m

7/5/2010 12:40:16 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:40:20 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:40:20 PM SETI@home Message from server: Project has no tasks available
7/5/2010 12:40:36 PM SETI@home Sending scheduler request: To fetch work.
7/5/2010 12:40:36 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:40:43 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:40:43 PM SETI@home Message from server: Project has no tasks available
7/5/2010 12:40:58 PM SETI@home Sending scheduler request: To fetch work.
7/5/2010 12:40:58 PM SETI@home Requesting new tasks for GPU
7/5/2010 12:41:07 PM SETI@home Scheduler request completed: got 0 new tasks
7/5/2010 12:41:07 PM SETI@home Message from server: Project has no tasks available

Hiamps buddy.....this has been discussed sooooooooo many times here before. Surprised you have never caught it.

There are lots of WUs ready to send, but they only get loaded into the feeder one batch at a time. And are being sent out as fast as the bandwidth will allow. Then the feeder has to be refilled. When you connect and the feeder is between cycles, you get the no tasks available message. You just have to happen to connect at the moment that the feeder has just been refilled to get some for your rig.

Went in and reset my DCF for the millionth time and started getting some work.

---

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

Nothing even turned in and once again I am at 99 hours for completion....PLEASE FIX THIS.

EDIT: This time I changed the DCF in old and previous client states also, wonder how long it will last?

---

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

Seems my E8500 host has had a miscommunication and detached itself,
after i abort all the now useless tasks, one of the next communications gives me 46 Ghost Wu's,
was it really a good idea to limit everyone to 20 tasks at a time over the weekend?
now even more hosts need to refill their cache's, making this more likely.

Claggy

Anybody have a clue what the bandwidth cycles on the Cricket Graph are all about? I don't think I have ever seen such a well defined pattern before....

There appears to be correlation with when the splitters are boosting the "Results ready to send" and when they're idle. Compare Scarecrow's graphs, though it's hard to really match the time scales. It's a case where sampling the server status once an hour isn't quite enough to pin down the relationship, but my guess is the high rate download bursts are occurring just after the splitters have stopped for awhile. Or it could just be coincidence...

                                                                 Joe

And "ready to send" doesn't drop to zero when splitters are idle, but bandwidth load drops hugely nevertheless.

My suspicions-
The Ready to Send buffer probably drops quite rapidly when badnwidth is maxed out, then continues to drop gradually once the network traffic drops off till such time as the splitters fire up & top up the buffer; the graphs aren't updated frequently enough to see accurately what's happening.


Extremely wild supposition-
The traffic bursts may be related to odd work request behaviour.
I noticed one or 2 threads where people commented about the client not requesting new work, even though they had less than 20 in their cache. After a while, it does request work & that's when you're getting those bursts in network traffic. Lots of clients running down their buffer below 20 Work Units before requesting more, resulting in short bursts of network traffic.


EDIT- just had a look at the Astropulse graphs. It shows a full Ready to Send buffer, with ups & downs similar to MB, but the slope of the waveform is different.
MB- buffer fills quickly, drains slowly.
AP- buffer fills slowly, but drains quickly.

Looks like the spkies could be very much AP related. Just odd with their fairly consistent frequency.

The spike interval & duration I can't explain any better than above but if you compare the cricket graph with scarecrow's "AP in progress" you can see a beautiful correlation with a ratcheting up of AP in progress every time a data burst occurs. Very pretty!

[/img]

to add insult to injury, there seems to be some internet connectivity problems towards the San Francisco bay area in general (not SETI/Berkeley/etc specific).

This could be compounding errors while downloading and amplifying spikes.

---

Janice

Well the plan seemed to be do a "Soft Start".

Limit the work units to 20 until all the slower hosts had full caches, then increase the limit in steps over a day to 2 and get the big caches full in stages.

But when they opened the tap a bit more, the database crashed. So things were left on trickle feed for the weekend as that was a lot better than being dead in the water with the database down.

Now the tap has been turned on, data has is flowing as fast as the system is able. But for my slower PCs things are worse as the overload means they cant refill their 10 or 20 WU caches at the moment.

And I suspect the guys looking for 500 units are not getting them reliably either.

So now we are just now seeing the congestion that we expected on Friday.

The Gradual Startup was a good plan, hope they can get the bugs worked out of. Separate quota for GPU and CPU would quiet a lot of the Whining from the power crunchers that have been on short rations, and get some work to everyone.

Ian

and now another 17 Ghost Wu's,

Claggy

Nothing even turned in and once again I am at 99 hours for completion....PLEASE FIX THIS.

EDIT: This time I changed the DCF in old and previous client states also, wonder how long it will last?

Well this is the longest my times have stayed normal since this started. Anyone else have the DCF problem it would be cool to know if this helps. I changed the DCF to .2 in client state, client state_old and client state_previous.

---

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

Nothing even turned in and once again I am at 99 hours for completion....PLEASE FIX THIS.

EDIT: This time I changed the DCF in old and previous client states also, wonder how long it will last?

Well this is the longest my times have stayed normal since this started. Anyone else have the DCF problem it would be cool to know if this helps. I changed the DCF to .2 in client state, client state_old and client state_previous.

I have never edited the prev file...I didn't think Boinc referred to it except in the case of some sort of corruption or crash of the working file.

---

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

Nothing even turned in and once again I am at 99 hours for completion....PLEASE FIX THIS.

EDIT: This time I changed the DCF in old and previous client states also, wonder how long it will last?

Well this is the longest my times have stayed normal since this started. Anyone else have the DCF problem it would be cool to know if this helps. I changed the DCF to .2 in client state, client state_old and client state_previous.

I have never edited the prev file...I didn't think Boinc referred to it except in the case of some sort of corruption or crash of the working file.

Neither had I, but I was desperate...LOL I just stole 60 non Vlars from my CPU with the rescheduler and my times stayed stable. Not sure which folder did it or if I am just lucky right now, thats why I am hoping someone else will try.

---

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

and another 56 Ghosts,

Claggy

and another 56 Ghosts,

Claggy

How do you tell if they are ghosts?

---

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

Nothing even turned in and once again I am at 99 hours for completion....PLEASE FIX THIS.

EDIT: This time I changed the DCF in old and previous client states also, wonder how long it will last?

Well this is the longest my times have stayed normal since this started. Anyone else have the DCF problem it would be cool to know if this helps. I changed the DCF to .2 in client state, client state_old and client state_previous.

I have never edited the prev file...I didn't think Boinc referred to it except in the case of some sort of corruption or crash of the working file.

Neither had I, but I was desperate...LOL I just stole 60 non Vlars from my CPU with the rescheduler and my times stayed stable. Not sure which folder did it or if I am just lucky right now, thats why I am hoping someone else will try.

Well never mind I was just lucky for a bit....back to 88 hours...

EDIT: I think a VLar did me in, as I don't have any errors but noticed the last batch of downloads for GPU was all Vlars that wanted to start NOW!

---

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

and another 56 Ghosts,

Claggy

How do you tell if they are ghosts?

06/07/2010 01:26:47 SETI@home update requested by user
06/07/2010 01:26:51 SETI@home [sched_op_debug] Starting scheduler request
06/07/2010 01:26:51 SETI@home Sending scheduler request: Requested by user.
06/07/2010 01:26:51 SETI@home Requesting new tasks for GPU
06/07/2010 01:26:51 SETI@home [sched_op_debug] CPU work request: 0.00 seconds; 0.00 CPUs
06/07/2010 01:26:51 SETI@home [sched_op_debug] NVIDIA GPU work request: 295929.11 seconds; 0.00 GPUs
06/07/2010 01:26:51 SETI@home [sched_op_debug] ATI GPU work request: 309850.73 seconds; 0.00 GPUs
06/07/2010 01:28:35 Project communication failed: attempting access to reference site
06/07/2010 01:28:35 SETI@home Scheduler request failed: Transferred a partial file
06/07/2010 01:28:35 SETI@home [sched_op_debug] Deferring communication for 1 min 0 sec
06/07/2010 01:28:35 SETI@home [sched_op_debug] Reason: Scheduler request failed
06/07/2010 01:28:36 Internet access OK - project servers may be temporarily down.
06/07/2010 01:28:43 SETI@home work fetch suspended by user

and i've got fresh tasks listed in my task list at 6 Jul 2010 0:26:51 UTC, but Boinc never got them :-(

Claggy

Just when you think things are getting better:

BOINC asked for about 30 tasks, finally enough to fill my 5 day queue. Two downloaded about 20%, now all say "project back off..."

Oh wait, one came back, up to 51% downloaded!

---