BOINC 6.6.36
I'm running SETI and there are a couple of WU still in upload.
BOINC doesn't request for new work even as the computer is out of work.
Is this intentional.

Seti is splitting Astropulse again. This is causing all those computers that do run AP to take up all the bandwidth on the project. Nothing else can get through. This behaviour should settle down by itself, else be going down after today's outage.

See Seti NC forum for threads.

---

Seti is splitting Astropulse again. This is causing all those computers that do run AP to take up all the bandwidth on the project. Nothing else can get through. This behaviour should settle down by itself, else be going down after today's outage.

See Seti NC forum for threads.

What I meant was does BOINC wait for all the WU that need to be uploaded to finish. Before it starts asking for work again. Even if the computer is out of work.

That depends on how many tasks are waiting to upload.
By default, BOINC will allow for 8 simultaneous uploads and downloads per project. If you have more than that waiting to upload, then yes, it'll wait with downloading new work for that project. If the computer was allowed to continue downloading work, after some time all work downloaded would miss the deadline, and most likely be useless for the project, and won't give any credit to users.

You can set a higher maximum amount of simultaneous downloads through cc_config.xml, by adding <max_file_xfers>N</max_file_xfers> to the <options> section, where N is the amount you want to allow.

But it's really better to leave it be and attach to a second or third project.

(Of met deze hitte helemaal niets te doen... ik zit overdag met nul cache en alleen 's nachts laat ik een paar tasks doorlopen... ;-))

---

That depends on how many tasks are waiting to upload.
By default, BOINC will allow for 8 simultaneous uploads and downloads per project. If you have more than that waiting to upload, then yes, it'll wait with downloading new work for that project. If the computer was allowed to continue downloading work, after some time all work downloaded would miss the deadline, and most likely be useless for the project, and won't give any credit to users.

You can set a higher maximum amount of simultaneous downloads through cc_config.xml, by adding <max_file_xfers>N</max_file_xfers> to the <options> section, where N is the amount you want to allow.

But it's really better to leave it be and attach to a second or third project.

(Of met deze hitte helemaal niets te doen... ik zit overdag met nul cache en alleen 's nachts laat ik een paar tasks doorlopen... ;-))

Ok just curious, but the option is something to add, as the work is done in a day anyway. But the backlog is gone so..

(De verwarming doet het weer en dan de anti warmte aan.)

I tried to adjust this setting to no avail. I made other test settings to verify that the config file is being read and successfully interpreted. Is it possible that the <max_file_xfers> setting has been disabled? Sometines uploads get bogged down on weekends and it would be helpful to be able to get some work.

I tried to adjust this setting to no avail. I made other test settings to verify that the config file is being read and successfully interpreted. Is it possible that the <max_file_xfers> setting has been disabled? Sometines uploads get bogged down on weekends and it would be helpful to be able to get some work.

This doesn't help... Waiting does.

I am puzzled why some think the above setting will solve this issue when it doesn't.

I wonder if there is a way to temporarily "hide" the offending jobs and restart Boinc. Then, when the servers are more receptive, bring those tasks "back into the fold", so to speak.

Of course, there's always the option to bring up an "alternate", OS complete with Boinc, then, when the system is more "receptive", drain the alternate and bring up the primary.

I guess there is also a way to bring up Boinc with an alternate data path, but this would require a lot of "twiddling", and could result in a catastrophic screw-up (to the extent that losing a bunch of work and breaking Boinc could be considered "catastrophic".)

In the case of Seti it is just a waiting game, patience is all you need. They have a 100Mbit line into the building that they use for the uploads and downloads. With the large amount of users, plus the problems with the upload server (it being down half the time), we just can't all upload at the same time.

So you don't have to edit anything in any file, you don't have to do anything. BOINC will retry the uploads and eventually it will find a way to get through. I got rid of all my backed up uploads again, without worrying about it.

Just let BOINC do its thing. If you're in the situation where the amount of uploads waiting prevent you from downloading work, then attach to another project. There's no way around it, the bottleneck at Seti will continue to exist for as long as they have that 100Mbit line as their only connection.

---

a) At the risk of sounding contentious, the above does not address the issue of why the aformentioned setting does not function "as advertised".

b) An easy solution to the "won't download" problem is to maintain a queue that is large enough to weather the outages. I have done this, and it works just fine.

c) A discussion evolved in another forum as to why Boinc wouldn't download any work. With much fiddling, it bacame evident that eight or more stalled uploads prevented any downloads. This was canonized in the discussion above. As a test, I started up a system with an "empty" Boinc during one of the "stalled" upload periods. Downloads came "flooding" in and started processing. This effectively ruled out bandwidth as being a relevant issue, at least in that situation.

d) In no way does Boinc inform the user that it will not download because there are too many uploads. All one notices is that the little green Process Explorer square in the tray has turned to black, indicating that the system is idle, while other systems are busy processing. Thus, one spends (wastes) much time trying to figure out what is the problem. A glance at the "Server Status Page" indicates that all the relevant servers are supposedly running. (A closer look might reveal that the "Result turnaround time" has climbed from 51 hours to 112). Thus, the user is left frustrated, trying to figure out what is the problem.

e) While "connecting to another project" might seem to be a solution, the last thing one wants to do with an apparently malfunctioning system is expand the problem to another area. Besides, I tried connecting to another project 2 or 3 years ago. It took four months to finish one work unit, which was just boring. I've been processing Seti for more than ten years amd I'd just as soon continue to do so, at least until the plug is pulled, which, I understand, could be "sooner rather than later". I've done my own personal analysis of the Fermi Paradox, and have concluded that the odds of the Seti multibeam project finding what it's looking for are probably lower than those of winning an alien lottery, but I really don't care.

f) The above post is the first inkling I have had that there is a known problem with the upload process. I'm encouraged to know that it is a recognized issue, and that it is presumably being worked on.

My apologies to anyone if the above sounds snippy, it isn't meant to be so. It's just that I have spent a lot of time on this issue, and I wanted to present these facets.

d) In no way does Boinc inform the user that it will not download because there are too many uploads. All one notices is that the little green Process Explorer square in the tray has turned to black, indicating that the system is idle, while other systems are busy processing. Thus, one spends (wastes) much time trying to figure out what is the problem. A glance at the "Server Status Page" indicates that all the relevant servers are supposedly running. (A closer look might reveal that the "Result turnaround time" has climbed from 51 hours to 112). Thus, the user is left frustrated, trying to figure out what is the problem.

OK, I give you this one and will forward it to the developers. A message of sorts about why many uploads will stop downloads must be possible.

---

a) At the risk of sounding contentious, the above does not address the issue of why the aformentioned setting does not function "as advertised".

And heh, that may be cause I took the wrong one as example. It needed to be the <max_file_xfers_per_project>N</max_file_xfers_per_project> (default 2).

Setting that one higher won't make them go through the pipe any faster though. :-)

My apologies to anyone if the above sounds snippy, it isn't meant to be so.

After having been called way worse in another thread yesterday, having someone being snippy isn't that bad. A whole bit of refreshment even. :-)

---

And heh, that may be cause I took the wrong one as example. It needed to be the <max_file_xfers_per_project>N</max_file_xfers_per_project> (default 2).

Setting that one higher won't make them go through the pipe any faster though. :-)

I actually changed this one from 2 to 1 because I found that with satellite Internet, trying to download two at once actually seems to make them take longer than downloading each one separately.

Nevertheless, there appears to be no way to download when there are eight or more uploads waiting except by resorting to exotic things like virtual machines or alternate Boincs. Of course, maintaining a large queue takes care of it. It also appears that there may be a downward threshold of perhaps 2 uploads or maybe 4 or 6 before it starts downloading. This is extremely difficult to test because creating the exact circumstances depends on so many external issues. Perhaps someone may know about this.

My apologies to anyone if the above sounds snippy, it isn't meant to be so.

After having been called way worse in another thread yesterday, having someone being snippy isn't that bad. A whole bit of refreshment even. :-)[/quote]

Thank you very much for your courteous and thoughtful reply. I have wasted a rediculous amount of time trying to figure this out since I first brought it up on alt.sci.seti on 7/7. I didn't know about this web-based forum until recently.

I actually changed this one from 2 to 1 because I found that with satellite Internet, trying to download two at once actually seems to make them take longer than downloading each one separately.

But isn't that because of the need to still have a landline/modem to send data, to overcome the one second relay time between whichever site you're on, the satellite and you? Or has technology changed and is it now possible to do both the downloading and uploading through satellite?

---

I actually changed this one from 2 to 1 because I found that with satellite Internet, trying to download two at once actually seems to make them take longer than downloading each one separately.

But isn't that because of the need to still have a landline/modem to send data, to overcome the one second relay time between whichever site you're on, the satellite and you? Or has technology changed and is it now possible to do both the downloading and uploading through satellite?

Yes. You can now upload and download via satellite. For about $100 on eBay an ordinary person can buy equipment that will transmit and receive to/from a satellite (after paying $60-$80 a month for the service). There's a 1 watt transmitter on the dish. Although there are shortcomings, the good thing is that one can have high speed Internet access (sort of) in whatever god-forsaken place one may care to go that has a view of the satellite and some sort of electric power.

The short history is that 10 or 12 years ago I was connecting via a download- only modem and a Tellular adapter on a 3 watt analog cell phone. Then they came out with a new modem with a plug on the back, otherwise like the first. Then you got a second modem that connected to that plug on the first one, ran a second coax to the dish, added to or replaced the hardware on the dish, and you had the option of dial return or satellite return. Then, about three years ago, they obsolesced those modems with a new one that operates independently of the computer, connects via ethernet. has a built-in router, and has no dial-return capability. Thus, one winds up with a pile of dishes and modems out in the shed.

To answer the download issue, the signal has to make a round trip of tens of thousands of miles between my house, the satellite, and the Network Operations Center in Germantown, Maryland. Because (I think) the IP connection uses ACKs and NAKs to maintain the data flow, and because the upload speed is much slower than the download speed, my theory is that the ACKs back up waiting to upload, thus slowing the download, and if you try to do more than one download at once, it increases this congestion.