Sometimes the host has downloads already queued up before you hit NNT.
Those will still downloaded. At least that is what seems to happen to me.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
... BTW it seems these tasks only use GPU's and not CPU's despite the label.
What 'label' are you talking about? On the applications page all the O3ASE apps are labeled as (GW-opencl-ati) or (GW-opencl-nvidia) which pretty clearly identifies them as GPU apps. These apps do need CPU support, as always. The only CPU apps are in the O2MD1 section, which is for the previous observation run, O2.
earthbilly wrote:
... one host had consumed all tasks and finished. 2 hosts somehow each had hundreds of tasks Q'd. Where in the heavens could they have come from?
It won't be anything to do with "tasks queued up" or in transit but not received. The best way to work out what went wrong is to look at your recorded 'log of what happened' in the file stdoutdae.txt. You just need to browse that file over the time period in question. Just look for work requests and tasks received statements.
To get "hundreds" of new tasks, you should find many transactions being made and the exact times when those things happened. If you really did have NNT properly set, look out for the 'resending' of lost tasks. That can happen even when NNT is properly set. To get "hundreds" of actual 'lost' tasks, you must have had a stack of things go wrong earlier (before your nap) so surely you would have noticed something at that earlier time.
If you give a link to the host in question, it would be possible to infer if the problem was DCF related. If you had done a bunch of GRP tasks prior to O3ASE, the estimate for the GW tasks could have been insanely low. Can you rule that out? Do you use 'locations' (aka venues)? If so, were changes in preferences made for the correct location?
So you know how to prevent this in future, you should at least try to identify the cause this time.
For the "non-professional" crunchers and for the sake of making coherent titles it would surely be helpful if the little word/abreviation "GPU" would be shown on the application page in the title for the "O3ASE" WUs.
... BTW it seems these tasks only use GPU's and not CPU's despite the label.
What 'label' are you talking about? On the applications page all the O3ASE apps are labeled as (GW-opencl-ati) or (GW-opencl-nvidia) which pretty clearly identifies them as GPU apps. These apps do need CPU support, as always. The only CPU apps are in the O2MD1 section, which is for the previous observation run, O2.
... BTW it seems these tasks only use GPU's and not CPU's despite the label.
What 'label' are you talking about? On the applications page all the O3ASE apps are labeled as (GW-opencl-ati) or (GW-opencl-nvidia) which pretty clearly identifies them as GPU apps. These apps do need CPU support, as always. The only CPU apps are in the O2MD1 section, which is for the previous observation run, O2.
You can see it does NOT have GPU at the end of the O3AS Engineering line to select what type of tasks to run.
This is what I am talking about Gary. No big deal. Just clarifying for others who put forward a question regarding what kind of task is this? First time I selected it I was surprised it was not a CPU task but there seems to be a bigger command N control issue that the team is working overtime to figure out. I am impressed.
Gary, I am very pleased with how bullet proof your people have built your GPU tasks to survive hardware faults and client mistakes like me, that the tasks don't crash like they used to. Excellent improvements! If controlling the number of tasks that Q is so easy, why are so many working on 03AS?
I'm a World Class PLC motor controller programmer, not a trained code reader/writer. My forte is solving problems no one else can. I still think I can contribute and learn a great deal in the process. I like suggestions on research to help this goal.
I stopped crunching O3AS once I hit my 1000 hr goal. I sort of limited myself as I see not much need for crunching "dummy data." Since I have not been crunching for a while I am wondering if we are still crunching the dummy data or have migrated to the real data? If still the dummy data...is there an ETA to when we may get the real data (at which time I will restart working on O3AS tasks)?
(Given that I still have '000s of hours for GRP1 to crunch for its goal I am in no rush...)
... I am wondering if we are still crunching the dummy data or have migrated to the real data?
I haven't seen any further official announcement that followed the original one in Technical News so I presume that nothing has changed. That announcement mentioned waiting for release of the O3 data by the LIGO Scientific Collaboration (LSC). Perhaps if you perused the LSC website, there might be details for when to expect the data release. I haven't looked so I have no idea.
I would assume that as soon as new data becomes available to E@H, there would be a further announcement in Technical News to confirm it. Presumably this would include details about the anticipated start time and whether or not it would be GPU only or two separate searches (GPU and CPU). My only source of information comes from what the Devs post from time to time so I know nothing more than anyone else reading these forums.
Well, checking the LIGO site (https://www.gw-openscience.org/O3/O3a/), it looks like some data have been made available. The first release was made a week after Bernd's message. So I hope we can soon find some new work units based on these data.
Sometimes the host has
)
Sometimes the host has downloads already queued up before you hit NNT.
Those will still downloaded. At least that is what seems to happen to me.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
I just tried to edit my last
)
I just tried to edit my last entry, but says "ACCESS DENIED", to add, "all 3 hosts are set to web based preferences".
Work runs fine on Bosons reacted into Fermions,
Sunny regards,
earthbilly
Tom M wrote: Sometimes the
)
Probably correct Tom. Only thing that makes sense.
Work runs fine on Bosons reacted into Fermions,
Sunny regards,
earthbilly
earthbilly wrote:... BTW it
)
What 'label' are you talking about? On the applications page all the O3ASE apps are labeled as (GW-opencl-ati) or (GW-opencl-nvidia) which pretty clearly identifies them as GPU apps. These apps do need CPU support, as always. The only CPU apps are in the O2MD1 section, which is for the previous observation run, O2.
It won't be anything to do with "tasks queued up" or in transit but not received. The best way to work out what went wrong is to look at your recorded 'log of what happened' in the file stdoutdae.txt. You just need to browse that file over the time period in question. Just look for work requests and tasks received statements.
To get "hundreds" of new tasks, you should find many transactions being made and the exact times when those things happened. If you really did have NNT properly set, look out for the 'resending' of lost tasks. That can happen even when NNT is properly set. To get "hundreds" of actual 'lost' tasks, you must have had a stack of things go wrong earlier (before your nap) so surely you would have noticed something at that earlier time.
If you give a link to the host in question, it would be possible to infer if the problem was DCF related. If you had done a bunch of GRP tasks prior to O3ASE, the estimate for the GW tasks could have been insanely low. Can you rule that out? Do you use 'locations' (aka venues)? If so, were changes in preferences made for the correct location?
So you know how to prevent this in future, you should at least try to identify the cause this time.
Cheers,
Gary.
For the "non-professional"
)
For the "non-professional" crunchers and for the sake of making coherent titles it would surely be helpful if the little word/abreviation "GPU" would be shown on the application page in the title for the "O3ASE" WUs.
Not everyone is super smart ... (including me)
Gary Roberts
)
This one:
Applications
mikey wrote:Gary Roberts
)
This is what I am talking about Gary. No big deal. Just clarifying for others who put forward a question regarding what kind of task is this? First time I selected it I was surprised it was not a CPU task but there seems to be a bigger command N control issue that the team is working overtime to figure out. I am impressed.
Gary, I am very pleased with how bullet proof your people have built your GPU tasks to survive hardware faults and client mistakes like me, that the tasks don't crash like they used to. Excellent improvements! If controlling the number of tasks that Q is so easy, why are so many working on 03AS?
I'm a World Class PLC motor controller programmer, not a trained code reader/writer. My forte is solving problems no one else can. I still think I can contribute and learn a great deal in the process. I like suggestions on research to help this goal.
Work runs fine on Bosons reacted into Fermions,
Sunny regards,
earthbilly
I stopped crunching O3AS once
)
I stopped crunching O3AS once I hit my 1000 hr goal. I sort of limited myself as I see not much need for crunching "dummy data." Since I have not been crunching for a while I am wondering if we are still crunching the dummy data or have migrated to the real data? If still the dummy data...is there an ETA to when we may get the real data (at which time I will restart working on O3AS tasks)?
(Given that I still have '000s of hours for GRP1 to crunch for its goal I am in no rush...)
Werinbert wrote:... I am
)
I haven't seen any further official announcement that followed the original one in Technical News so I presume that nothing has changed. That announcement mentioned waiting for release of the O3 data by the LIGO Scientific Collaboration (LSC). Perhaps if you perused the LSC website, there might be details for when to expect the data release. I haven't looked so I have no idea.
I would assume that as soon as new data becomes available to E@H, there would be a further announcement in Technical News to confirm it. Presumably this would include details about the anticipated start time and whether or not it would be GPU only or two separate searches (GPU and CPU). My only source of information comes from what the Devs post from time to time so I know nothing more than anyone else reading these forums.
Cheers,
Gary.
Well, checking the LIGO site
)
Well, checking the LIGO site (https://www.gw-openscience.org/O3/O3a/), it looks like some data have been made available. The first release was made a week after Bernd's message. So I hope we can soon find some new work units based on these data.