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.
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.
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.
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.
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 ?
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.
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.
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.
RE: So...the result of S5R4
)
I believe all of the science runs are valid and useful to some degree. I suggest completing the run.
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.
RE: Well done, that's
)
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...?
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.
RE: I don't mind waiting a
)
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.
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
RE: I guess the fact that
)
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.
RE: No matter how promptly
)
Could you please state the "trouble" it gives? Help me understand why there is a problem...
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
RE: The "deadline" is
)
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.