Why won't application transfer? Screen shows no time remaining, elapsed 11:19:42 and rising, past deadline still running on gamma-ray pulsar search #5 1.11 (FGRPSSE)
Why won't application transfer? Screen shows no time remaining, elapsed 11:19:42 and rising, past deadline still running on gamma-ray pulsar search #5 1.11 (FGRPSSE)
So the task is still running? If so let it run as alot of the processing at the end is on the cpu and if the cpu is busy doing something else it can take awhile. Whether you get credit for it or not might depend on if they send it out to someone else and how fast they can crunch it.
Your thread title says, "Completed Application will not transfer". I presume you're referring to the results files that get uploaded when the science application finishes the analysis. The answer may simply be that the calculations aren't finished yet. Since you say the elapsed time (11:19:42) is still rising, then that would seem to be the case.
Have you looked at the 'Transfers' tab in BOINC Manager (Advanced view) to see if any transfers are stuck?
socrbob wrote:
... Screen shows no time remaining, elapsed 11:19:42 and rising, past deadline ...
The remaining time is just an estimate. It can be wrong. A zero value can also suggest that the task may be 'spinning its wheels' and not actually making progress. Have you tried stopping BOINC and after a few seconds, restarting it again? That may get the task to resume from the last saved checkpoint and then continue normally to completion. Are you saying that with just 11+ hours of elapsed time, the task is already past its 2-week deadline? For that to be the case, the task must have been stuck for quite a while.
What %progress shows in BOINC Manager for the task in question? What is the actual 'Deadline' as shown in the appropriate column?
If the task is well past deadline, you should look at the full workunit on the website to see if it already has 2 validated results. In that case you should just abort your copy since you wont get any credit for it even if you make the effort to complete it.
Hello Gary, thanks for the reply. I stopped and restarted BOINC, no change. The deadline is July 17 04:50:07 2023. I did not do anything yesterday, the 18th thinking it would clear overnight. The progress is 100.00 I was not able to find the workunit in a search. Can you locate it?
Just go to your account on the website and pull up a list of your computers. You have three. Go to the one that has the problem task and click on the tasks list for that machine. Use the dropdown to just look at FGRP5 tasks and you will find it. It's obviously the one with the 17th july date in red. Because it's still there it hasn't been completed yet. It could be any time soon though.
The only other thing to try is a complete reboot of the machine. If the task still doesn't restart from a saved checkpoint after that, you should just abort it and see if a new one will start crunching normally.
Thanks again for your help. A reboot did not help and I aborted the task. I noticed that 2 of my task were invalid due to they were completed too late to validate. That seems strange as they were sent on July 3,23 and the time reported/deadline was July 18. That seems like a long time for my computer not to have finished them. Would you suggest that i abort any task that is past due?
... 2 of my task were invalid due to they were completed too late to validate. That seems strange as they were sent on July 3,23 and the time reported/deadline was July 18.
The tasks (the above two and 4 others - 6 in total) were sent at precisely 3 Jul 2023 6:50:07 UTC. That means that each one had a deadline of 17 Jul 2023 6:50:07 UTC. The one I looked at was reported on 18 Jul 2023 15:43:06 UTC, which is nearly 1.5 days after the deadline.
If you look at the full workunit your task belonged to, the third task was sent out less than a minute after your task's deadline and was completed and returned less than 8 hours later. That's the risk you face in trying to complete tasks that are already past deadline. A fast computer with a small work cache size can return first and cause your task to be rejected.
socrbob wrote:
That seems like a long time for my computer not to have finished them.
Yes, that's indeed the strange bit.
You received the FGRP#5 tasks on 3rd July. The first to complete and validate was returned more than a week later on 10th July. The next one after that was 16th July - almost another week. You have a 6C/12T i5-10600 CPU which should be reasonably fast. Do you have it turned off (or have work suspended) for most of the time? How many concurrent CPU tasks do you allow to run? The reported elapsed time for those tasks was ~11 hours (around 40,000 secs). How come the machine only completed 2 in two weeks?
You are also doing Arecibo, long tasks but only 1 in that 2 week period so that shouldn't have had much effect.
Another strange thing about the above 'first to return and validate' task (returned on 10th July) can be seen by looking at what was returned to the server - just click on the TaskID link to see the stderr output that was returned. Whilst the starting date is not given, the time of day is. It was - 01:50:47. I don't know if that's local time or UTC. Scroll down and you will see that at checkpoint #53 the app was stopped and a further timestamp was given - 19:14:45. That's almost 17.5 hours after the task started. Since dates aren't given, it could even be much longer (ie. +24 hrs, etc.)
A few hours (or maybe days???) later at 02:47:14 crunching resumed and the task completed at 15:50:20. That's a further (at least) 13 hours of crunching. Do you shut down your computer when you finish using it or does it run continuously? Also do you use the preference setting to suspend crunching when computer is in use?
The elapsed time reported for that task was around 11 hours yet the indicated time from the stderr output totals at least 30.5 hours. The task being suspended and kept in RAM due to user activity seems to be the simplest explanation. Unless your 'user activity' is very compute intensive, you don't really need to suspend crunching when doing simple 'office' type stuff. If the task isn't being suspended regularly, I don't know how a reported elapsed time of ~11 hours turns into 30+ hours from start to finish.
Why does einstein work on tasks that the deadline is Aug 6,8 or 12 when there are 58 tasks that the deadline is Aug 5 ?
Boinc does tasks on a first in first out basis until deadlines start to get too close and then it will go into doing tasks based on calendar date and time. ie a task due at 1am will be crunched before a task due at 5 am on the same day when it switches to calendar date mode. As long as your cache is small enough then Boinc will merrily crunch the tasks in the order they arrive.
socrbob wrote: Why won't
)
So the task is still running? If so let it run as alot of the processing at the end is on the cpu and if the cpu is busy doing something else it can take awhile. Whether you get credit for it or not might depend on if they send it out to someone else and how fast they can crunch it.
Your thread title says,
)
Your thread title says, "Completed Application will not transfer". I presume you're referring to the results files that get uploaded when the science application finishes the analysis. The answer may simply be that the calculations aren't finished yet. Since you say the elapsed time (11:19:42) is still rising, then that would seem to be the case.
Have you looked at the 'Transfers' tab in BOINC Manager (Advanced view) to see if any transfers are stuck?
The remaining time is just an estimate. It can be wrong. A zero value can also suggest that the task may be 'spinning its wheels' and not actually making progress. Have you tried stopping BOINC and after a few seconds, restarting it again? That may get the task to resume from the last saved checkpoint and then continue normally to completion. Are you saying that with just 11+ hours of elapsed time, the task is already past its 2-week deadline? For that to be the case, the task must have been stuck for quite a while.
What %progress shows in BOINC Manager for the task in question? What is the actual 'Deadline' as shown in the appropriate column?
If the task is well past deadline, you should look at the full workunit on the website to see if it already has 2 validated results. In that case you should just abort your copy since you wont get any credit for it even if you make the effort to complete it.
Cheers,
Gary.
Hello Gary, thanks for the
)
Hello Gary, thanks for the reply. I stopped and restarted BOINC, no change. The deadline is July 17 04:50:07 2023. I did not do anything yesterday, the 18th thinking it would clear overnight. The progress is 100.00 I was not able to find the workunit in a search. Can you locate it?
socrbob wrote:... I was not
)
Why not?
Just go to your account on the website and pull up a list of your computers. You have three. Go to the one that has the problem task and click on the tasks list for that machine. Use the dropdown to just look at FGRP5 tasks and you will find it. It's obviously the one with the 17th july date in red. Because it's still there it hasn't been completed yet. It could be any time soon though.
The only other thing to try is a complete reboot of the machine. If the task still doesn't restart from a saved checkpoint after that, you should just abort it and see if a new one will start crunching normally.
Cheers,
Gary.
Thanks again for your help. A
)
Thanks again for your help. A reboot did not help and I aborted the task. I noticed that 2 of my task were invalid due to they were completed too late to validate. That seems strange as they were sent on July 3,23 and the time reported/deadline was July 18. That seems like a long time for my computer not to have finished them. Would you suggest that i abort any task that is past due?
Yes. Pointless to work on
)
Yes. Pointless to work on expired tasks.
socrbob wrote:... 2 of my
)
The tasks (the above two and 4 others - 6 in total) were sent at precisely 3 Jul 2023 6:50:07 UTC. That means that each one had a deadline of 17 Jul 2023 6:50:07 UTC. The one I looked at was reported on 18 Jul 2023 15:43:06 UTC, which is nearly 1.5 days after the deadline.
If you look at the full workunit your task belonged to, the third task was sent out less than a minute after your task's deadline and was completed and returned less than 8 hours later. That's the risk you face in trying to complete tasks that are already past deadline. A fast computer with a small work cache size can return first and cause your task to be rejected.
Yes, that's indeed the strange bit.
You received the FGRP#5 tasks on 3rd July. The first to complete and validate was returned more than a week later on 10th July. The next one after that was 16th July - almost another week. You have a 6C/12T i5-10600 CPU which should be reasonably fast. Do you have it turned off (or have work suspended) for most of the time? How many concurrent CPU tasks do you allow to run? The reported elapsed time for those tasks was ~11 hours (around 40,000 secs). How come the machine only completed 2 in two weeks?
You are also doing Arecibo, long tasks but only 1 in that 2 week period so that shouldn't have had much effect.
Another strange thing about the above 'first to return and validate' task (returned on 10th July) can be seen by looking at what was returned to the server - just click on the TaskID link to see the stderr output that was returned. Whilst the starting date is not given, the time of day is. It was - 01:50:47. I don't know if that's local time or UTC. Scroll down and you will see that at checkpoint #53 the app was stopped and a further timestamp was given - 19:14:45. That's almost 17.5 hours after the task started. Since dates aren't given, it could even be much longer (ie. +24 hrs, etc.)
A few hours (or maybe days???) later at 02:47:14 crunching resumed and the task completed at 15:50:20. That's a further (at least) 13 hours of crunching. Do you shut down your computer when you finish using it or does it run continuously? Also do you use the preference setting to suspend crunching when computer is in use?
The elapsed time reported for that task was around 11 hours yet the indicated time from the stderr output totals at least 30.5 hours. The task being suspended and kept in RAM due to user activity seems to be the simplest explanation. Unless your 'user activity' is very compute intensive, you don't really need to suspend crunching when doing simple 'office' type stuff. If the task isn't being suspended regularly, I don't know how a reported elapsed time of ~11 hours turns into 30+ hours from start to finish.
Cheers,
Gary.
Why does einstein work on
)
Why does einstein work on tasks that the deadline is Aug 6,8 or 12 when there are 58 tasks that the deadline is Aug 5 ?
socrbob wrote:Why does
)
Boinc does tasks on a first in first out basis until deadlines start to get too close and then it will go into doing tasks based on calendar date and time. ie a task due at 1am will be crunched before a task due at 5 am on the same day when it switches to calendar date mode. As long as your cache is small enough then Boinc will merrily crunch the tasks in the order they arrive.