By changing its deadlines to 7 days instead of 14 days, the Rosetta project has ALTERED the impact participation has upon off-line users like myself.

I have a slow dialup line; also, I need to manually setup a proxy whenever I want to connect the crunching computer to the server. I'm happiest when I can go days and days and days without having to connect.

By halving its deadlines, the Rosetta project is trying to __force__ me to connect twice as often as I'm comfortable with. I'll see how that works out -- but the result of this deadline change may be that I stop contributing to Rosetta, and go look for a project that is less burdensome for me to participate in.
.

Hopefully the dramatic reduction in the size of the WUs they made will help your download times to improve and counter balance the negative of the shorter deadlines that are necessary in order to get results back for CASP.

If you describe your proxy situation a little further, perhaps there are some steps people could suggest to make it much easier for you to connect as well.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Perhaps it is possible to set a deadline of min(14 days, days till needed for CASP). So some (most?) of the deadlines will still be 14 days.

Norbert

---

Perhaps it is possible to set a deadline of min(14 days, days till needed for CASP). So some (most?) of the deadlines will still be 14 days.

Norbert

I think the problem is that the CASP deadlines are generally 3 weeks from when they release the protein. And R@H needs to build the WU and test them on Ralph... then crunch them on R@H, and then compile the results and do analysis on the findings and perhaps send additional targetted WUs to explore certain areas more thouroughly... and so there just isn't time. But they are clearly doing what they can.

Personally, I think it is best for the rest of client stability and predictability to have a consistent deadline. Otherwise, folks like Mikus would have to be careful to study what deadline they got this time and schedule next connect time etc. And when you download a group of WUs, there would be a good chance at least one would be the short deadline anyway and so they would still have to connect to return it on time. Whereas with a consistent deadline, while it is inconvient for them, at least they know what to expect and it is consistent each time.

Wonder how much of the recent TFLOP increase is temporary due to the reduced deadlines and client's hitting EDF on R@H. There may be a rash of posts soon about "why can't I get R@H to download more work?" as BOINC tries to pay back the other projects for the R@H time to meet the deadline.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Apologies, but your post does not address my situation.

Hopefully the dramatic reduction in the size of the WUs they made will help your download times to improve and counter balance the negative of the shorter deadlines that are necessary in order to get results back for CASP.

Yes, the download times are shorter. But what I do is un-suspend (with boincmgr) the client's network connection and then go away, letting the uploads/downloads proceed at their own pace. I do something else in the meantime. It matters little to me whether the downloads finish in half an hour or in an hour and a half. [Except once, when due to a BUG in the BOINC client the downloads stretched over nine hours and over-loaded my cruncher with work !!]

If you describe your proxy situation a little further, perhaps there are some steps people could suggest to make it much easier for you to connect as well.

As far as I can tell, it *cannot* be done more easily. Connecting to the server takes three steps:

(1) Computer A has hardware connected to a telephone line. I'm typically not using the 'net, so there is no connection. When I do want to dial out, it takes a single click (at (A)) to activate the connection. [If there is a problem making the connection, obviously it takes more decisions. I've had auto-dialers run "wild" (e.g., when my ISP's authentication server crashed), and won't use them.]

(2) Normally, no 'ports' on computer A are activated (unless I'm using a browser at (A) - even then direct http connections were initiated from "inside" not "outside"). When I want my OTHER computers to communicate with the outside (and am connected), it takes a single click (at (A)) to start squid on computer A as a proxy/nat. That activates/filters the 'ports' on computer A that relay http from my other computers. [I do not believe in leaving 'ports' open all the time.]

(3) Normally, the crunching computer (B) is locally on-line to (A), but has its BOINC client network communication suspended (via boincmgr). It takes a single click (at (B)) to make BOINC client network communication available. [If I didn't leave BOINC client network communication suspended, it would at times of its own choosing try to contact the server but fail, and would produce lots of error messages and try totally useless deferred communication intervals.]


Note that my PHILOSOPHY is: 'Don't keep anything "activated" unless it is actually in use'. I have no wish to change.
.

By changing its deadlines to 7 days instead of 14 days, the Rosetta project has ALTERED the impact participation has upon off-line users like myself.

I have a slow dialup line; also, I need to manually setup a proxy whenever I want to connect the crunching computer to the server. I'm happiest when I can go days and days and days without having to connect.

By halving its deadlines, the Rosetta project is trying to __force__ me to connect twice as often as I'm comfortable with. I'll see how that works out -- but the result of this deadline change may be that I stop contributing to Rosetta, and go look for a project that is less burdensome for me to participate in.
.

You and I are getting WUs with various deadlines. Some have a one-week deadline others have two weeks. I don't know if it is implemented yet in 5.4.9 but theoretically BOINC should not download 7-days WU if you set your cache size above 7 days. So try 8 days cache size and you hopefully will receive only 14-day-WUs.

---

...theoretically BOINC should not download 7-days WU if you set your cache size above 7 days. So try 8 days cache size and you hopefully will receive only 14-day-WUs.

I don't think it works that way. That's one of the problems BOINC has at present is short deadlines on large caches. I can actually download more work that it will be able to complete, especially if your cache is larger than the deadline, as you propose. ...unless they've changed something in this newest BOINC version?

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

You and I are getting WUs with various deadlines. Some have a one-week deadline others have two weeks. I don't know if it is implemented yet in 5.4.9 but theoretically BOINC should not download 7-days WU if you set your cache size above 7 days. So try 8 days cache size and you hopefully will receive only 14-day-WUs.

-------------------------------------------------------------------------------

I am still getting workunits with two week deadlines. I do not care either way since this is the only project I am crunching at the moment (LHC has no work). I just hope the admins realize that the deadlines have not been shortened.

I do not think anyone should be that greatly impacted by the shorter deadlines because they can increase their cach size (as previously mentioned) as well as increase the workunit size.

I suggested earlier (a week or two ago) to shorten the deadlines but I never got a response or feedback from anyone.........

---

You and I are getting WUs with various deadlines. Some have a one-week deadline others have two weeks. I don't know if it is implemented yet in 5.4.9 but theoretically BOINC should not download 7-days WU if you set your cache size above 7 days. So try 8 days cache size and you hopefully will receive only 14-day-WUs.

-------------------------------------------------------------------------------

I am still getting workunits with two week deadlines. I do not care either way since this is the only project I am crunching at the moment (LHC has no work). I just hope the admins realize that the deadlines have not been shortened.

I do not think anyone should be that greatly impacted by the shorter deadlines because they can increase their cach size (as previously mentioned) as well as increase the workunit size.

I suggested earlier (a week or two ago) to shorten the deadlines but I never got a response or feedback from anyone.........

They have actually announce that the deadlines would be shortened. Currently there is a mix of 1 and 2 week Work units in the server queue. I do not know at this time if it will continue that way. Most of the long ones are not directly CASP proteins. They are shorter amino chains that they are using to validate the results from known structures.

But the shorter deadlines are being driven by CASP work. While this may be an issue for some people, it is just the nature of CASP.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

As far as I can tell, it *cannot* be done more easily. Connecting to the server takes three steps:

(1) Computer A has hardware connected to a telephone line. I'm typically not using the 'net, so there is no connection. When I do want to dial out, it takes a single click (at (A)) to activate the connection. [If there is a problem making the connection, obviously it takes more decisions. I've had auto-dialers run "wild" (e.g., when my ISP's authentication server crashed), and won't use them.]

(2) Normally, no 'ports' on computer A are activated (unless I'm using a browser at (A) - even then direct http connections were initiated from "inside" not "outside"). When I want my OTHER computers to communicate with the outside (and am connected), it takes a single click (at (A)) to start squid on computer A as a proxy/nat. That activates/filters the 'ports' on computer A that relay http from my other computers. [I do not believe in leaving 'ports' open all the time.]

(3) Normally, the crunching computer (B) is locally on-line to (A), but has its BOINC client network communication suspended (via boincmgr). It takes a single click (at (B)) to make BOINC client network communication available. [If I didn't leave BOINC client network communication suspended, it would at times of its own choosing try to contact the server but fail, and would produce lots of error messages and try totally useless deferred communication intervals.]

Even your case can be simplified quite dramatically. With the correct proxy, step 2 is completely unnecessary. FreeProxy from Handcrafted software ( http://www.handcraftedsoftware.org/ ) can be left running on (A) all the time without compromising security, since it permits binding the listening port to a specific NIC (your LAN NIC in this case).

Step 3 can be moved to machine A by use of Boincview, which allows remote control of a Boinc installation. Therefore your connection process now becomes:

1. Click at (A) to dial up. Allow connection to be established

2. Second click at (A) to cause BOINC at (B) to activate it's network.

-- Edit --

Ack - you're running Squid, which implies (A) is a Linux / Unix system. That just means that you needs to leave it running 24/7 and use the http_port directive to limit where it listens. That gets you the necessary security. Boincview is windows only, not sure if anyone has bothered to write a BOINC remote control package that runs under Linux / Unix. So you may still need to hoof over to B to enable Boinc networking for step 3. Or try running Boincview under Wine .....

---

...theoretically BOINC should not download 7-days WU if you set your cache size above 7 days. So try 8 days cache size and you hopefully will receive only 14-day-WUs.

I don't think it works that way. That's one of the problems BOINC has at present is short deadlines on large caches. I can actually download more work that it will be able to complete, especially if your cache is larger than the deadline, as you propose. ...unless they've changed something in this newest BOINC version?

It is described here under Scheduler work-send policy, but it is still marked as "not implemented yet" so probably not enforced at the moment.

---

Perhaps it is possible to set a deadline of min(14 days, days till needed for CASP). So some (most?) of the deadlines will still be 14 days.

Norbert

we could do this if absolutely necessary, but it is is good to be able to look at the results and evaluate how close to a solution we are after not too long

---

Perhaps it is possible to set a deadline of min(14 days, days till needed for CASP). So some (most?) of the deadlines will still be 14 days.

Norbert

we could do this if absolutely necessary, but it is is good to be able to look at the results and evaluate how close to a solution we are after not too long

I'm in the same situation as above.

The deadline would (I assume) only alter getting work back from multiproject BOINCers. But wouldn't that mean they do a lot of work for you now, then never get any for a while when the debt gets paid off ? (so later CASP target get les work done ?)

For single project crunchers (like mine are setup at the moment).
Then it's not normally a problem since you get them back when they are finished from always on everyday crunchers, unless there like mikus & myself and have to control our connections (I have to manualy send and recieve else others get rather annoyed with a modem dialing through a phone call or it just completely bocks out my browsing due to the bandwidth used)

So does a week deadline really work in the long run ?

It may work, if the tasks over the deadline where still counted and get credit (since I assume they are still usefull to you ?),
Also weekends cause major problems for weekday used computers and a seven day deadline. (the deadline is effecively shorter)

I'm trying to connect every few days now, rather than every week for a big transfer. But the lesser used computers or the end of the queue will miss probably have a few miss the deadlines.

---

Team mauisun.org

It may work, if the tasks over the deadline where still counted and get credit (since I assume they are still usefull to you ?)

I've seen other posts, might even be in FAQ, saying credit is issued for ALL work done, and it explicitly said even if it is past the deadline. But it might arrive too late to help with CASP.

Also weekends cause major problems for weekday used computers and a seven day deadline. (the deadline is effecively shorter)

If I hear you right here, you are saying that it might help measurable if they would use an 8 day deadline rather than 7, is that right?

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

It may work, if the tasks over the deadline where still counted and get credit (since I assume they are still usefull to you ?)

I've seen other posts, might even be in FAQ, saying credit is issued for ALL work done, and it explicitly said even if it is past the deadline. But it might arrive too late to help with CASP.

Also weekends cause major problems for weekday used computers and a seven day deadline. (the deadline is effecively shorter)

If I hear you right here, you are saying that it might help measurable if they would use an 8 day deadline rather than 7, is that right?

we could certainly move to 8 or 9 day deadlines if that would be much better.

---

It may work, if the tasks over the deadline where still counted and get credit (since I assume they are still usefull to you ?)

I've seen other posts, might even be in FAQ, saying credit is issued for ALL work done, and it explicitly said even if it is past the deadline. But it might arrive too late to help with CASP.

Also weekends cause major problems for weekday used computers and a seven day deadline. (the deadline is effecively shorter)

If I hear you right here, you are saying that it might help measurable if they would use an 8 day deadline rather than 7, is that right?

we could certainly move to 8 or 9 day deadlines if that would be much better.

I don't know how much it would help, since it wouldn't effect my setup (not workplace computers) but I have seen in previous projects where 'You get the job on monday so effectively it'll need returning by friday' and people would moan they keep loosing work because of it or something to that effect.

Though with Rosetta's various different configs I don't know how it would work, I assume you'll be in a better position to see the time from sending to recieving normal. I would base it more on that, than what I say :-)

---

Team mauisun.org

A 9 day deadline seems fair to me. I know that it will only be temporary and that most dial up users only have to dial in once every 9 days or so. From my experience with another project, all of the workunits have a 7 day deadline and there does not seem to be any problems......

---

Just for the info.

Another side effect of having different deadline times is that I now have two Rosetta's on the go, the newer tasks/jobs/workunits came down and they have a shorter deadline, causing the client to abandon its current rosetta task and start the newer one. Since I have leave in memory enabled its using more memory up, not really a problem.

(But I really wish BOINC had the option to enable, 'finish job through to the end' rather than this swithing thing, there is loads of time to finish these shorter deadline jobs)

---

Team mauisun.org

(But I really wish BOINC had the option to enable, 'finish job through to the end' rather than this swithing thing, there is loads of time to finish these shorter deadline jobs)

When the BOINC client will sometime be rewritten to match the specs (see: Client scheduling policies, CPU scheduling policies 6.), it will only start a new WU for the same project if the deadline is too near.

Norbert

---

some further thought on short deadlines

for those that have trouble meeting them, this may have a negative impact on the project and speed at which resutls are obtained, because boinc will resend work, which will take longer, and even if the "late" result is returned, and is useful, you've got at least one other cruncher doing work that it didn't have to, reducing the overall crunching power (consider multiples of this situation)

so increasing the deadline just a small amount, might actually have a positive impact, but i don't know, the only way to really know is to try it, i'm just voicing some lateral thinking ;)

---

Want to search the BOINC Wiki, BOINCstats, or various BOINC forums from within firefox? Try the BOINC related Firefox Search Plugins