I have a very similar problem happening as well. One machine that is using BOINC version 6.10.60 seems to do ok for the most part. At times it has trouble getting new WU’s. It was having trouble uploading completed WU’s until a few days ago.

The other computer that is using BOINC version 6.12.26 has a really difficult time getting new WU’s. After having it sit idle for nearly the last 4 or 5 days, I decided today to start another project. I did not want to do this. The new project, Rosetta, sent WU’s just fine and the computer has been working on them all day. It has yet to receive a completed WU download from SETI. If I am lucky, it will receive some but the download always stops. I am still awaiting for it to download a few from this morning. Unless I sit there with it and keep hitting “retry” for hours, it takes an extremely long time to get them which is why I gave up and started the new project.

I have two ways to connect to the internet. One is a verizon card, the other is a virgin mobile card. I have tried both with no difference.

The computer has been crunching for Rosetta all day today as it has not received a WU from SETI. Actually it did finish downloading one WU this morning, but that WU download started some time yesterday and was only 366 kbs. Plus I sat there with it and kept hitting retry. It just bothered me having the computer sitting idle for most of its time. Almost like showing up to a neighbors house and saying “I am here to work”. After standing at the front door alone for 3 days with nothing to do, I went to the next neighbor and have been put to work.

How is that host connected to the Net?, Could it be a poor wireless signal or a duff network cable or Nic?,
i have tended to connect to the net via wireless hotspots, sometimes the connection is too slow to report Wu's at all, but other projects where i don't have Wu's report O.K,

Claggy

All my machines are located on a 100 Mb internal network connected to Internet through one firewall with multiple interfaces. I have a regular ADLS line.

No other communication problems has been detected in the network. This problem seem to be related to this host and this program only.

---

I'd be very tempted to back up your Boinc Data directory, remove all traces of Boinc,
then see if you can get the latest recommended Boinc version installed, (what version did you try last time? you didn't say)
then attach to Seti again as a fresh host, and see what happens,

Claggy

Today I stopped boinc and renamed the BOINC catalog. I then installed the same version as used on the other host (with same OS and (almost) same hardware) and attached to seti again.

It is now crunching data again. It seems like three WU's has been reported.

---

One other slight possibility. IIRC BOINC on Linux uses the system's copy of the Curl shared library rather than providing one. If there were a problem with that library reinstalling BOINC wouldn't help.

                                                                  Joe

OMG...now what? Are there ever any consistent periods of time where SETI just crunches numbers, reports the results and requests new tasks without a myriad of issues? Seems like lately (or at least until I got back into using SETI again on my lab servers), SETI has nothing but issues and/or customization requirements.

Now I'm seeing what this thread is all about...can't upload completed tasks and suddenly no new ones are coming down. WTF?

Edit: If I sit here and spam the update button I will get one new task at a time instead of the 7 days worth it should download automagically...

One other slight possibility. IIRC BOINC on Linux uses the system's copy of the Curl shared library rather than providing one. If there were a problem with that library reinstalling BOINC wouldn't help.

                                                                  Joe

Hmm... seems like you are right. I updated to the same version of BOINC which have been running perfectly good on another machine. In the beginning it worked well - the server was able to report.

Today I see that it is two days since last time the machine was in contact with the servers. And again I begin to see error messages about slow connections.

I did a 'yum update curl' which installed version 7.19.7-13.fc12 (previous version was 7.19.6-10.fc12). Then I restarted boinc. Time will tell if this solve this problem.

---

I did a 'yum update curl' which installed version 7.19.7-13.fc12 (previous version was 7.19.6-10.fc12). Then I restarted boinc. Time will tell if this solve this problem.

I'm running boinc (6.12.18) on three machines, all using libcurl-7.19.7-13.fc12.x86_64. I don't have any problems and don't remember having them before the curl update and boinc 6.10.x.
However, I did compile boinc from source (because I needed to fix an ugly bug in boinc that prevents it from working with account managers on most 64-bit Linux distros).

---

My new sig tells it all...nevermind...

---

I did a 'yum update curl' which installed version 7.19.7-13.fc12 (previous version was 7.19.6-10.fc12). Then I restarted boinc. Time will tell if this solve this problem.

I'm running boinc (6.12.18) on three machines, all using libcurl-7.19.7-13.fc12.x86_64. I don't have any problems and don't remember having them before the curl update and boinc 6.10.x.
However, I did compile boinc from source (because I needed to fix an ugly bug in boinc that prevents it from working with account managers on most 64-bit Linux distros).

The other machine (solo), that has worked without any problems and use the same OS and almost the same hardware, does also use the 7.19.6-10.fc12 version of curl.

So I don't think the problem is in the curl library. There is something else with that machine which is screwed up. Finding a solution seem to be impossible.

Still, no contact with my machine (r2-d2) for several days (while the other has been in contact with it today) according to http://setiathome.berkeley.edu/hosts_user.php?userid=7992989.

---

Why does my event log say "Not requesting new tasks" when my preferences are set to download enough for 7 days of activity and I currently only have two active tasks??? I can only assume there is code behind the covers that is now *cough* managing the amount of downloads being parsed out in an attempt to smooth things out with the ridiculously skinny data pipe we are all complaining about.

If it's a duck, then let's call it a duck. Don't put stuff in the event log that is misleading. The event log should say, "Cannot get enough new tasks at this time, per your preferences, due to SETI server network bandwidth constraints."

I promise I will shut up once the software gets the proper editting to let the users know what is really happening.

Why does my event log say "Not requesting new tasks" when my preferences are set to download enough for 7 days of activity and I currently only have two active tasks??? I can only assume there is code behind the covers that is now *cough* managing the amount of downloads being parsed out in an attempt to smooth things out with the ridiculously skinny data pipe we are all complaining about.

If it's a duck, then let's call it a duck. Don't put stuff in the event log that is misleading. The event log should say, "Cannot get enough new tasks at this time, per your preferences, due to SETI server network bandwidth constraints."

I promise I will shut up once the software gets the proper editting to let the users know what is really happening.

There can be several things that will cause BOINC to not ask for tasks. One is if the computer you are talking about is connected to other projects. If your computer is set to receive 7 days of work, it adds the work from all projects to that total. Also, if you have more than twice the number of uploads still trying to upload as you number of processors, then it won't request work. Next it could be your DCF being to high. Look at the details of the computer in question, and see what it's DCF is. It should be close to "1". If it is much higher than that, your computer won't request work.

At any rate, the reason your computer is not requesting work is the situation with your computer, not the servers. If you are able to request work and don't get any, that is due to the server side either not having wu's ready at the exact time of your request, or network traffic being to high.

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

Why does my event log say "Not requesting new tasks" when my preferences are set to download enough for 7 days of activity and I currently only have two active tasks??? I can only assume there is code behind the covers that is now *cough* managing the amount of downloads being parsed out in an attempt to smooth things out with the ridiculously skinny data pipe we are all complaining about.

If it's a duck, then let's call it a duck. Don't put stuff in the event log that is misleading. The event log should say, "Cannot get enough new tasks at this time, per your preferences, due to SETI server network bandwidth constraints."

I promise I will shut up once the software gets the proper editting to let the users know what is really happening.

enable
<work_fetch_debug>1</work_fetch_debug>

in cc_config.xml and look at the

08/06/2011 17:48:55 |  | [work_fetch] target work buffer: 172800.00 + 216000.00 sec
08/06/2011 17:48:55 |  | [work_fetch] CPU: shortfall 0.00 nidle 0.00 saturated 651414.43 busy 0.00 RS fetchable 825.00 runnable 825.00
08/06/2011 17:48:55 |  | [work_fetch] NVIDIA GPU: shortfall 0.00 nidle 0.00 saturated 495358.29 busy 0.00 RS fetchable 650.00 runnable 650.00

entries.

If you are not requesting new tasks, Boinc thinks (for whatever reason) that you have enough work. Depending on personal setup that can have a variety of reasons. work_fetch_debug should tell you all about it.

You can post a stdoutdae.txt snippet [if possible containing aforementioned work_fetch_debug messages] and I'll be happy to analyse it for you.

---

Carola
-------
I'm multilingual - I can misunderstand people in several languages!

Sigh...

"6/8/2011 8:58:02 AM | | Unrecognized tag in cc_config.xml: <work_fetch_debug>
"

Now what?

This should not be this difficult. I set my preferences, the software does what it is set to. How hard is that? There is nothing in my prefs that says "Do not request new tasks if x, y, z."

P.S. Btw, what is "DCF"?

Sigh...

"6/8/2011 8:58:02 AM | | Unrecognized tag in cc_config.xml: <work_fetch_debug>
"

Now what?

P.S. Btw, what is "DCF"?

You need to have it in the <log_flags> section, it probably isn't...
ie.

<cc_config>
   <log_flags>
       <work_fetch_debug>1</work_fetch_debug>
   </log_flags>
</cc_config>

DCF = Duration Correction Factor, looks like
Task duration correction factor 1.471338
on your computer's details page.

HTH,
-Dave

---

Why does my event log say "Not requesting new tasks" when my preferences are set to download enough for 7 days of activity and I currently only have two active tasks??? I can only assume there is code behind the covers that is now *cough* managing the amount of downloads being parsed out in an attempt to smooth things out with the ridiculously skinny data pipe we are all complaining about.

If it's a duck, then let's call it a duck. Don't put stuff in the event log that is misleading. The event log should say, "Cannot get enough new tasks at this time, per your preferences, due to SETI server network bandwidth constraints."

I promise I will shut up once the software gets the proper editting to let the users know what is really happening.

If you'd identify which of your 13 hosts is giving you these symptoms, perhaps some analysis could be done.

The BOINC core client knows nothing about the size of the download pipe (nor does the server-side).

"Not requesting new tasks" is strictly based on client side conditions:

1. If you have more incomplete uploads than 2x the number of CPU logical cores in the host, work fetch is inhibited.
2. If the host is attached to more than one project, a debt mechanism attempts to honor whatever resource shares you have specified.
3. The core client keeps track of how much time you've allowed it to work, and predicts future time fraction on that basis.
4. It is all too easy for a user to look at the Preferences from the Advanced menu of BOINC Manager, click OK without realizing that will lock in whatever settings are shown, and subsequently try to change those settings from the web.
5. Buttons in the BOINC Manager are labeled with the action which will be performed if the button is clicked. Menu entries with a check mark indicate the current state.

BOINC is open source, so the client behavior can be analyzed (though it isn't easy). The first step is gathering enough data, using the <work_fetch_debug> flag in a cc_config.xml file would make sense for your case.

                                                                 Joe

From what I've noticed, 6.12.x will not request new work when you have some (or just one?) downloads in Retry state (and NOT just uploads).

---

Why does my event log say "Not requesting new tasks" when my preferences are set to download enough for 7 days of activity and I currently only have two active tasks??? I can only assume there is code behind the covers that is now *cough* managing the amount of downloads being parsed out in an attempt to smooth things out with the ridiculously skinny data pipe we are all complaining about.

If it's a duck, then let's call it a duck. Don't put stuff in the event log that is misleading. The event log should say, "Cannot get enough new tasks at this time, per your preferences, due to SETI server network bandwidth constraints."

I promise I will shut up once the software gets the proper editting to let the users know what is really happening.

If you'd identify which of your 13 hosts is giving you these symptoms, perhaps some analysis could be done.

The BOINC core client knows nothing about the size of the download pipe (nor does the server-side).

"Not requesting new tasks" is strictly based on client side conditions:

1. If you have more incomplete uploads than 2x the number of CPU logical cores in the host, work fetch is inhibited. I do not
2. If the host is attached to more than one project, a debt mechanism attempts to honor whatever resource shares you have specified. I do not

3. The core client keeps track of how much time you've allowed it to work, and predicts future time fraction on that basis. Whatever

4. It is all too easy for a user to look at the Preferences from the Advanced menu of BOINC Manager, click OK without realizing that will lock in whatever settings are shown, and subsequently try to change those settings from the web. Whatever. Was never a problem until recently.

5. Buttons in the BOINC Manager are labeled with the action which will be performed if the button is clicked. Menu entries with a check mark indicate the current state. Push update button, no new tasks requested.


BOINC is open source, so the client behavior can be analyzed (though it isn't easy). The first step is gathering enough data, using the <work_fetch_debug> flag in a cc_config.xml file would make sense for your case.

                                                                 Joe

[/i][/b]

From what I've noticed, 6.12.x will not request new work when you have some (or just one?) downloads in Retry state (and NOT just uploads).

And previous versions of BOINC did the same, for as far back as I can remember.

Next it could be your DCF being to high. Look at the details of the computer in question, and see what it's DCF is. It should be close to "1". If it is much higher than that, your computer won't request work.

Steve,

what would you define as a DCF "much higher" than 1.0 then? my host for this project is currently at 2.14, and getting AP tasks can be a real PITA for me sometimes (granted, not all the time). i'm just trying to eliminate DCF as the reason for my occasional AP work fetch woes, and hoping that its just due to excessive server traffic.

*EDIT* - i'm not specifically referring to my current inability to fetch AP work, as i believe nobody is getting AP work right now...i've been watching the number of AP results "ready to send" steadily increase all day. right now its at 22,129 tasks...i've never seen it that high, but i'm assuming its only been able to climb that high b/c either AP splitters 1, 4, 5, and 6 are producing results faster than they're getting processed, or nobody is able to download any of the results currently being produced by splitters 1, 4, 5, and 6.

---