Putting the current value of 8.0269/sec into a spreadsheet, and constraining myself to integer seconds, the most plausible values in the first 10 minutes are

3283 in 409 seconds
1790 in 223 seconds

It's one way of filling in time while waiting for new work.

Can someone show me when this 250 task limit was implemented on the feeder as AFAIK the last increase that I know of took it from 100 to 200.

That was just a guess on my part since when the servers were working well I frequently received MORE than 200 tasks at a time for a request when hosts were empty and the general populace was already full. I have seen values as high as the 236 range, so I just guessed that the limit was closer to 250. Or maybe the magic 256 number that is computer friendly.

Last night before bed I was receiving occasional dribs and drabs of work at every 10th request or so. This morning all hosts are completely empty. So either I have very bad luck in the filling queue or there is still a problem with the RTS buffer and splitting.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

This morning all hosts are completely empty. So either I have very bad luck in the filling queue or there is still a problem with the RTS buffer and splitting.

The splitters have been stopped for about 4 hours now. Only Astropulse splitters are running but they are so slow they can satisfy about 2% of the demand. The only work we get now are tie-breakers and some lucky Astropulses.

---

This morning all hosts are completely empty. So either I have very bad luck in the filling queue or there is still a problem with the RTS buffer and splitting.

Same here... only my slower hosts have enough work. Every time that I have checked the result creation rate since the outrage ended it has been 8/sec. or so (and the page has certainly updated since then.) Now all the GBT splitters are showing disabled. so I think that result creation is still being throttled.

There are 5M results in the field even with this, so again it seems to fall back on the three-quorum validation being in place due to the bad AMD hosts.

---

I’m also mostly empty. So it’s not just you.

I was always under the impression that the RTS buffer was 255, 8-bit [0-255]

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

https://boinc.berkeley.edu/trac/wiki/ProjectOptions#Jobscheduling
'The size of the job cache. Default is 100 jobs.'
'The size of the feeder's enumeration query. Default is 200.'

https://boinc.berkeley.edu/trac/wiki/ProjectOptions#Jobscheduling
'The size of the job cache. Default is 100 jobs.'
'The size of the feeder's enumeration query. Default is 200.'

Still, as Keith has also observed, sometimes you get more than 200 tasks in one scheduler call.

---

As the page says, it's configurable in the project's config.xml file - it won't be stored or visible where anyone except a project admin can see it. We'll just have to go on speculating.

Every time that I have checked the result creation rate since the outrage ended it has been 8/sec. or so

It has been that for several hours now but when the splitters were still running, the number was normal. Those 8/sec don't come from splitters but from tie-breaker tasks added by the validator.

Now all the GBT splitters are showing disabled. so I think that result creation is still being throttled.

It's not throttling - the splitters have been completely stopped for a long time now, not 'pulse width modulated' like when they throttled them to help the database shrink.

There are 5M results in the field even with this, so again it seems to fall back on the three-quorum validation being in place due to the bad AMD hosts.

The average replication is only 2.2, so doesn't look that high. I guess the results out in the field is high because people have increased their caches due to recent very long outages.

---

Still, as Keith has also observed, sometimes you get more than 200 tasks in one scheduler call.

24-Jan-2020 02:31:58 [SETI@home] Scheduler request completed: got 306 new tasks

---

Greetings,

The long unscheduled Sunday outages last September and October motivated me to download boinc source and hack it to report fake GPUs. I made it read the number of fake GPUs from a file each time it contacts the scheduler so that I can adjust the queue size on the fly without restarting boinc. The slower computer was running the stock boinc until last Monday when I installed my spoofed client on it too to prepare for Tuesday downtime that Eric announced beforehand to be very long.

So, those of use not getting any work are going to continue not getting any work. Great!

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

Since the project came back up:

I have 2 machines
1 finally recovered and is getting a trickle of work.
The other

1/24/2020 9:37:26 AM | SETI@home | Fetching scheduler list
1/24/2020 9:37:39 AM | | Project communication failed: attempting access to reference site
1/24/2020 9:37:40 AM | | Internet access OK - project servers may be temporarily down.

Have rebooted, etc.

Cannot even get it to report.

Any ideas ?

Dave

---

Dave

Since the project came back up:

I have 2 machines
1 finally recovered and is getting a trickle of work.
The other

1/24/2020 9:37:26 AM | SETI@home | Fetching scheduler list
1/24/2020 9:37:39 AM | | Project communication failed: attempting access to reference site
1/24/2020 9:37:40 AM | | Internet access OK - project servers may be temporarily down.

Have rebooted, etc.

Cannot even get it to report.

Any ideas ?

Dave

Try setting No new tasks (NNT) on the Projects tab. I was able to report all of my completed tasks this way. then reset it to Allow new tasks after all reports are done. Then just wait to get lucky and get some new work.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

Since the project came back up:

I have 2 machines
1 finally recovered and is getting a trickle of work.
The other

1/24/2020 9:37:26 AM | SETI@home | Fetching scheduler list
1/24/2020 9:37:39 AM | | Project communication failed: attempting access to reference site
1/24/2020 9:37:40 AM | | Internet access OK - project servers may be temporarily down.

Have rebooted, etc.

Cannot even get it to report.

Any ideas ?

Dave

Try setting No new tasks (NNT) on the Projects tab. I was able to report all of my completed tasks this way. then reset it to Allow new tasks after all reports are done. Then just wait to get lucky and get some new work.

Have tried NNT, no JOY.

---

Dave

Can someone show me when this 250 task limit was implemented on the feeder as AFAIK the last increase that I know of took it from 100 to 200.

That was just a guess on my part since when the servers were working well I frequently received MORE than 200 tasks at a time for a request when hosts were empty and the general populace was already full. I have seen values as high as the 236 range, so I just guessed that the limit was closer to 250. Or maybe the magic 256 number that is computer friendly.

Last night before bed I was receiving occasional dribs and drabs of work at every 10th request or so. This morning all hosts are completely empty. So either I have very bad luck in the filling queue or there is still a problem with the RTS buffer and splitting.

. . This machine has been empty for nearly 4 hours ... :(

Stephen

:(

Then just wait to get lucky and get some new work.

If you are that lucky, then better use that luck to buy a lottery ticket or something. I have received 5 tasks in the last 6 hours.

---

Now my gpu ran out of tasks and the cpu will follow soon...

And looks like the same is happening to everyone else too. The results out in the field dropped rapidly from millions to thousands!

---

I guess the numbers on the server status page are wrong. 'Results waiting for db purging' is zero but I have almost 8000 task in 'Valid' state where they should be included in that zero count. Also 'results out in the field' dropped suspiciously fast and Astropulse results out is only 71 although AP splitters have been running all day. I have 20 AP tasks here and it's hard to believe that I would have 28% of all the AP tasks in the world!

---

This will be a cold weekend if they don't kick the servers into action.

---

I guess the numbers on the server status page are wrong. 'Results waiting for db purging' is zero but I have almost 8000 task in 'Valid' state where they should be included in that zero count. Also 'results out in the field' dropped suspiciously fast and Astropulse results out is only 71 although AP splitters have been running all day. I have 20 AP tasks here and it's hard to believe that I would have 28% of all the AP tasks in the world!

I don't think the actual numbers have changed in unexpected ways, they've just moved around on the status page, so there is little or no connect between the (current) labels and the numbers.

---