@Bernd, I just noticed that the latest task I ran, ran for a full 4 minutes at 100% done.
Did it finish eventually? There's definitely something wrong with the progress counting that should be fixed in the next App generation (hopefully early next week).
It may have been running for longer at 100%, it's only that I started timing since I saw it at 100% and still in status of running. 4 minutes plus a couple of seconds. It uploaded and reported without trouble.
I'm wondering though whether it runs all the way correctly. Checking in my logs, I see a lot of app restarts without cause. I switch between apps every 90 minutes but I only have work from 3 projects, Einstein, Seti and QuantumFire. So a run will take 180 minutes. Then why would the app restart all the time?
I will have to do some debugging on that, add some CPU scheduling flags to see what's going on (maybe it's a BOINC 6.10.43 problem). And eventually send you the log in email, if you want that. No need to clutter up the forums with that. :-)
There is another question that makes me worry. Why does server tell me that it has no S5R6 work available though it does have them? Instead it gives me a lot of S5GCE and ABP2 CPU WUs that I don't want to crunch yet.
The status page tells that there are more than 100'000 S5R6 workunits not sent yet and even ABP1 WUs (I don't understand what are they here for?).
May be it's better to force finishing all previous runs, before starting new ones, or kill the rest WUs if they are not usable anymore.
There is another question that makes me worry. Why does server tell me that it has no S5R6 work available though it does have them? Instead it gives me a lot of S5GCE and ABP2 CPU WUs that I don't want to crunch yet.
The status page tells that there are more than 100'000 S5R6 workunits not sent yet and even ABP1 WUs (I don't understand what are they here for?).
May be it's better to force finishing all previous runs, before starting new ones, or kill the rest WUs if they are not usable anymore.
The server status page tells you that there are S5R6 and ABP1 workunits where there haven't been found a canonical result yet, it doesn't tell you that these have not yet been sent. The tasks were sent to clients, the server is waiting for them to return. If these return as errors or aren't reported until the deadline, new tasks will be generated and sent out. This is probably what happened a couple of times to the 6 tasks left over from ABP1.
The status page tells that there are more than 100'000 S5R6 workunits not sent yet and even ABP1 WUs (I don't understand what are they here for?).
It doesn't say that there are any 'not sent' S5R6 tasks. I presume you are looking at the "Previous Searches" box which lists the numbers of workunits with 'no final result' for both S5R6 and ABP1. You need to understand that you can't delete workunits on the server until they are completed and they can't be completed until someone returns the second valid result. The server will continue to wait for the return of those results so that the quorum can be completed. This process can take quite a while since results in the field have a two week deadline and the server will need to keep resending any that error out, fail to validate, or fail to meet the deadline.
As soon as the server notices such a task, it will send out a further copy reasonably promptly. At any instant there are likely to be only a few 'unsent' S5R6 tasks. The scheduler does wait to see if a host with suitable data files makes a request so there is a bit of a delay before the scheduler decides to stop waiting and send out a complete data set for that single task.
Quote:
May be it's better to force finishing all previous runs, before starting new ones, or kill the rest WUs if they are not usable anymore.
Would you prefer to have the majority of attached hosts sitting idle whilst the remaining tasks are somehow 'forced'? If there is no desperate need for the final results to be in, it's no problem to let BOINC take care of it over time. In the past there have been occasions where the outstanding results were cleared quickly and that was done by increasing the initial replication so that a whole bunch of extra copies (maybe 10 or more) of the outstanding tasks were sent out. That way at least one host was likely to send back a result quickly but this is rather wasteful of resources.
EDIT: Sorry, my reply obviously took too long to compose :-).
This process can take quite a while since results in the field have a two week deadline and the server will need to keep resending any that error out, fail to validate, or fail to meet the deadline.
As soon as the server notices such a task, it will send out a further copy reasonably promptly. At any instant there are likely to be only a few 'unsent' S5R6 tasks. The scheduler does wait to see if a host with suitable data files makes a request so there is a bit of a delay before the scheduler decides to stop waiting and send out a complete data set for that single task.
I don't suppose it would be an idea to allow S5R6 to enter an 'end of run' mode where it sends out additional copies to get results more quickly?
Does this app have SSE/SSE2
)
Does this app have SSE/SSE2 versions or just x87? The latter would appear to favor older hardware by removing an advantage from new machines.
It has SSE/SSE2 apps.
)
It has SSE/SSE2 apps.
From my P4's log:
@Bernd, I just noticed that the latest task I ran, ran for a full 4 minutes at 100% done. Granted, it was still using the old
I'll check what the new one will do.
RE: @Bernd, I just noticed
)
Did it finish eventually? There's definitely something wrong with the progress counting that should be fixed in the next App generation (hopefully early next week).
BM
BM
RE: Did it finish
)
Yes, as you can see from the link. ;)
It may have been running for longer at 100%, it's only that I started timing since I saw it at 100% and still in status of running. 4 minutes plus a couple of seconds. It uploaded and reported without trouble.
I'm wondering though whether it runs all the way correctly. Checking in my logs, I see a lot of app restarts without cause. I switch between apps every 90 minutes but I only have work from 3 projects, Einstein, Seti and QuantumFire. So a run will take 180 minutes. Then why would the app restart all the time?
I will have to do some debugging on that, add some CPU scheduling flags to see what's going on (maybe it's a BOINC 6.10.43 problem). And eventually send you the log in email, if you want that. No need to clutter up the forums with that. :-)
Okay, I'll take back what I
)
Okay, I'll take back what I said before.
It seems that my Pentium IIIs and Pentium IVs are taking longer for these, after all.
It should take 18 hours on my
)
It should take 18 hours on my Opteron 1210 running Linux as opposed to 10 hours on S5R6.
Tullio
There is another question
)
There is another question that makes me worry. Why does server tell me that it has no S5R6 work available though it does have them? Instead it gives me a lot of S5GCE and ABP2 CPU WUs that I don't want to crunch yet.
The status page tells that there are more than 100'000 S5R6 workunits not sent yet and even ABP1 WUs (I don't understand what are they here for?).
May be it's better to force finishing all previous runs, before starting new ones, or kill the rest WUs if they are not usable anymore.
RE: There is another
)
The server status page tells you that there are S5R6 and ABP1 workunits where there haven't been found a canonical result yet, it doesn't tell you that these have not yet been sent. The tasks were sent to clients, the server is waiting for them to return. If these return as errors or aren't reported until the deadline, new tasks will be generated and sent out. This is probably what happened a couple of times to the 6 tasks left over from ABP1.
BM
BM
RE: The status page tells
)
It doesn't say that there are any 'not sent' S5R6 tasks. I presume you are looking at the "Previous Searches" box which lists the numbers of workunits with 'no final result' for both S5R6 and ABP1. You need to understand that you can't delete workunits on the server until they are completed and they can't be completed until someone returns the second valid result. The server will continue to wait for the return of those results so that the quorum can be completed. This process can take quite a while since results in the field have a two week deadline and the server will need to keep resending any that error out, fail to validate, or fail to meet the deadline.
As soon as the server notices such a task, it will send out a further copy reasonably promptly. At any instant there are likely to be only a few 'unsent' S5R6 tasks. The scheduler does wait to see if a host with suitable data files makes a request so there is a bit of a delay before the scheduler decides to stop waiting and send out a complete data set for that single task.
Would you prefer to have the majority of attached hosts sitting idle whilst the remaining tasks are somehow 'forced'? If there is no desperate need for the final results to be in, it's no problem to let BOINC take care of it over time. In the past there have been occasions where the outstanding results were cleared quickly and that was done by increasing the initial replication so that a whole bunch of extra copies (maybe 10 or more) of the outstanding tasks were sent out. That way at least one host was likely to send back a result quickly but this is rather wasteful of resources.
EDIT: Sorry, my reply obviously took too long to compose :-).
Cheers,
Gary.
RE: This process can take
)
I don't suppose it would be an idea to allow S5R6 to enter an 'end of run' mode where it sends out additional copies to get results more quickly?