S5R5 plans

Erik
Erik
Joined: 14 Feb 06
Posts: 2815
Credit: 2645600
RAC: 0

RE: So...the result of S5R4

Message 87026 in response to message 87025

Quote:

So...the result of S5R4 would still make any sense? If not, I'd like to stop running this project until S5R5 comes out.

YG

I believe all of the science runs are valid and useful to some degree. I suggest completing the run.

kashi
kashi
Joined: 6 Mar 07
Posts: 13
Credit: 23542234
RAC: 0

Well done, that's excellent

Well done, that's excellent that the new application will have shorter running tasks. I hope you reduce the deadline accordingly. I would suggest 7 days instead of the current 18 days would help greatly to reduce the length of time that some tasks remain pending.

7 days would be long enough for even the slowest computers to complete the new shorter tasks. I know there are some who still use museum pieces for fun but there comes a time when they are no longer suited for distributed computing for electricity/carbon reasons.

A shorter deadline also helps to minimise total pending time when tasks remain unsent for 7-10 days.

It also minimises the delay caused by those who download a large number of tasks, only complete a few and then detach and reattach and repeat this procedure.

Elphidieus
Elphidieus
Joined: 20 Feb 05
Posts: 245
Credit: 20603702
RAC: 0

RE: Well done, that's

Message 87028 in response to message 87027

Quote:

Well done, that's excellent that the new application will have shorter running tasks. I hope you reduce the deadline accordingly. I would suggest 7 days instead of the current 18 days would help greatly to reduce the length of time that some tasks remain pending.

7 days would be long enough for even the slowest computers to complete the new shorter tasks. I know there are some who still use museum pieces for fun but there comes a time when they are no longer suited for distributed computing for electricity/carbon reasons.

A shorter deadline also helps to minimise total pending time when tasks remain unsent for 7-10 days.

It also minimises the delay caused by those who download a large number of tasks, only complete a few and then detach and reattach and repeat this procedure.

A seven-day deadline is way too short as it will be detrimental (pardon my strong word) to those multi-core crunchers like me who would download loads of workunits to last a week or two on less-accessible-yet-automated machines.

Can't wait to get credited on your work...?

kashi
kashi
Joined: 6 Mar 07
Posts: 13
Credit: 23542234
RAC: 0

I don't mind waiting a few

I don't mind waiting a few weeks but a month or more is excessive on any project.

I understand that many who download a lot of work at once complete it all but there are also others with hidden computers who make a habit of downloading many tasks, wait until their wingmen have completed them and then only complete the faster tasks. Not only is this against the spirit of crunching but it is wasteful of server resources and bandwidth.

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: I don't mind waiting a

Message 87030 in response to message 87029

Quote:

I don't mind waiting a few weeks but a month or more is excessive on any project.

I understand that many who download a lot of work at once complete it all but there are also others with hidden computers who make a habit of downloading many tasks, wait until their wingmen have completed them and then only complete the faster tasks. Not only is this against the spirit of crunching but it is wasteful of server resources and bandwidth.

The way the datasets are distributed, if you reduce to a 7-day deadline you will more than likely significantly increase the amount of "backfill" downloading that goes on. This means that there will be more downloading of 70MB+ groups of files. This will irritate those still on dialup.

If runtimes are indeed halved, then the minimum deadline should go to 9 days, since that is half of the current 18. My suggestion though would be to return to the original 14-day deadline.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686127309
RAC: 577205

Several weeks ago the

Several weeks ago the "pending credit" situation was rather bad as reported in this thread, but now, at least for me, it's OK again. If it stays like it is now I can live with a 18 or 14 day deadline. I guess the fact that ATLAS stopped crunching for some time when the servers got overloaded must have contributed to the massive increase of pending credits ?

CU
Bikeman

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7023784931
RAC: 1804666

RE: I guess the fact that

Message 87032 in response to message 87031

Quote:
I guess the fact that ATLAS stopped crunching for some time when the servers got overloaded must have contributed to the massive increase of pending credits ?

Not directly by waiting for it, I think. It seems to me the primary symptom was that it became common for many days to go by between first issue of a result from a WU and issue of the first quorum partner result in that same WU. No matter how promptly everyone processes the results they receive, that situation gives trouble.

It seems to have become less common recently, though my tiny fleet is not a big enough sample to say that with any assurance. Even in that fleet I spotted some 5 day delays within the last week.

Perhaps ATLAS contributed indirectly: instead of waiting for it our waits were a consequence of the scheduler's poor response to its presence.

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: No matter how promptly

Message 87033 in response to message 87032

Quote:
No matter how promptly everyone processes the results they receive, that situation gives trouble.

Could you please state the "trouble" it gives? Help me understand why there is a problem...

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4267
Credit: 244926956
RAC: 16579

The "deadline" is something

The "deadline" is something that can rather easily be adjusted on-the-fly during a run (whereas the average workunit duration is not). With current workunits the average is set to be 18d, for what I recall from previous discussions I think most people feel comfortable with about 14d for 6-8h WUs.

BM

BM

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: The "deadline" is

Message 87035 in response to message 87034

Quote:

The "deadline" is something that can rather easily be adjusted on-the-fly during a run (whereas the average workunit duration is not). With current workunits the average is set to be 18d, for what I recall from previous discussions I think most people feel comfortable with about 14d for 6-8h WUs.

BM

Perhaps people don't remember the history and the reasoning for going up to 18 days. There used to be a lot of complaining about "Einstein" tasks going into Earliest Deadline First (now called "High Priority") when tasks were set to 14 days. The common misconception was that it is the project doing this and that the participants' resource allocation selection is not being honored. People made complaints about Einstein "hogging" their CPU. The reality is that BOINC was/is doing it to try to make sure that work is returned on time and that resource allocations are honored over the long-term, but perhaps not on an hour-by-hour basis.

I view a lot of the "I have way too much pending credit" discussion in a similar light. Is it a "problem"? I guess it could be, if it is significant enough to cause a sizeable amount of participants to stop processing tasks because they feel they are not being rewarded in a timely fashion. Beyond that, it is up to you and the rest of the project team to determine whether or not you need to be getting results in faster.

The deadline needs to be set to something "reasonable". When I requested the increase to 18-21 days, the condition I put on it was that it should be increased until such time as the SSE (and other) enhancements made it into the stock Windows application. Since that time has arrived, 14 days is probably a good choice again. Due to workunit distribution methods, I'm not sure that going lower than that will have the substantial "relief" hoped for by the people who are upset about pending credit and/or unsent tasks.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.