Getting "No tasks available" with 770k ready to send on the server. I gave up trying to understand the logic behind this...

For the record: the 770k was "0m" ago. Something is broken.
Btw, is there some kind of bug tracker somewhere where the issues are tracked and addressed?

Nothing is broken .. there's just (tens of) thousands of machines hitting the server wanting units. RTS is now 330k. Truthfully, even if you did get WUs assigned, you probably couldn't download them due to those machines being overwhelmed also. This is very normal following long outages .. it will be back to normal in a day or so.

---

All systems here up and running - maybe 10% left "Downloading" :-)

---

I'm putting myself to the fullest possible use, which is all, I think, that any conscious entity can ever hope to do.

I had a lot of downloads pending when I got back from my "Dinner date" with a guy who is willing to buy me steak :)

So I hit the retry and there for a while I was getting "http: failed transient error" issues.

But as I write, the queue is now downloading......

Ah, Sweat Seti!

Tom

ps. I now have both gpu and cpu tasks running.... the cache is not even close to full but at least I got "some".

---

A proud member of the OFA (Old Farts Association).

Getting "No tasks available" with 770k ready to send on the server. I gave up trying to understand the logic behind this...

100 other hosts beat you to the RTS buffer first.

. . :)

. . There are clearly still issues to be worked out ... :(

. . Unless those 100 hosts got 8,000 WUs each :)

Stephen

? ?

The actual buffer that you download from only holds about 250 tasks at any time. Constantly replenishes from the RTS buffer that shows on the SSP. If 5 hosts hit it at the same time and get 50 tasks, it empties very fast before refilling. If your request comes in after it was emptied, you get the "no tasks are available" message.

---

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

A proud member of the OFA (Old Farts Association)

Lots of stalled downloads on my hosts. The project will eventually clear the congestion and hosts will get normal returns and requests fulfilled.

---

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

A proud member of the OFA (Old Farts Association)

+1
No downloads are going through.

---

Getting "No tasks available" with 770k ready to send on the server. I gave up trying to understand the logic behind this...

100 other hosts beat you to the RTS buffer first.

. . :)

. . There are clearly still issues to be worked out ... :(

. . Unless those 100 hosts got 8,000 WUs each :)

Stephen

? ?

The actual buffer that you download from only holds about 250 tasks at any time. Constantly replenishes from the RTS buffer that shows on the SSP. If 5 hosts hit it at the same time and get 50 tasks, it empties very fast before refilling. If your request comes in after it was emptied, you get the "no tasks are available" message.

I don't understand why they don't make the 250 task buffer larger. Seems to be a bottleneck.
Can't get enough jobs to keep my top machine's GPUs busy. Why does it keep giving that one CPU tasks?

---

I don't understand why they don't make the 250 task buffer larger. Seems to be a bottleneck.
Can't get enough jobs to keep my top machine's GPUs busy. Why does it keep giving that one CPU tasks?

That buffer might be in Ram. Until they have SSD's installed, it might be "too slow" to use a regular HD.

Tom

---

A proud member of the OFA (Old Farts Association).

I don't understand why they don't make the 250 task buffer larger. Seems to be a bottleneck.
Can't get enough jobs to keep my top machine's GPUs busy. Why does it keep giving that one CPU tasks?

Don't know, probably something to do with the I/O to the buffer and how many concurrent http connections the download server can handle. Don't know enough about server hardware to make a better guess.

Depends on the host. Most of my hosts will ALWAYS fill the gpu cache before ever asking to fill the cpu cache. On one host though, it gets cpu work first and then fills the gpu cache. Something to do with the APR of the applications and what the scheduler thinks is the faster bit of hardware.

---

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

A proud member of the OFA (Old Farts Association)

I'm pretty sure my (idle) 2070 Supers are faster than the i7-5820K. ;)

---

The actual buffer that you download from only holds about 250 tasks at any time. Constantly replenishes from the RTS buffer that shows on the SSP. If 5 hosts hit it at the same time and get 50 tasks, it empties very fast before refilling. If your request comes in after it was emptied, you get the "no tasks are available" message.

. . True, but I liked the imagery and I am sure there are still some knots to be unravelled.

Stephen

:(

I'm pretty sure my (idle) 2070 Supers are faster than the i7-5820K. ;)

But I never suggested the BOINC client code and the scheduler code was logical. It is way more convoluted and I don't think anyone that has ever looked at it would state it works the same way, every time under all circumstances.

---

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

A proud member of the OFA (Old Farts Association)

And my Einstein@Home RAC has topped 80,000. That is way to much for a "backup" project :)

Tom

Yes, Well, Wait until you find you are climbing up their top 50 computers list.

Looks like I am on the bottom of the queue when they hand out tasks here:-(

And it blew past 100,000 RAC too.

Tom

ATM you are No 30 on E@H top computers list wit an RAC of over 1,017,000

I have just cracked No 25 :-)

Just got a reasonable bunch of Seti WU's with a fair No of CPU's, Hopefully the cache will refill properly now.

---

Kevin

That’s my system. Not Toms lol

---

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

That’s my system. Not Toms lol

Oops, Sorry.

---

Kevin

It's been 2 hours since my Linux system was able to get any work. It did get some earlier, very occasionally. But then ran in to issues being able to actually download it.

It seems if you have work- you can get more.
My Windows system also gets mostly "Project has no tasks available" responses, but it's got enough work to keep any timeouts at bay & keep asking, eventually scoring enough work to be (slightly) more than it has returned since the last successful request.

---

Grant
Darwin NT

Oh joy.
It would appear a good chunk of the work currently going out are noise bombs- both Arecibo GBT. That's not going to help things at all.

Edit- and there's a bunch of shorties going through as well.
Perfect storm, perfect timing.

---

Grant
Darwin NT

The actual buffer that you download from only holds about 250 tasks at any time. Constantly replenishes from the RTS buffer that shows on the SSP. If 5 hosts hit it at the same time and get 50 tasks, it empties very fast before refilling. If your request comes in after it was emptied, you get the "no tasks are available" message.

And after a long outage a dry gpu client is asking for 300 or more tasks. So there's no need for many simultaneous hits - a single computer can swallow the entire buffer.

---

Depends on the host. Most of my hosts will ALWAYS fill the gpu cache before ever asking to fill the cpu cache. On one host though, it gets cpu work first and then fills the gpu cache. Something to do with the APR of the applications and what the scheduler thinks is the faster bit of hardware.

My computers normally fill the gpu cache first. But after this week's outage it took them a long time to receive any gpu work. I discovered the reason for that:

I had turned my spoofing dial way up before the outage to coast over it (which wasn't enough , my hosts idled for about a day because so many of the tasks they had buffered were result overflows) and during the outage I turned the dial back to my normal 12 hour buffer. The idea was that if I had had enough buffer to survive the downtime, then I could have surplus after it and my hosts wouldn't need to ask for more gpu work before long after the congestion has cleared.

But I didn't have enough and the buffers were dry when the dt ended. The result was that when my hosts started getting some work, they got CPU work only because the old unreported cache was still larger than my new gpu max buffer. The tasks crunched during the downtime took many hours to report.

---

Why are we processing data that is 10 years old now?
Seems like we had data only few days old before.

---