If you are only getting 1 or 2 tasks on your requests when you have a large shortfall then take note of Richards post 1153104 in request issues.

I'm pretty sure that request for 1 second, when there's a near-30,000 second shortfall, is a DCF safety.

Edit - confirmed: I edited DCF by a factor of ten - took out a zero, so 0.013... became 0.13...

And conveniently, just as I was reading that, a host I've been monitoring confirmed it:

18/09/2011 15:35:36 | | [work_fetch] NVIDIA GPU: shortfall 132825.49 nidle 0.00 saturated 44294.51 busy 0.00 RS fetchable 100.00 runnable 100.00
18/09/2011 15:35:36 | SETI@home | [work_fetch] NVIDIA GPU: fetch share 1.00 LTD 0.00 backoff dt 0.00 int 0.00
18/09/2011 15:35:36 | | [work_fetch] No project chosen for work fetch
18/09/2011 15:35:50 | SETI@home | Computation for task 12jl11ad.18873.476.9.10.189_0 finished
18/09/2011 15:35:50 | SETI@home | [dcf] DCF: 0.016567->0.021427, raw_ratio 0.021427, adj_ratio 1.293360
18/09/2011 15:36:02 | | [work_fetch] NVIDIA GPU: shortfall 119854.60 nidle 0.00 saturated 57265.40 busy 0.00 RS fetchable 100.00 runnable 100.00
18/09/2011 15:36:02 | SETI@home | [work_fetch] request: CPU (0.00 sec, 0.00 inst) NVIDIA GPU (119854.60 sec, 0.00 inst)
18/09/2011 15:36:02 | SETI@home | Reporting 10 completed tasks, requesting new tasks for NVIDIA GPU
18/09/2011 15:36:02 | SETI@home | [sched_op] CPU work request: 0.00 seconds; 0.00 CPUs
18/09/2011 15:36:02 | SETI@home | [sched_op] NVIDIA GPU work request: 119854.60 seconds; 0.00 GPUs

I reckon this weekend goes down as 'revenge of the little guys'.

That host is a 9800GT - as you see, it's teetering above and below the 0.02 DCF 'work fetch' cutoff value - I'm still clearing out some work assigned with stock estimates, VHAR drives DCF below 0.02, mid-AR takes it back above.

In about 20 minutes, the optimised app APR kicks in, with tasks given twice the stock speed estimate. That'll do nicely, and I've got a good big run of shorties lined up (the best part of 200) - they'll be reporting, one or two every six minutes, all evening I reckon.

That's why the "results returned per hour" is so high. Stock crunchers, and the people with lesser CUDA cards, are having a field-day with a download pipe mercifully clear of AP, and plenty of shorties between the VLARs.

It´s not just the client problem. Even if you request work and it´s available, it´s not beeing assigned. It keeps just sending 0 or 1 even if you are drain.

My problem isn't getting 1 or 2 for the GPU, it's getting any at all. Sometimes i get a couple, sometimes a dozen, sometimes a couple of dozen. But invariably they're all crunched before i can download anymore.
"No tasks sent" is the usual message, but there are plenty of "Project has no tasks available" there as well.

---

Grant
Darwin NT

When BOINC asks for new work, the return message has been "no work available" for AP since last Tuesday.

Either the estimated completion times for new AP work are so huge you can only get a couple at a time, or something got borked with the Scheduler when they put in the patch. The AP Raedy to Send buffer just continues to grow, as the Work in Progress gets less & less.

I'm thinking this is probably the case. Does anyone with a nearly-empty 10+10 cache of AP-only get any new APs? I know the ETA would be astronomical, but if you can normally run through one in ~15 hours, surely you should be able to pick up at least one with a 480-hour work request, unless the ETA is up by 30x.

If it's not that, then feeder is borked.

---

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

It is on automatic, I have not messed with it. Machine is not having "too full" issues at all. Just getting measly amounts of work irregularly. I keep asking, server keeps saying 0. or 1. Occasional 30-40.. after it has gone completely dry again.

I wasn't suggesting you had fiddled with it, I was just asking what it is.

It could be that stopping BOINC, editting DCF to a realistic value, then re-starting BOINC might fix it.

I'm not having a problem d/loading, not as many as normal agreed, but getting more than you. But that is due to the, now, publicised problem I am having with the AP APR. Because as soon as an AP task completes it punches my DCF up to 1.5 min.

I see no flops entry in the app_info.

---

Janice

Uploads have dropped to Zero.

Claggy

Uploads have stalled and server status page is not updating.

---

Kevin

Aye. Uploads are nil. Cricket has plummeted.

---

Same here!!!!!

---

Yay! The upload server has died again! Which means my BOINC will soon stop requesting work because of the 2*numprocessors limit!

---

It is on automatic, I have not messed with it. Machine is not having "too full" issues at all. Just getting measly amounts of work irregularly. I keep asking, server keeps saying 0. or 1. Occasional 30-40.. after it has gone completely dry again.

I wasn't suggesting you had fiddled with it, I was just asking what it is.

It could be that stopping BOINC, editting DCF to a realistic value, then re-starting BOINC might fix it.

I'm not having a problem d/loading, not as many as normal agreed, but getting more than you. But that is due to the, now, publicised problem I am having with the AP APR. Because as soon as an AP task completes it punches my DCF up to 1.5 min.

I see no flops entry in the app_info.

You will have to manually add the info.
http://setiathome.berkeley.edu/forum_thread.php?id=62293#1055179

Seems to be fairly close after I changed my DCF back to 1.000000 again.

---

Is it time for that dreaded water-fowl to present itself?

---

Don't take life too seriously, as you'll never come out of it alive!

Uploads not working.. :(

Maybe uploads died because APs aren't being handed out and the storage got full? That's happened numerous times. Or did they go and put uploads and WU storage on separate volumes? I thought I remembered reading something about that.

---

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

Is it time for that dreaded water-fowl to present itself?

If its the one i think you mean, our fowl watery fiend only comes out to play when the grass is green :¬)

But i think our crickets have turned into locusts and there will be nothing green left before long, the uploads line seems to have crashed :¬(

I am actually surprised it held as long as it did.
Luckily tomorrow is Monday, and somebody should be in the lab to set things upright again....
Then we wait for the Boinc server code to be straightened out.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Astropuleses are turned off and the servers dont survive the weekend.
I´m wondering.......

---

With each crime and every kindness we birth our future.

Astropuleses are turned off and the servers dont survive the weekend.
I´m wondering.......

Too many tasks stored in the database, maybe.
Lots more MB taks have been downloaded and returned, and a high number of AP;s not even sent out.

The MB Assimilators didn't appear to be working- the backlog was growing minute by minute.

---

Grant
Darwin NT

I am in the process of downloading 6 AP WUs with completion times of 10x. I thought AP downloads were turned off.

---