Mine's 15kb

Thanks. That's solve the puzzle.

Something was changed and the servers not handle anymore my large file.

Back to the drawing board. Will remain running with NNT until i think on something.

Thanks again for the help.

No problem.
Wondering, if that was deleted would BOINC just rebuild it on restart? Would think so.

---

I'm looking for this file:

sched_request_setiathome.berkeley.edu

27kB for me.

---

Grant
Darwin NT

Just got 1.

Thought it unusual that it was a _1.

Did a bit of searching and found it was the ghost that I had not bothered to try to recover.

Looks like they have turned something back on again.

---

Kevin

Looks like they have turned something back on again.

It would explain why the Scheduler keeps falling over if they are enabling it for a hour or 2 every few hours.

---

Grant
Darwin NT

Looks like they have turned something back on again.

If would explain why the Scheduler keeps falling over if they are enabling it for a hour or 2 every few hours.

That is exactly is my clue.

Wondering, if that was deleted would BOINC just rebuild it on restart? Would think so.

No it's created each time your host makes a new scheduled call. But is supposed to be a small file like yours.
Because my huge caches my file is a lot bigger. My large file was working fine until something changes the 303 secs delay to 606 this week.
Maybe is related to the ghost recovery subrotine at the server side. Need more digging with less alcohol in my head.

---

Back to the drawing board. Will remain running with NNT until i think on something.

Try NNT and limit the number of reported Results to 25 or so.
cc_config.xml, <options> section
<max_tasks_reported>25</max_tasks_reported>

I've had to limit mine to 75 for ages now to be able to report & get new work. After outages i still often had to use NNT to report.

---

Grant
Darwin NT

Back to the drawing board. Will remain running with NNT until i think on something.

Try NNT and limit the number of reported Results to 25 or so.
cc_config.xml, <options> section
<max_tasks_reported>25</max_tasks_reported>

I've had to limit mine to 75 for ages now to be able to report & get new work. After outages i still often had to use NNT to report.

Thanks for the tip but I can't do that.
Remember due my unique client, what you see is not what it rely is.

My host production is in the range of 50-70 WU each 5 min.
Now with the 10 min interval i'm sending 100-140 WU on each request.

Don't worry until i could find a solution NNT is ok for me.

It's more a question of curiosity, i 'm a curious men. LOL

---

Thanks for the tip but I can't do that.
Remember due my unique client, what you see is not what it rely is.

My host production is in the range of 50-70 WU each 5 min.
Now with the 10 min interval i'm sending 100-140 WU on each request.

Yep, but at least the backlog would be increasing at a lower rate.
And it may be possible to return more per request, just use 25 as a starting point to see if it does allow you to return work.

If it does, you just click Update after each successful request- even at 25 a t time it should still be possible to return work faster than you are completing it (at least until your finger gives out from fatigue).

---

Grant
Darwin NT

Thanks for the tip but I can't do that.
Remember due my unique client, what you see is not what it rely is.

My host production is in the range of 50-70 WU each 5 min.
Now with the 10 min interval i'm sending 100-140 WU on each request.

Does not matter.

Set NNT and restrict max tasks to a low amount and try.

If it works you do not have to wait just hit the update button again.

The wait was only introduced to stop people swamping the server with work requests.

---

Kevin

Thanks for the tip but I can't do that.
Remember due my unique client, what you see is not what it rely is.

My host production is in the range of 50-70 WU each 5 min.
Now with the 10 min interval i'm sending 100-140 WU on each request.

Does not matter.

Set NNT and restrict max tasks to a low amount and try.

If it works you do not have to wait just hit the update button again.

The wait was only introduced to stop people swamping the server with work requests.

Seems to me I remember Richard saying something about the "sweet spot" for max reporting being 64 for Win and 128 for Linux. After a lot of experimenting, I found that to be a good compromise here.

---

Seems to me I remember Richard saying something about the "sweet spot" for max reporting being 64 for Win and 128 for Linux. After a lot of experimenting, I found that to be a good compromise here.

Mine is set to 40, even without setting NNT it used to clear them down after an outrage - which usually ended just after I left for work.

---

Kevin

...
05/04/2020 00:39:33 | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
05/04/2020 00:39:36 | SETI@home | Scheduler request completed: got 75 new tasks                                    <-- !!!!!!
...

:O

. . You should buy a lottery ticket :)

Stephen

:)

[quote]
05/04/2020 00:39:33 | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
05/04/2020 00:39:36 | SETI@home | Scheduler request completed: got 75 new tasks <-- !!!!!!
...
[/code]
Congrats you win the #1 prize.

About my problem.
Set the WU reported to 128 and allow new tasks. As suggested. Thanks
Is working for now. Lets see what happening at the end of the 3 hrs cicle.
BTW The file drops from 1.8 MB to 1.5 MB still too high.
The WU cache is at 88K.

---

@Stephen

Could you make me a favor?

Can you look and post (or PM) the size of your setiathome.berkeley.edu.xml file? Its located on the boinc directory (the one where the boinc.exe program is placed)

And if you could look how many seconds your host is asking for new work on the scheduled request? That will appears o the history file if you have the sched_op flag activated.

Asked because after the change for 303 to 606 my host has serious troubles to report the work and the only possible cause i was able to imagine focus on this 2 possibilities. So i need the info of a regular client who is getting work to be sure i'm in the right path.

Thanks in advance.

. . I hate to be a disappointment Juan but there is no such file in the BOINC folder on this machine (Windows) under program, but in the data directory there is a statistics.setiathome.berkeley.edu.xml file which is 11Kb, and on the Linux boxes that same file exists in the program/BOINC directories and is 10.5Kb. I don't have that flag set for the log file but I can add it, although I don't think it will yield much info because all I am getting is "no tasks available' and longer and longer backoffs. It is only when I initiate a manual request that I can see the 'normal' backoff which is 606 secs. But if you want me to try something I will happily do so.

Stephen

? ?

@Stephen

Could you make me a favor?

Can you look and post (or PM) the size of your setiathome.berkeley.edu.xml file? Its located on the boinc directory (the one where the boinc.exe program is placed)

And if you could look how many seconds your host is asking for new work on the scheduled request? That will appears o the history file if you have the sched_op flag activated.

Asked because after the change for 303 to 606 my host has serious troubles to report the work and the only possible cause i was able to imagine focus on this 2 possibilities. So i need the info of a regular client who is getting work to be sure i'm in the right path.

Thanks in advance.

. . I hate to be a disappointment Juan but there is no such file in the BOINC folder on this machine (Windows) under program, but in the data directory there is a statistics.setiathome.berkeley.edu.xml file which is 11Kb, and on the Linux boxes that same file exists in the program/BOINC directories and is 10.5Kb. I don't have that flag set for the log file but I can add it, although I don't think it will yield much info because all I am getting is "no tasks available' and longer and longer backoffs. It is only when I initiate a manual request that I can see the 'normal' backoff which is 606 secs. But if you want me to try something I will happily do so.

Stephen

? ?

Was a type error the right name is: sched_request_setiathome.berkeley.edu

But Jimbocous & Grant already give me their numbers. I was able to confirm the problem was because my large file.
By a suggestion i set the report number to a lower set and i'm testing now if that helps of not.
Need to pass the 3 hrs cicle to be sure.

Fingers crossed.
Thanks

---

Just got 1.

Thought it unusual that it was a _1.

Did a bit of searching and found it was the ghost that I had not bothered to try to recover.

Looks like they have turned something back on again.

. . I had 10 ghosts I was unaware of attempt a recovery only to expire :(

Stephen

:(

Was a type error the right name is: sched_request_setiathome.berkeley.edu
But Jimbocous & Grant already give me their numbers. I was able to confirm the problem was because my large file.
By a suggestion i set the report number to a lower set and i'm testing now if that helps of not.
Need to pass the 3 hrs cicle to be sure.
Fingers crossed.
Thanks

. . Good luck!!!

Stephen

:)

No joy. Still receiving:

04-Apr-2020 20:33:46 [SETI@home] Scheduler request failed: HTTP service unavailable
04-Apr-2020 20:33:46 [SETI@home] [sched_op] Deferring communication for 00:14:19
04-Apr-2020 20:33:46 [SETI@home] [sched_op] Reason: Scheduler request failed

After complete the 3 hrs cicle.

So i will reduce the number of active GPUs and the report WU is now at 64

Let's see what i get.

---

No joy. Still receiving:

04-Apr-2020 20:33:46 [SETI@home] Scheduler request failed: HTTP service unavailable
04-Apr-2020 20:33:46 [SETI@home] [sched_op] Deferring communication for 00:14:19
04-Apr-2020 20:33:46 [SETI@home] [sched_op] Reason: Scheduler request failed

After complete the 3 hrs cicle.

So i will reduce the number of active GPUs and the report WU is now at 64

Keep in mind the system is borked

5/04/2020 10:48:11 | SETI@home | Scheduler request failed: HTTP internal server error
5/04/2020 10:50:47 | SETI@home | Scheduler request failed: HTTP service unavailable
5/04/2020 10:53:52 | SETI@home | Scheduler request failed: HTTP internal server error
5/04/2020 11:01:26 | SETI@home | Scheduler request failed: HTTP service unavailable
5/04/2020 11:31:13 | SETI@home | Project has no tasks available

It wasn't just you.

Scheduler is back again, but who knows how long for.

---

Grant
Darwin NT

I reconfigure the device array so now my file size down to 240Kb and reports 128 Wu at a time.

Will slow down the crunch but at least the work will be reported and the new task will allow to flow.

Lets see what i get. Need to pass the 3 hrs cicle to be sure its worked.

---