I guess also ATLAS has to be taken into account, I could imagine that there will be periods when E@H jobs get very little CPU time and others when ATLAS is highly productive for E@H, for lack of other jobs. Probably hard to predict and highly irregular. If the deadline is too short there might be mass failures to meet the deadline by the several thousand ATLAS cores. But 14 days seem reasonable.
If the deadline is too short there might be mass failures to meet the deadline by the several thousand ATLAS cores. But 14 days seem reasonable.
It more than likely is reasonable. Personally, I doubt going below 12 days would help, and in fact, I think it may harm things. 14 is a good place to start at. Part of the problem now is the faster Windows app is still not the stock app. A combination of getting the faster app to the general user base along with the reduction to 14 days should be the first step taken to see if it makes a significant dent in the pending / unsent issue. If it does not, then it is up to the project to decide if that issue is a high enough risk to warrant any other action to be taken to address the situation.
A combination of getting the faster app to the general user base along with the reduction to 14 days should be the first step taken to see if it makes a significant dent in the pending / unsent issue.
Is there still an issue? The "oldest unsent result" is now back to the 7 days (it used to be like that as far as I can remember), and pending credits have been reduced likewise (at least that's my experience). I think it's more or less "normal" again.
Is there still an issue? The "oldest unsent result" is now back to the 7 days (it used to be like that as far as I can remember), and pending credits have been reduced likewise (at least that's my experience). I think it's more or less "normal" again.
There are still people complaining about it, so there is an "issue" of some sort, either real or perceived...
If this run hits, what's the best way to get rid of the optimized application? Resetting the project is what I usually do, but there must be better ways
Drain your queue (set no-new-work)
Report results when it's empty
Shutdown BOINC (make sure it's down all the way)
Remove app_info.xml file
Restart BOINC and enable new work
Any idea when the cut over to S5R5 is likely to happen? So we can plan the above steps, well the first one at least.
Any idea when the cut over to S5R5 is likely to happen? So we can plan the above steps, well the first one at least.
Currently there's a telecon scheduled for tomorrow which covers the subject. Once the final decision is made actually starting the run is a matter of days.
Perhaps my ambit claim of 7 days deadline was a bit ambitious, but it was not my intention to cause offence. I still believe a shorter deadline if possible is better for any quorum project than a longer one, particularly if the project wishes to retain a higher percentage of new contributors. When the unsent time rises it's like a double whammy. However it seems there are valid user and server reasons to justify a 2 week deadline so that's fair enough.
The excellent part of this is that shorter running tasks and an included optimised Windows application will be much better and should help those with slower computers who wish to contribute and also please Windows users. I like them shorter too, thank you.
I have noticed that the running time of the current Einstein tasks can vary on my computer by up to about 27%. Will the new S5R5 tasks also vary the same as the current tasks? I was just wondering if the larger "dwell time" per sky location would change this running time variability.
I have noticed that the running time of the current Einstein tasks can vary on my computer by up to about 27%. Will the new S5R5 tasks also vary the same as the current tasks?
The variation is quite normal, there is a lot of info and graphs in the "How to check Performance when Testing a new App" thread.
I guess also ATLAS has to be
)
I guess also ATLAS has to be taken into account, I could imagine that there will be periods when E@H jobs get very little CPU time and others when ATLAS is highly productive for E@H, for lack of other jobs. Probably hard to predict and highly irregular. If the deadline is too short there might be mass failures to meet the deadline by the several thousand ATLAS cores. But 14 days seem reasonable.
CU
Bikeman
RE: If the deadline is too
)
It more than likely is reasonable. Personally, I doubt going below 12 days would help, and in fact, I think it may harm things. 14 is a good place to start at. Part of the problem now is the faster Windows app is still not the stock app. A combination of getting the faster app to the general user base along with the reduction to 14 days should be the first step taken to see if it makes a significant dent in the pending / unsent issue. If it does not, then it is up to the project to decide if that issue is a high enough risk to warrant any other action to be taken to address the situation.
RE: A combination of
)
Is there still an issue? The "oldest unsent result" is now back to the 7 days (it used to be like that as far as I can remember), and pending credits have been reduced likewise (at least that's my experience). I think it's more or less "normal" again.
CU
Bikeman
RE: Is there still an
)
There are still people complaining about it, so there is an "issue" of some sort, either real or perceived...
RE: RE: Partly on
)
Any idea when the cut over to S5R5 is likely to happen? So we can plan the above steps, well the first one at least.
BOINC blog
RE: Any idea when the cut
)
Currently there's a telecon scheduled for tomorrow which covers the subject. Once the final decision is made actually starting the run is a matter of days.
I'll keep you posted.
BM
BM
Thanks Brenard
)
Thanks Brenard
Shih-Tzu are clever, cuddly, playful and rule!! Jack Russell are feisty!
Merci, Bernd........or is it
)
Merci, Bernd........or is it 'mercy'??....;)....Cheers, Rog.
Perhaps my ambit claim of 7
)
Perhaps my ambit claim of 7 days deadline was a bit ambitious, but it was not my intention to cause offence. I still believe a shorter deadline if possible is better for any quorum project than a longer one, particularly if the project wishes to retain a higher percentage of new contributors. When the unsent time rises it's like a double whammy. However it seems there are valid user and server reasons to justify a 2 week deadline so that's fair enough.
The excellent part of this is that shorter running tasks and an included optimised Windows application will be much better and should help those with slower computers who wish to contribute and also please Windows users. I like them shorter too, thank you.
I have noticed that the running time of the current Einstein tasks can vary on my computer by up to about 27%. Will the new S5R5 tasks also vary the same as the current tasks? I was just wondering if the larger "dwell time" per sky location would change this running time variability.
RE: I have noticed that the
)
The variation is quite normal, there is a lot of info and graphs in the "How to check Performance when Testing a new App" thread.