Keep getting the message No Jobs Available. Server status shows 44,000 available nad none are being created. Can somebody go kick the server since some of my machines are out of work?

---

Keep getting the message No Jobs Available. Server status shows 44,000 available nad none are being created. Can somebody go kick the server since some of my machines are out of work?

You do realise that it is 2AM where the servers are? Unlikely to be much kicking for a few hours yet.

F.

---

Have a look at Matt's Technical News post from just before Christmas. That's the same position we're in now: there is work available in the stockroom, but the servers are having a struggle to keep it piled up on the counter ready for collection (to extend Matt's analogy).

No-one is likely to kick the servers for a while yet, since it's 2 o'clock in the morning where it matters, but the work should keep flowing in fits and starts if you keep asking.

Similar message here and running out of wu's on one rig.
2/2/2009 10:09:27 AM|SETI@home|Message from server: (Project has no jobs available)

---

02.02.2009 16:47:43|SETI@home|Message from server: (Project has no jobs available)
very angry...

---

D5400XS V8-Xeon

Is it that the 'no jobs available' message is inconsistent with reality? (Or vice versa.) There are 15K jobs or so ready to send and we are getting nothing. The 15K number was updated just 20m ago. Scarecrow's graphs indicate a healthy average of 50K RTS's for a while now (96hr or more).

The bandwidth is peaking frequently, per crickets graphs. So It seems that when the bandwidth is peaking, we are getting the wrong ("no jobs available") message.

(Yes, I know it is the correct message, but the more correct one is "bandwidth peaking" or some such)

My point is that there seems to be a structural rift in the system software architecture.

Did either of you two read Matt's explanation?

Perhaps one of you could design a better feeder?

FWIW, every machine of mine that has needed more work today has received plenty - just maybe not at the first attempt.

Hi Richard,
if you have work so you have luck.
My V8-Xeon get work, but all is already done a while.
Now he get no work since more than six hours.
02.02.2009 17:43:30|SETI@home|Sending scheduler request: Requested by user. Requesting 2244205 seconds of work, reporting 1 completed tasks
02.02.2009 17:43:35|SETI@home|Scheduler request succeeded: got 0 new tasks
02.02.2009 17:43:35|SETI@home|Message from server: (Project has no jobs available)
02.02.2009 17:56:12|SETI@home|Sending scheduler request: Requested by user. Requesting 2246400 seconds of work, reporting 3 completed tasks
02.02.2009 17:56:17|SETI@home|Scheduler request succeeded: got 0 new tasks
02.02.2009 17:56:17|SETI@home|Message from server: (Project has no jobs available)
Today 2. Februar V8-Xeon calculated 349 wu's already, but this is not enough for the machine, need work for 6 hours, till the day is over...
and additional work for tomorrow when the outage starts
Have a look at my account...

heinz

SETI@home 02/02/2009 16:50:00 Scheduler request completed: got 20 new tasks

Maybe SETI@home doesn't like Xeons, since they crunch like nobody's business. Even if you download 1K WU cache wouldn't even last a week.

I had my fair share of problems getting new WUs, heck, I don't even recall getting a full 20 WUs of download per scheduler request. Mostly 5 to 12... Half the time would be "no jobs available". I'll be glad to grab some APs to last longer, but one of my Xeons sucks at AP performance.

My suggestion is to sign up for other BOINC projects to keep your rigs busy.

Just received 11 WU's after adjusting preferences

Michael

It's probably me who doesn't understand, but:

Results ready to send 13,620
Current result creation rate 26.5570/sec

With a respectable creation rate of more than 26/s, the number of results ready to send is remarkably low. With a creation rate like that, the results ready to send should be huge (at least almost 100,000 per hour).

I can answer that. It looks like the hope I posted in Technical News earlier today was just that - wishful thinking.

14 of the 20 tasks from the scheduler request I posted 40 minutes ago were from the new 'tape' 06dc08ai dredged up from backing storage over the weekend. They were all shorties, and will last for about 6 minutes each - this is a CUDA machine. The other six have a bit more meat on them, but I'll be back for more inside three hours. The Cruncher's Collective is sucking WUs as fast as Matt can split them, and as fast as the pipe can pump them. There will also be storage problems, filing system inefficiencies, and database bloat. We need more speed, Scotty, to get away from here before the engines blow.

02.02.2009 16:47:43|SETI@home|Message from server: (Project has no jobs available)
very angry...

Why are you "angry" SETI@Home does not guarantee to keep your machine fully occupied 365 days a year. The whole idea behind projects like this is to make use of your "unused" CPU cycles. NOT to crunch 24/7, so If work is running out, join another project, or do what I do, nothing. It will sort itself out.

Bernie

---

I can answer that. It looks like the hope I posted in Technical News earlier today was just that - wishful thinking.

14 of the 20 tasks from the scheduler request I posted 40 minutes ago were from the new 'tape' 06dc08ai dredged up from backing storage over the weekend. They were all shorties, and will last for about 6 minutes each - this is a CUDA machine. The other six have a bit more meat on them, but I'll be back for more inside three hours. The Cruncher's Collective is sucking WUs as fast as Matt can split them, and as fast as the pipe can pump them. There will also be storage problems, filing system inefficiencies, and database bloat. We need more speed, Scotty, to get away from here before the engines blow.

Even worse - the 280 / 295 class cards out there knock them off in about four and a quarter minutes :)

F.

---

This may explain things better than any words:

Results returned per hour, last 60 days

(you may have to visit Scarecrow's graphs page first, to get the image to display)

Results returned, in an ideal world, should match Tasks Issued, at least to a first approximation.

See how there's a noticeable upturn in the number of results around 17 December, when the CUDA application was first released. Then it gradually declined, perhaps as people got disillusioned with the early releases which tended to crash the host computer. Then, CUDA v6.08 was released on 21 January, the trendline turned sharply upwards, and hasn't looked back since. We're now processing twice as many tasks as we were two months ago (and that's a sustained throughput, ignoring the spikes).

I think we can put Matt's estimate of 3% to bed, once and for all.

02.02.2009 16:47:43|SETI@home|Message from server: (Project has no jobs available)
very angry...

Why are you "angry" SETI@Home does not guarantee to keep your machine fully occupied 365 days a year. The whole idea behind projects like this is to make use of your "unused" CPU cycles. NOT to crunch 24/7, so If work is running out, join another project, or do what I do, nothing. It will sort itself out.

Bernie

Actually, SETI has always promised that there will be times when there is no work, it just doesn't happen very often.

---

It's probably me who doesn't understand, but:

Results ready to send 13,620
Current result creation rate 26.5570/sec

With a respectable creation rate of more than 26/s, the number of results ready to send is remarkably low. With a creation rate like that, the results ready to send should be huge (at least almost 100,000 per hour).

The scheduler itself retrieves work units from the database in 100 unit batches.

If the database is running slow, and requests are running fast, it can run out before it gets the next 100.

... and the status page tells you that there were 13,000 when that query was done, but that may change a few minutes later -- either direction.

---

Did either of you two read Matt's explanation?

Perhaps one of you could design a better feeder?

FWIW, every machine of mine that has needed more work today has received plenty - just maybe not at the first attempt.

Richard, my point was that I was getting a "wrong" message, since the indicators showed that 1) RTS was nominal and 2) I was getting "no work" messages.

Of course, right after I wrote that note, I got the fill that my quad was asking for for the previous 8 hours. (==> There is no predictive ability from the system indicators.)

Is it that the 'no jobs available' message is inconsistent with reality? (Or vice versa.) There are 15K jobs or so ready to send and we are getting nothing. The 15K number was updated just 20m ago. Scarecrow's graphs indicate a healthy average of 50K RTS's for a while now (96hr or more).

The bandwidth is peaking frequently, per crickets graphs. So It seems that when the bandwidth is peaking, we are getting the wrong ("no jobs available") message.

(Yes, I know it is the correct message, but the more correct one is "bandwidth peaking" or some such)

My point is that there seems to be a structural rift in the system software architecture.

It's only a "structural rift" if you think real-time is a design requirement.

As others have mentioned elsewhere in this thread, one request goes unfufilled, the next one gets work, and if you weren't looking at the logs, you'd never know.

---