I had exactly the same problem. Using ipconfig /flushdns as suggested by Mike did not solve the problem. I had similar problems last week and a reboot solved this, so I tried that again and again it solved the problem. I don't know what is causing this, but as it can be fixed by a reboot it is probably local and not server related.

Tom

Whatever it is, it's a problem.
In the last 5 1/2 hours i've only had 11 successfull requests for work on the machine experiencing this issue. While a couple of them resulted in 20+ Work Units, others only got 1 or 2. End result- my cache is shrinking again, not growing.

At the moment there is a dip in network traffic- and it's not because of full caches. Both of my systems have requested work & both have received "No tasks sent" messages in response- that's 5 requests for work from one system & 4 requests fom the other. All while the network traffic is at a lull.
If caches were full, then there would be no demand for work, then there should be plenty of work ready to be dished out- no less than 200,00 Work Units for several houtrs now. So a request for work should result in plenty. Yet it results in none.

Possibly the feeder is blocked? There's work there, i need it, but it's just not getting through. Last night almost every request resulted in work being allocated; now almost every request results in no work being allocated.

---

Read the message. It is saying the server has no available tasks. It is not saying you can't connect.
Given the delivery pipe only contains a 100 tasks, and is refilled every few seconds there will be times when there are no tasks available, and if you are just right in your request timing of will miss the several times in a row.
We are getting over an unplanned outage everyone will be trying to get work, so tasks will be being gobbled up as soon as they arrive for delivery, with a very short time window for a successful request. As for getting lots of tasks - Apart from cheating the only way to get loads of tasks is sit back and wait for a quieter time, there is nothing a user can do to request lots of tasks NOW.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Hello Rob,

There are two different messages here.
What I see when the problem is persistent is:

24-7-2011 8:32:04 | SETI@home | Reporting 1 completed tasks, requesting new tasks for NVIDIA GPU
24-7-2011 8:32:06 | SETI@home | Scheduler request completed: got 0 new tasks
24-7-2011 8:32:06 | SETI@home | No tasks sent

The message you are referring to has the same first two lines, but the last line says something like "Project has no tasks available". When I see this last message it behaves like you described, but when the last lines says "No tasks sent" things are different and it keeps repeating this message on subsequent requests.

I hope someone can explain what the difference is between the "No tasks sent" and "Project has not tasks available" messages.

Tom

Read the message. It is saying the server has no available tasks. It is not saying you can't connect.
Given the delivery pipe only contains a 100 tasks, and is refilled every few seconds there will be times when there are no tasks available, and if you are just right in your request timing of will miss the several times in a row.
We are getting over an unplanned outage everyone will be trying to get work, so tasks will be being gobbled up as soon as they arrive for delivery, with a very short time window for a successful request. As for getting lots of tasks - Apart from cheating the only way to get loads of tasks is sit back and wait for a quieter time, there is nothing a user can do to request lots of tasks NOW.

---

In short, read (or post) the complete sequence of messages relating to the scheduler request in question, and the explanation should become clearer.

No clearer.
According to my account page, this machine has returned 1147 valid CUD tasks.

24/07/2011 10:48:45 | SETI@home | Sending scheduler request: To fetch work.
24/07/2011 10:48:45 | SETI@home | Reporting 1 completed tasks, requesting new tasks for NVIDIA GPU
24/07/2011 10:48:49 | SETI@home | Scheduler request completed: got 0 new tasks
24/07/2011 10:48:49 | SETI@home | No tasks sent
.....

You are requesting work, but only work for NVIDIA GPU.

Yesterday the servers were sending out a lot of VLAR tasks - my laptop got 30 or more in succession, from three different 'tapes' (26fe11ac, 09mr11 ag, 13mr11af). VLAR tasks are withheld from NVIDIA GPUs - they run very inefficiently. If you were unlucky enough to ask at a time when the 100 tasks in the feeder cache were all VLAR, that would result in a 'no tasks sent'.

In short, read (or post) the complete sequence of messages relating to the scheduler request in question, and the explanation should become clearer.

No clearer.
According to my account page, this machine has returned 1147 valid CUD tasks.

24/07/2011 10:48:45 | SETI@home | Sending scheduler request: To fetch work.
24/07/2011 10:48:45 | SETI@home | Reporting 1 completed tasks, requesting new tasks for NVIDIA GPU
24/07/2011 10:48:49 | SETI@home | Scheduler request completed: got 0 new tasks
24/07/2011 10:48:49 | SETI@home | No tasks sent
.....

You are requesting work, but only work for NVIDIA GPU.

Yesterday the servers were sending out a lot of VLAR tasks - my laptop got 30 or more in succession, from three different 'tapes' (26fe11ac, 09mr11 ag, 13mr11af). VLAR tasks are withheld from NVIDIA GPUs - they run very inefficiently. If you were unlucky enough to ask at a time when the 100 tasks in the feeder cache were all VLAR, that would result in a 'no tasks sent'.

True.

I downloaded 600 tasks yesterday and 400 was just VLARs.

BTW i´m downloading APs with 250 kbps right now.
Didn´t happen in a long time.

---

With each crime and every kindness we birth our future.

You are requesting work, but only work for NVIDIA GPU.

Yesterday the servers were sending out a lot of VLAR tasks - my laptop got 30 or more in succession, from three different 'tapes' (26fe11ac, 09mr11 ag, 13mr11af). VLAR tasks are withheld from NVIDIA GPUs - they run very inefficiently. If you were unlucky enough to ask at a time when the 100 tasks in the feeder cache were all VLAR, that would result in a 'no tasks sent'.

Some of us are asking for all types of work and still seeing very few tasks allocated.

There has been drops in the pipe graph which is unusual this soon after a problem, especialy when the results ready to send is so high.

A Good look at the Top Hosts page, the drop in RAC for the top performers and the size of their cache's, how many have got so few In Progress task's when their usual is 5K - 10K. I have been lucky, I am sitting a lot higher up the chart than I should be, but I have somehow managed to retain a resonable sized cache, but even that is now dropping.

At this time after a problem most of the fast machines would have large awaiting download queue's, I very much doubt this is the case at the moment.

---

Kevin

You are requesting work, but only work for NVIDIA GPU.

Yesterday the servers were sending out a lot of VLAR tasks - my laptop got 30 or more in succession, from three different 'tapes' (26fe11ac, 09mr11 ag, 13mr11af). VLAR tasks are withheld from NVIDIA GPUs - they run very inefficiently. If you were unlucky enough to ask at a time when the 100 tasks in the feeder cache were all VLAR, that would result in a 'no tasks sent'.

I was thinking the same thing- maybe that only VLAR work was available at that instant, however even though i was getting some "No work sent" messages on my other machine it was still getting GPU work.
And on that machine there are several messages where CPU & GPU work was requested, but still the response was "No tasks sent".

Going back through my cache on the problem machine shows one download batch where it was almost solely VLARs, but there were still some shorter WUs in there.
Even so, today a fair number of the CPU tasks have been non-VLARs but it does appear there are a lot still about. Having said that, almost all of the GPU work that has been downloaded today are shorties. There doesn't appear to be much inbetween work about which is a shame.
It takes a #%^^! load of Work Units to fill the cache with shorties (2 WUs in less than 3 min), and hardly any when they're longer running WUs (2 WUs in 18 min).

---

Grant
Darwin NT

Here are the messages from the machine that has been able to keep it's cache up (although still not full).
24/07/2011 18:44:09 SETI@home Sending scheduler request: To fetch work.
24/07/2011 18:44:09 SETI@home Reporting 4 completed tasks, requesting new tasks for CPU and GPU
24/07/2011 18:44:21 SETI@home Scheduler request completed: got 0 new tasks
24/07/2011 18:44:21 SETI@home Message from server: No tasks sent
24/07/2011 18:49:24 SETI@home Sending scheduler request: To fetch work.
24/07/2011 18:49:24 SETI@home Requesting new tasks for CPU and GPU
24/07/2011 18:49:36 SETI@home Scheduler request completed: got 1 new tasks
24/07/2011 18:49:38 SETI@home Started download of 05ap11ab.24013.11928.6.10.210
24/07/2011 18:49:56 SETI@home Finished download of 05ap11ab.24013.11928.6.10.210
24/07/2011 18:54:41 SETI@home Sending scheduler request: To fetch work.
24/07/2011 18:54:41 SETI@home Requesting new tasks for CPU and GPU
24/07/2011 18:54:53 SETI@home Scheduler request completed: got 0 new tasks
24/07/2011 18:54:53 SETI@home Message from server: No tasks sent
24/07/2011 18:54:57 SETI@home Computation for task 18ap11ad.24133.21913.9.10.158_0 finished
24/07/2011 18:54:57 SETI@home Starting 18ap11ad.24133.21913.9.10.149_1
24/07/2011 18:54:57 SETI@home Starting task 18ap11ad.24133.21913.9.10.149_1 using setiathome_enhanced version 610
24/07/2011 18:54:59 SETI@home Started upload of 18ap11ad.24133.21913.9.10.158_0_0
24/07/2011 18:55:05 SETI@home Finished upload of 18ap11ad.24133.21913.9.10.158_0_0
24/07/2011 18:58:05 SETI@home Computation for task 18ap11ad.24133.21913.9.10.155_0 finished
24/07/2011 18:58:05 SETI@home Starting 18ap11ad.24133.23140.9.10.109_1
24/07/2011 18:58:05 SETI@home Starting task 18ap11ad.24133.23140.9.10.109_1 using setiathome_enhanced version 610
24/07/2011 18:58:07 SETI@home Started upload of 18ap11ad.24133.21913.9.10.155_0_0
24/07/2011 18:58:12 SETI@home Finished upload of 18ap11ad.24133.21913.9.10.155_0_0
24/07/2011 18:59:58 SETI@home Sending scheduler request: To fetch work.
24/07/2011 18:59:58 SETI@home Reporting 2 completed tasks, requesting new tasks for CPU and GPU
24/07/2011 19:00:10 SETI@home Scheduler request completed: got 0 new tasks
24/07/2011 19:00:10 SETI@home Message from server: No tasks sent
24/07/2011 19:05:15 SETI@home Sending scheduler request: To fetch work.
24/07/2011 19:05:15 SETI@home Requesting new tasks for CPU and GPU
24/07/2011 19:05:27 SETI@home Scheduler request completed: got 0 new tasks
24/07/2011 19:05:27 SETI@home Message from server: No tasks sent

I suspect the only reason it's been able to keep the number in the cache up is it's BOINC version- it doesn't back off after a missed request nearly as much as the latest versions do. Every 5 min it asks for work, the current ones may back off for 30min after missing 2 requests for work. Just missing one request can result in a 10 min backoff (although it usually is only 5min).

---

Grant
Darwin NT

I suspect the only reason it's been able to keep the number in the cache up is it's BOINC version- it doesn't back off after a missed request nearly as much as the latest versions do. Every 5 min it asks for work, the current ones may back off for 30min after missing 2 requests for work. Just missing one request can result in a 10 min backoff (although it usually is only 5min).

That feature only really comes into play after an extended outage, when a work queue (local cache) - CPU or GPU, separately - has completely run dry. An active GPU cruncher very rarely gets backed off for any significant period, because the delay counter is reset to zero every time a task completes. If you finish a task every five minutes or less (as a multi-GPU machine will), the only inhibitor is the 5:03 server communications backoff.

Here's some work fetch debug from my problem host:

24/07/2011 13:07:05 SETI@home [wfd] NVIDIA GPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 120.00 (comm deferred)
24/07/2011 13:07:05 SETI@home Beta Test [wfd] NVIDIA GPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (no new tasks)
24/07/2011 13:07:05 Milkyway@home [wfd] overall LTD -231380.04
24/07/2011 13:07:05 SETI@home [wfd] overall LTD -21939263.84
24/07/2011 13:07:05 SETI@home Beta Test [wfd] overall LTD 0.00
24/07/2011 13:07:05 [wfd] ------- end work fetch state -------
24/07/2011 13:07:05 [wfd] No project chosen for work fetch
24/07/2011 13:07:50 [wfd] Request work fetch: Backoff ended for SETI@home
24/07/2011 13:07:51 [wfd]: work fetch start
24/07/2011 13:07:51 SETI@home chosen: minor shortfall NVIDIA GPU: 0.00 inst, 3268531.35 sec
24/07/2011 13:07:51 [wfd] ------- start work fetch state -------
24/07/2011 13:07:51 [wfd] target work buffer: 0.86 + 691200.00 sec
24/07/2011 13:07:51 [wfd] CPU: shortfall 597955.19 nidle 0.00 saturated 614363.56 busy 0.00 RS fetchable 100.00 runnable 100.00
24/07/2011 13:07:51 Milkyway@home [wfd] CPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (no new tasks) (blocked by prefs)
24/07/2011 13:07:51 SETI@home [wfd] CPU: fetch share 1.00 LTD 0.00 backoff dt 0.00 int 0.00
24/07/2011 13:07:51 SETI@home Beta Test [wfd] CPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (no new tasks)
24/07/2011 13:07:51 [wfd] NVIDIA GPU: shortfall 3268531.35 nidle 0.00 saturated 241517.28 busy 0.00 RS fetchable 100.00 runnable 100.00
24/07/2011 13:07:51 Milkyway@home [wfd] NVIDIA GPU: fetch share 0.00 LTD -3101.77 backoff dt 0.00 int 0.00 (no new tasks)
24/07/2011 13:07:51 SETI@home [wfd] NVIDIA GPU: fetch share 1.00 LTD 0.00 backoff dt 0.00 int 120.00
24/07/2011 13:07:51 SETI@home Beta Test [wfd] NVIDIA GPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (no new tasks)
24/07/2011 13:07:51 Milkyway@home [wfd] overall LTD -231380.04
24/07/2011 13:07:51 SETI@home [wfd] overall LTD -21870444.44
24/07/2011 13:07:51 SETI@home Beta Test [wfd] overall LTD 0.00
24/07/2011 13:07:51 [wfd] ------- end work fetch state -------
24/07/2011 13:07:51 SETI@home [wfd] request: 3268531.35 sec CPU (597955.19 sec, 0.00) NVIDIA GPU (3268531.35 sec, 0.00)
24/07/2011 13:07:51 SETI@home Sending scheduler request: To fetch work.
24/07/2011 13:07:51 SETI@home Reporting 1 completed tasks, requesting new tasks for CPU and GPU
24/07/2011 13:08:00 SETI@home Scheduler request completed: got 0 new tasks
24/07/2011 13:08:00 SETI@home Message from server: No tasks sent
24/07/2011 13:08:00 SETI@home Message from server: No tasks are available for Astropulse v5
24/07/2011 13:08:00 SETI@home Message from server: No tasks are available for Astropulse v505
24/07/2011 13:08:00 SETI@home [wfd] backing off CPU 35 sec
24/07/2011 13:08:00 SETI@home [wfd] backing off NVIDIA GPU 209 sec
24/07/2011 13:08:00 [wfd] Request work fetch: RPC complete
24/07/2011 13:08:05 [wfd]: work fetch start
24/07/2011 13:08:05 [wfd] ------- start work fetch state -------
24/07/2011 13:08:05 [wfd] target work buffer: 0.86 + 691200.00 sec
24/07/2011 13:08:05 [wfd] CPU: shortfall 599153.83 nidle 0.00 saturated 614422.01 busy 0.00 RS fetchable 0.00 runnable 100.00
24/07/2011 13:08:05 Milkyway@home [wfd] CPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (no new tasks) (blocked by prefs)
24/07/2011 13:08:05 SETI@home [wfd] CPU: fetch share 0.00 LTD 0.00 backoff dt 29.31 int 60.00 (comm deferred)
24/07/2011 13:08:05 SETI@home Beta Test [wfd] CPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (no new tasks)
24/07/2011 13:08:05 [wfd] NVIDIA GPU: shortfall 3270788.25 nidle 0.00 saturated 241379.13 busy 0.00 RS fetchable 0.00 runnable 100.00
24/07/2011 13:08:05 Milkyway@home [wfd] NVIDIA GPU: fetch share 0.00 LTD -3101.77 backoff dt 0.00 int 0.00 (no new tasks)
24/07/2011 13:08:05 SETI@home [wfd] NVIDIA GPU: fetch share 0.00 LTD 0.00 backoff dt 203.81 int 240.00 (comm deferred)
24/07/2011 13:08:05 SETI@home Beta Test [wfd] NVIDIA GPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (no new tasks)
24/07/2011 13:08:05 Milkyway@home [wfd] overall LTD -231380.04
24/07/2011 13:08:05 SETI@home [wfd] overall LTD -21849315.24
24/07/2011 13:08:05 SETI@home Beta Test [wfd] overall LTD 0.00
24/07/2011 13:08:05 [wfd] ------- end work fetch state -------

---

Morten Ross

I suspect the only reason it's been able to keep the number in the cache up is it's BOINC version- it doesn't back off after a missed request nearly as much as the latest versions do. Every 5 min it asks for work, the current ones may back off for 30min after missing 2 requests for work. Just missing one request can result in a 10 min backoff (although it usually is only 5min).

That feature only really comes into play after an extended outage, when a work queue (local cache) - CPU or GPU, separately - has completely run dry. An active GPU cruncher very rarely gets backed off for any significant period, because the delay counter is reset to zero every time a task completes. If you finish a task every five minutes or less (as a multi-GPU machine will), the only inhibitor is the 5:03 server communications backoff.

I'll checkout the times between requests for work tomorrow, a quick look shows them being every 10-20min with v6.12.33 where as with v6.10.58 it's every 5min (although that machine is a quad core with hyperthreading, it has the slower video card).



EDIT- just checked things out then. The work deferral time for the GPU was reset when a GPU Work Unit was completed.
From memory the longest GPU times i've seen on the GTX560ti is about 25 min. So depending on the timing of a Scheduler request & miss & a Work Unit completion, 25min would be the maximum time between requests for work, which is over 4 times the wait compared to the earlier client.
Other than the shorties, usual completion times are around 12-15min, which still puts the requests for work at less than half that of earlier clients.

I still think something is amiss with the allocation of work as requests for both GPU & CPU work often result in none (the day before this wasn't occuring).
Maybe it's always been an issue, but the prensent mix of work has brought it to the fore? Over the last couple of hours the work i've been able to get has been about 90% VLARs for the CPU, and probably 95-97% shorties for the GPU.

---

Grant
Darwin NT

Over the last day and a half I've received 25 APs and about 800 or so MB work units. I have 1317 tasks between two machines. Everything seems to be uploading fine however the servers are giving me a temporarily down error. So it seems the servers are still having some issues.

Seems Synergy, Vader, and jocelyn are having issues. Internet issue or hardware issue is yet to be determined since we have heard no word yet from the lab. Guess I'll happily crunch what I have and keep my fingers crossed I don't run dry before we get service back.

---

Traveling through space at ~67,000mph!

Over the last day and a half I've received 25 APs and about 800 or so MB work units. I have 1317 tasks between two machines. Everything seems to be uploading fine however the servers are giving me a temporarily down error. So it seems the servers are still having some issues.

I think in that context 'temporarily down' means 'temporarily unreachable because of congestion' - where 'temporarily' can be measured in seconds, even fractions of a second. Not showing up as a problem here.

Over the last day and a half I've received 25 APs and about 800 or so MB work units. I have 1317 tasks between two machines. Everything seems to be uploading fine however the servers are giving me a temporarily down error. So it seems the servers are still having some issues.

I think in that context 'temporarily down' means 'temporarily unreachable because of congestion' - where 'temporarily' can be measured in seconds, even fractions of a second. Not showing up as a problem here.

Looking at the server status page, it hasn't been updated for at lease 45 minutes and I am having trouble uploading with the usual HTTP errors. One machine d/l over 100 VLARs yesterday, but haven't had any CUDA work since Thursday.

---

I don't buy computers, I build them!!

Over the last day and a half I've received 25 APs and about 800 or so MB work units. I have 1317 tasks between two machines. Everything seems to be uploading fine however the servers are giving me a temporarily down error. So it seems the servers are still having some issues.

I think in that context 'temporarily down' means 'temporarily unreachable because of congestion' - where 'temporarily' can be measured in seconds, even fractions of a second. Not showing up as a problem here.

Looking at the server status page, it hasn't been updated for at lease 45 minutes and I am having trouble uploading with the usual HTTP errors. One machine d/l over 100 VLARs yesterday, but haven't had any CUDA work since Thursday.

I make the Server status page 8 minutes old, [As of 24 Jul 2011 | 13:20:05 UTC]

Claggy

Over the last day and a half I've received 25 APs and about 800 or so MB work units. I have 1317 tasks between two machines. Everything seems to be uploading fine however the servers are giving me a temporarily down error. So it seems the servers are still having some issues.

I think in that context 'temporarily down' means 'temporarily unreachable because of congestion' - where 'temporarily' can be measured in seconds, even fractions of a second. Not showing up as a problem here.

Depends on what you interpret as a problem though. Not being able to get work could be a problem rather it happens fractions of a second at a time or days. lol ;)

---

Traveling through space at ~67,000mph!

Looks like things are borked again.
It came up OK after the outage for a while, but then it fell over again- once again the splitters just aren't splitting enough work to meet demand.

---

Grant
Darwin NT

Don't forget that we are still in the three day "outage window", so the splitters may be down for a "real reason", not just taking a break....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Don't forget that we are still in the three day "outage window", so the splitters may be down for a "real reason", not just taking a break....

None of the MB splitters are down, but for whatever reason they're just not churning out the work. Before the outage they were producing 30-50 Work Units/sec when necessary. At the moment it's less than 20/sec.
With a normal mix of work it generally takes 25-30/sec just to meet demand, let alone build up a Ready to Send buffer.

---

Grant
Darwin NT

Don't forget that we are still in the three day "outage window", so the splitters may be down for a "real reason", not just taking a break....

None of the MB splitters are down, but for whatever reason they're just not churning out the work. Before the outage they were producing 30-50 Work Units/sec when necessary. At the moment it's less than 20/sec.
With a normal mix of work it generally takes 25-30/sec just to meet demand, let alone build up a Ready to Send buffer.

Well you should be happy now it's up to 30.5537/sec again! Looks like we are still low on work to send out at the moment though with only about 500 ready to send out.

I wonder if they ever worked out the issue they were having that was slowing everything down on the backend.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[