Server status.....

---

Still no response from the Scheduler.

---

Grant
Darwin NT

Scheduler responds for me. Getting nothing but "no tasks available." What I find sketchy is the ready-to-send queue is building, splitters are steaming right along, but cricket is pretty calm and lots of "no tasks available." Did they drop the feeder cache to something like 10 every 2 seconds?

---

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

Well I'm connecting again and receiving work again so I'm happy.

Cheers.

---

Well I'm connecting again and receiving work again so I'm happy.

Cheers.

Tried it again just then. This time it conected.
Project still has not tasks available though.

---

Grant
Darwin NT

Well I'm connecting again and receiving work again so I'm happy.

Cheers.

Tried it again just then. This time it conected.
Project still has not tasks available though.

EDIT- just tried it on the other machine & no response fom the Scheduler.

---

Grant
Darwin NT

Well I'm connecting again and receiving work again so I'm happy.

Cheers.

Tried it again just then. This time it conected.
Project still has not tasks available though.

EDIT- just tried it on the other machine & no response fom the Scheduler.

EDIT again- just tried it again & not only got a response but got 30 WUs.

Things really are seriously screwed. Not just the flakey router but the servers as well.

Yet another EDIT- 1st machine got a "server returned nothing(no headers, no data)" response from the Scheduler.
The next time it tried it got a couple of WUs.

---

Grant
Darwin NT

If I was Admin in this situation, I would be completely incoherent. These are times that Sadms live on Cheeto's and Mountain Dew.

Or Kit Kats and Coca Cola (sugar and caffeine mmmmmmmm)

  Team,

    This following messages are typical today...

    10/1/2011 7:40:19 PM | SETI@home | update requested by user
    10/1/2011 7:40:21 PM | SETI@home | Sending scheduler request: Requested by user.
    10/1/2011 7:40:21 PM | SETI@home | Requesting new tasks for NVIDIA GPU
    10/1/2011 7:40:25 PM | SETI@home | Scheduler request completed: got 0 new tasks
    10/1/2011 7:40:25 PM | SETI@home | No tasks sent
    10/1/2011 7:40:25 PM | SETI@home | No tasks are available for SETI@home Enhanced
    10/1/2011 7:40:25 PM | SETI@home | Tasks for CPU are available, but your preferences are set to not accept them


    Jeff

I wonder if that means that there's a lot of VLAR's around, (VLAR's aren't sent to Nvidia GPU's)

Out from 88 units i´ve downloaded over night there was only 6 VLARs.
Most VHARs and a few mid range units.

---

With each crime and every kindness we birth our future.

scheduler attempts are up to flakey. Some go through, others different types of errors/no connection and some go through, sometimes yielding units sometimes not. All in all cache is building slowly, and uploads and downloads are flying through for me.

---

Janice

  Team,

    This following messages are typical today...

    10/1/2011 7:40:19 PM | SETI@home | update requested by user
    10/1/2011 7:40:21 PM | SETI@home | Sending scheduler request: Requested by user.
    10/1/2011 7:40:21 PM | SETI@home | Requesting new tasks for NVIDIA GPU
    10/1/2011 7:40:25 PM | SETI@home | Scheduler request completed: got 0 new tasks
    10/1/2011 7:40:25 PM | SETI@home | No tasks sent
    10/1/2011 7:40:25 PM | SETI@home | No tasks are available for SETI@home Enhanced
    10/1/2011 7:40:25 PM | SETI@home | Tasks for CPU are available, but your preferences are set to not accept them


    Jeff

I wonder if that means that there's a lot of VLAR's around, (VLAR's aren't sent to Nvidia GPU's)

Out from 88 units i´ve downloaded over night there was only 6 VLARs.
Most VHARs and a few mid range units.

I think Jeff should check his project preferences then, and check that SETI@home Enhanced is still selected, then report back,

Claggy

ooh, ohhh - i think their is trouble ahead. I never have seen this values at this level: Results waiting for db purging 10,049,030 MB# 113,856 AP#.
And db_purge.x86_64 on vader is at "Disabled".
How many WUs could be handled by this database?

__W__

---

_______________________________________________________________________________

ooh, ohhh - i think their is trouble ahead. I never have seen this values at this level: Results waiting for db purging 10,049,030 MB# 113,856 AP#.
And db_purge.x86_64 on vader is at "Disabled".
How many WUs could be handled by this database?

__W__

That's a good question. From what I know of databases in general, I doubt we'll hit any problems with the absolute numbers - databases are designed to grow until they fill all the available disk space.

Bur what happens is that they get slower and slower as they get bigger. In particular for SETI, Matt has mentioned in the past then when the database gets too big for key tables (and indexes) to be held in RAM, then the performance is really hammered by having to swap pages at disk I/O speed. I think I'm seeing that already, if I ever look at the full task list for one of my hosts.

ooh, ohhh - i think their is trouble ahead. I never have seen this values at this level: Results waiting for db purging 10,049,030 MB# 113,856 AP#.
And db_purge.x86_64 on vader is at "Disabled".
How many WUs could be handled by this database?

__W__

That's a good question. From what I know of databases in general, I doubt we'll hit any problems with the absolute numbers - databases are designed to grow until they fill all the available disk space.

Bur what happens is that they get slower and slower as they get bigger. In particular for SETI, Matt has mentioned in the past then when the database gets too big for key tables (and indexes) to be held in RAM, then the performance is really hammered by having to swap pages at disk I/O speed. I think I'm seeing that already, if I ever look at the full task list for one of my hosts.

I have noticed the slow response when viewing task lists as well.

---

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

This maybe the reason why some crunchers could not get WUs up to the limits dispite cricket is not at a high level - at least connection to Berkely is now good and fast from my point of view.

__W__

---

_______________________________________________________________________________

So.. I keep hearing about this limit of 50/cpu... my single core machine has 99 in progress and the messages tab says nothing about a limit. Hm. Now it's 100, still no message. Either it's a glitch, or it's because a 10-day cache on this machine is somewhere between 90-110 MBs on average, at least with the weird estimates and most of them being shorties.

I'm keep hitting the limit on 2 PCs. What I don't understand is why BOINC still keep asking for CPU work, just now it has asked for new CPU work 5 times in a row. Wouldn't it be better if it waits until a CPU task is finished before asking for more?

What I don't understand is why BOINC still keep asking for CPU work, just now it has asked for new CPU work 5 times in a row. Wouldn't it be better if it waits until a CPU task is finished before asking for more?

You cache is set to a higher level so Boinc has to ask for more WUs. The 50/400 WUs limit are set at serverside and so Boinc don't "know" about them and can't handle them.

__W__

---

_______________________________________________________________________________

So.. I keep hearing about this limit of 50/cpu... my single core machine has 99 in progress and the messages tab says nothing about a limit. Hm. Now it's 100, still no message. Either it's a glitch, or it's because a 10-day cache on this machine is somewhere between 90-110 MBs on average, at least with the weird estimates and most of them being shorties.

I'm keep hitting the limit on 2 PCs. What I don't understand is why BOINC still keep asking for CPU work, just now it has asked for new CPU work 5 times in a row. Wouldn't it be better if it waits until a CPU task is finished before asking for more?

BOINC hasn't been programmed to take any notice of the reason why no work is issued - even when the reason is stated (it isn't always).

The newer BOINC v6.12.xx are programmed to back off and ask less frequently when no work is forthcoming - but the backoff is reset to zero when a task completes, and BOINC allows time for the just-completed task to upload and be available for reporting before requesting new work. So, its behaviour is quite close to what you're suggesting: if you have reached the quota limit, there's a fair likelyhood that your next scheduler request will be 'report one, get one replacement'.

You, on the other hand, are running BOINC v6.10.58/60 - that version of BOINC simply knows how much work you've said that you'd like to have, and keeps asking 'more, more, more', even when the server is replying 'no, no, no'. If you are concerned about the strain that your repeated fruitless requests are placing on the servers, you could consider upgrading to BOINC v6.12.34, or temporarily reduce you cache size to something which matches the current (temporary) quota limit more closely.

I don't like v6.12.* so I will reduce my cache setting for now :)

BOINC hasn't been programmed to take any notice of the reason why no work is issued - even when the reason is stated (it isn't always).

The newer BOINC v6.12.xx are programmed to back off and ask less frequently when no work is forthcoming - but the backoff is reset to zero when a task completes, and BOINC allows time for the just-completed task to upload and be available for reporting before requesting new work. So, its behaviour is quite close to what you're suggesting: if you have reached the quota limit, there's a fair likelyhood that your next scheduler request will be 'report one, get one replacement'.

You, on the other hand, are running BOINC v6.10.58/60 - that version of BOINC simply knows how much work you've said that you'd like to have, and keeps asking 'more, more, more', even when the server is replying 'no, no, no'. If you are concerned about the strain that your repeated fruitless requests are placing on the servers, you could consider upgrading to BOINC v6.12.34, or temporarily reduce you cache size to something which matches the current (temporary) quota limit more closely.

That's the much more detailed explanation, thanks ;-)
__W__

---

_______________________________________________________________________________