I have had this issue with SETI work not Downloading. IT seems to mostly affect my fastest machines. My Quad Core stays out of seti work as much as it stays in. My Dual core X2 and my Opteron Server both have the same issue. My older PIII and my Laptop seem to get plenty of work.

I come up with 10 to 20 untis waiting in transfer.I get errors like download failed, project servers migth be down. This happens all the time, but seems to be worse on weekends.

I run Another project to fill the gaps, I never have any problem getting work from then. I have disabled SETI for a few days and ran only the other project, just to verify this. The common problem seems to be with the Seti servers, not our machines. I have seen many others with post like mine in some of the other message boards.

The issue started about three to four weeks ago, and has not improved. I have changed the buffer and connect time with no results. IF I could get more work, I could average 1000 instead of staying in the 500 to 600 range.

Does anyone have any ideas as to what in going on?

---

See Matt's Tech News

See Matt's Tech News

I have already read all of the post in that area. We were told in one rely to post in this area, so someone would work on it. It is not a new problem. It has been a problem for a long time. It occurs week days and weekends. I have looked back and I think it began when the servers were upgraded and we had that long downtime about 4 to 6 weeks ago.

---

See Matt's Tech News

I have already read all of the post in that area. We were told in one rely to post in this area, so someone would work on it. It is not a new problem. It has been a problem for a long time. It occurs week days and weekends. I have looked back and I think it began when the servers were upgraded and we had that long downtime about 4 to 6 weeks ago.

Well, read it again then, especially Ozzfan's reply.

Claggy

---

This is the pertinent information from Matt's post:

Still, just for the record even when I'm not in the lab I do check in from time to time and I noticed we were draining work. So before the queue ran to zero I started more splitters. This is good and bad: we're filling the ready-to-send queue, but at the expense of throttling the work we are able to send out.

The way I understand it, unless I'm reading it wrong, is that in order to prevent a "No work from server" messages, he turned on some more splitters to the detriment of throttling the servers' ability to hand out work. IOW, work will get through, it'll just take a little longer (but it doesn't help if everyone pounds the servers with the "update" button).

---

One thing you can do it to look periodically at the Cricket graphs - administrative tools which show how much information is flowing out of the SETI labs at Berkeley.

You'll see that for most of today, there have been about 20 Mbits/sec flowing down the pipe: but for a couple of hours this morning, an hour last thing last night, and most of yesterday morning, the splitters were off and data flowed much more freely.

If you happen to catch the graph during one of its 45Mbits/sec peaks, you stand a much better chance of getting WUs downloaded. Click 'Retry communications' in BOINC Manager (advanced view, and advanced menu).

The Cricket graphs are updated in real time ("now" is at the right-hand edge), and the times along the bottom are in California local time.

This is the pertinent information from Matt's post:

Still, just for the record even when I'm not in the lab I do check in from time to time and I noticed we were draining work. So before the queue ran to zero I started more splitters. This is good and bad: we're filling the ready-to-send queue, but at the expense of throttling the work we are able to send out.

The way I understand it, unless I'm reading it wrong, is that in order to prevent a "No work from server" messages, he turned on some more splitters to the detriment of throttling the servers' ability to hand out work. IOW, work will get through, it'll just take a little longer (but it doesn't help if everyone pounds the servers with the "update" button).

That's why I don't push the button, As It does no good, About the only time I push the button is to update the stats on the graph. I'm sure the team will get the downloads problem fixed asap, So I just make sure everything is running on this end. :D

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Firstly, I am not a novice. I do not "pound on the button". I have presented a reasonable question.

This problem is not new, This weekend is not the only time I have seen it. I see it almost daily on my faster machines. I am not the only person talking about it. I have seen it described by many others. The problem is many weeks old. I did not have it three months ago!

I understand about system bottlenecks. But the end result is work not getting to users. It means lost calculation time and frustrated users. It does not matter if it is the splitters, file handlers or the latest software upgrade.

I only present it so that you can be aware, and can use the information to assist in fixing the problem

---

Firstly, I am not a novice. I do not "pound on the button". I have presented a reasonable question.

I did not mean to imply that you did. I stated it for the benefit of anybody else reading.

This problem is not new, This weekend is not the only time I have seen it. I see it almost daily on my faster machines. I am not the only person talking about it. I have seen it described by many others. The problem is many weeks old. I did not have it three months ago!

I know you're not the only one talking about it, but I disagree that it's many weeks old. Just before the weekend I had no problems connecting for the last week. Others may have had other issues compounded by this one. If it was the same problem, it would affect everyone equally.

I understand about system bottlenecks. But the end result is work not getting to users. It means lost calculation time and frustrated users. It does not matter if it is the splitters, file handlers or the latest software upgrade.

Yes, unfortunately there are frustrated users. And if they did not turn on more splitters, people would be getting "No work from server" messages and the end result would be the same, lost calculation and frustrated users. Either way you look at it, something was going to go wrong.

Of course, taking into account the SETI has never promised 100% uptime and has indeed stated that there will be times of problems, one really shouldn't look at it as "lost calculation". Downtime certainly, but not "lost". Downtime is unavoidable.

I only present it so that you can be aware, and can use the information to assist in fixing the problem

And I'm sure SETI@Home thanks you greatly. I mean that sincerely. But if they're already aware of the problem and were the ones who intentionally messed it up to fix another problem, is assistance really needed? I mean that rhetorically, of course.

---

Thank you for you note. I don't have copies of error messages to prove it, But I do know that it started a week before I built my Quad system. And it has continued. This is not the first time I have written about it. That was almost four weeks ago.

I do run another project, so They get the work when SETI does not.

Best Regards,
Dannis

---

I don't have copies of error messages to prove it, But I do know that it started a week before I built my Quad system. And it has continued. This is not the first time I have written about it. That was almost four weeks ago.

I believe you. Once the server issues are settled, we can work at resolving any other issues you may have. Keep an eye here and there's plenty willing to help. 8-)

---

Firstly, I am not a novice. I do not "pound on the button". I have presented a reasonable question.

This problem is not new, This weekend is not the only time I have seen it. I see it almost daily on my faster machines. I am not the only person talking about it. I have seen it described by many others. The problem is many weeks old. I did not have it three months ago!

I understand about system bottlenecks. But the end result is work not getting to users. It means lost calculation time and frustrated users. It does not matter if it is the splitters, file handlers or the latest software upgrade.

I only present it so that you can be aware, and can use the information to assist in fixing the problem

Please be aware that virtually everyone posting here is a volunteer, just like you. We don't maintain the servers or really do anything more than run BOINC.

As you are not a novice, I'm sure you noticed the caching options in BOINC, especially the newer BOINC versions. I've got "connect every 'x' days" at 0.25 and "keep 'x' days of additional work" set to 10.

At my current rate, I've got approximately a weeks' worth of SETI waiting to be crunched. I've never gone a week without being able to upload/download.

Assuming that the problems aren't at your end (i.e. some over-aggressive internet security application, or poor connectivity) then you really should tune BOINC so that it is less of an issue.

You also mentioned that you're crunching more than one project. If BOINC can't get SETI, it will crunch your other projects and debt will accumulate. When you can get work, BOINC will do more SETI to catch up.

Crunching isn't lost, and BOINC certainly isn't frustrated.

The problem is perception: you see BOINC doing something unexpected, and you assume that BOINC is not meeting your expressed wishes -- that it is in fact something dangerously wrong with SETI and you want it fixed right away.

Again, long term, everything will happen just the way you want.

---

Thank you for your reply. I will continue to watch the post for solutions. Thanks for your efforts and time.

My Best regards,
Dannis

---

Cricket graph is peaking as I type. Just abused Retry Comms, once, and cleared all but one unit in stuck downloads queue.

Ned,

As you are not a novice, I'm sure you noticed the caching options in BOINC, especially the newer BOINC versions. I've got "connect every 'x' days" at 0.25 and "keep 'x' days of additional work" set to 10.

At my current rate, I've got approximately a weeks' worth of SETI waiting to be crunched. I've never gone a week without being able to upload/download.

Thanks for this portion of the post. I had set connect every 10 days so that I could have many WUs ready to work over the course of a week or so as you stated. But, to get them to upload, I would update. (Then, I increased the frequency of connections so I would not have to do that, but with, of course, a dwindling cache.) Thanks to you, I see that there is the "Keep 'x' days of additional work" setting as well. Thanks again!

---

Capitalize on this good fortune, one word can bring you round ... changes.

Cricket graph is peaking as I type. Just abused Retry Comms, once, and cleared all but one unit in stuck downloads queue.

Yes, those periods when the splitters are quiescent certainly demonstrate Matt's point about how work creation interacts with work delivery. It will only continue until the next large batch of quick running Very High Angle Range work, of course.

                                                                Joe

Cricket graph is peaking as I type. Just abused Retry Comms, once, and cleared all but one unit in stuck downloads queue.

Yes, those periods when the splitters are quiescent certainly demonstrate Matt's point about how work creation interacts with work delivery. It will only continue until the next large batch of quick running Very High Angle Range work, of course.

                                                                Joe

Then it's about that time Joe. I'm getting a bunch of them now. :)

---

PROUD MEMBER OF Team Starfire World BOINC

Ned,

As you are not a novice, I'm sure you noticed the caching options in BOINC, especially the newer BOINC versions. I've got "connect every 'x' days" at 0.25 and "keep 'x' days of additional work" set to 10.

At my current rate, I've got approximately a weeks' worth of SETI waiting to be crunched. I've never gone a week without being able to upload/download.

Thanks for this portion of the post. I had set connect every 10 days so that I could have many WUs ready to work over the course of a week or so as you stated. But, to get them to upload, I would update. (Then, I increased the frequency of connections so I would not have to do that, but with, of course, a dwindling cache.) Thanks to you, I see that there is the "Keep 'x' days of additional work" setting as well. Thanks again!

The way the "dynamics" of scheduling works out, you actually have a bigger cache, more consistently, if the "connect every 'x' days" is kind of short (too short and work can be reported too soon after an upload). Something 0.1 or slightly bigger seems to work best (and 0.25 is four times/day).

And since you're not under "connection pressure" BOINC can replenish the cache much more frequently. Works pretty well.

---

Ned, agreed. I just did not know about the second option until you pointed it out. Perhaps more accurately, I had overlooked it. I have another settings question. I'll create a new thread for it. At my cursory glances, it is not something recently discussed.

---

Capitalize on this good fortune, one word can bring you round ... changes.

Ned, agreed. I just did not know about the second option until you pointed it out. Perhaps more accurately, I had overlooked it. I have another settings question. I'll create a new thread for it. At my cursory glances, it is not something recently discussed.

It "snuck in" rather quietly, and it's very cool.

---