The new workunits need and refer to new config files that are part of the app bundle (old: O3ASHF1b_0.config and O3ASHF1b_1.config, new: O3ASBu_0.config O3ASBu_1.config). And thus new plan classes to make sure the new tasks are run with the correct application version and with the new memory requirements.
The new style task will have "O3ASBuB" in the name, instead of "O3ASBu". The currently produced ~44k "tasks to sent" are old style, after that, new style tasks will be produced and sent.
looks like the "new" application does work on the current set of "Bu" tasks since they don't rely on the config files at all, but it will be good to put the config files in place for a smooth transition. I've already downloaded them to prepare my app_info.xml. thanks!
As we did with the previous O3ASHF search, we will split the workunts ...
The current setup works very well for me whereas the previous 'split' arrangement was much more difficult to manage. I've written a lot of new script functions to support the current setup.
If you really want to encourage 2GB GPUs to participate, why don't you setup a new search specifically for them and leave the current search alone? Can't you just set a specific range of frequencies - say 220 - 250Hz (or whatever), using the 0.5Hz range - just for people with 2GB GPUs? Couldn't that be configured to avoid using a 'split' arrangement? I have quite a few 2GB GPUs and would be willing to add some if that separate (non-split) search was available.
In the meantime, I'm planning to set my current hosts to NNT as soon as a new 'split' setup is launched. It will be nice to take an extended break and avoid the summer heat. Today is supposed to peak around 37C.
EDIT: Hadn't seen the further discussion until after posting the above. I'll fire up a 2GB system and see how it goes, before making a final decision.
The current setup works very well for me whereas the previous 'split' arrangement was much more difficult to manage. I've written a lot of new script functions to support the current setup.
the recent Bu tasks have been much less troublesome due to them being almost entirely GPU computation. the CPU portion is much faster than before, and only a small fraction of the overall computation time on CPU compared to the total runtime.
it was difficult to manage with O3ASHFx because the portion of the computation in CPU was around 50% or more of the total runtime. this was the case in both the GPU-CPU, and GPU-CPU-GPU-CPU arrangements.
It is my current assumption that the new tasks will still have a small CPU portion even in the new split arrangement and probably wont require much change of your system configuration.
The tasks themselves (total frequency range, data required etc.) don't change, the only thing that changes is the command-line for the app and thus how these tasks are processed by it.
It is my current assumption that the new tasks will still have a small CPU portion even in the new split arrangement and probably wont require much change of your system configuration.
Thanks for your response. That is my hope as well.
I always tend to assume the worst so that I get pleasantly surprised when it doesn't happen :-). I've been really enjoying the single remarkably short CPU section at the end of current tasks, particularly for my mostly legacy hardware. My fear is that the split config will revert to much longer CPU only sections.
Also I had pre-deployed data and skygrids up to around 210Hz with more to follow. I'm hoping none of that has to change.
The new workunits need and
)
The new workunits need and refer to new config files that are part of the app bundle (old: O3ASHF1b_0.config and O3ASHF1b_1.config, new: O3ASBu_0.config O3ASBu_1.config). And thus new plan classes to make sure the new tasks are run with the correct application version and with the new memory requirements.
BM
Oh ok. So the app is the same
)
Oh ok. So the app is the same otherwise.
_________________________________________________________________________
The new style task will have
)
The new style task will have "O3ASBuB" in the name, instead of "O3ASBu". The currently produced ~44k "tasks to sent" are old style, after that, new style tasks will be produced and sent.
BM
looks like the "new"
)
looks like the "new" application does work on the current set of "Bu" tasks since they don't rely on the config files at all, but it will be good to put the config files in place for a smooth transition. I've already downloaded them to prepare my app_info.xml. thanks!
_________________________________________________________________________
Bernd Machenschalk wrote:As
)
The current setup works very well for me whereas the previous 'split' arrangement was much more difficult to manage. I've written a lot of new script functions to support the current setup.
If you really want to encourage 2GB GPUs to participate, why don't you setup a new search specifically for them and leave the current search alone? Can't you just set a specific range of frequencies - say 220 - 250Hz (or whatever), using the 0.5Hz range - just for people with 2GB GPUs? Couldn't that be configured to avoid using a 'split' arrangement? I have quite a few 2GB GPUs and would be willing to add some if that separate (non-split) search was available.
In the meantime, I'm planning to set my current hosts to NNT as soon as a new 'split' setup is launched. It will be nice to take an extended break and avoid the summer heat. Today is supposed to peak around 37C.
EDIT: Hadn't seen the further discussion until after posting the above. I'll fire up a 2GB system and see how it goes, before making a final decision.
Cheers,
Gary.
Bernd Machenschalk
)
All my hosts have 'pre-deployed' data files and skygrids. Are these still to be used or will there be new stuff for O3ASBuB?
Cheers,
Gary.
Gary Roberts wrote: The
)
the recent Bu tasks have been much less troublesome due to them being almost entirely GPU computation. the CPU portion is much faster than before, and only a small fraction of the overall computation time on CPU compared to the total runtime.
it was difficult to manage with O3ASHFx because the portion of the computation in CPU was around 50% or more of the total runtime. this was the case in both the GPU-CPU, and GPU-CPU-GPU-CPU arrangements.
It is my current assumption that the new tasks will still have a small CPU portion even in the new split arrangement and probably wont require much change of your system configuration.
_________________________________________________________________________
The tasks themselves (total
)
The tasks themselves (total frequency range, data required etc.) don't change, the only thing that changes is the command-line for the app and thus how these tasks are processed by it.
BM
Ian&Steve C. wrote:It is my
)
Thanks for your response. That is my hope as well.
I always tend to assume the worst so that I get pleasantly surprised when it doesn't happen :-). I've been really enjoying the single remarkably short CPU section at the end of current tasks, particularly for my mostly legacy hardware. My fear is that the split config will revert to much longer CPU only sections.
Also I had pre-deployed data and skygrids up to around 210Hz with more to follow. I'm hoping none of that has to change.
Cheers,
Gary.
the new app seems to be
)
the new app seems to be working properly. just waiting for some validation. seems a new validator isnt setup yet?
_________________________________________________________________________