Test and works, the only wierd thing is in some hosts the change makes no diference, still running 1 WU, even i set 0.5 or 0.33 on preferences. Any clue?
The hosts are: (one with 690+670 and the other 2x670)
The change in the settings affect the work generator, that means after you make the change, NEW work that is sent to your PC get's the info that it needs only the specified shared of a full GPU. Existing tasks that you downloaded before will not be affected.
Test and works, the only wierd thing is in some hosts the change makes no diference, still running 1 WU, even i set 0.5 or 0.33 on preferences. Any clue?
The hosts are: (one with 690+670 and the other 2x670)
The change in the settings affect the work generator, that means after you make the change, NEW work that is sent to your PC get's the info that it needs only the specified shared of a full GPU. Existing tasks that you downloaded before will not be affected.
Cheers
HB
Thanks for the info.
That radicaly different form the aproach on app_info.html, but cleary understood, will wait and see what happens after few days.
Test and works, the only wierd thing is in some hosts the change makes no diference, still running 1 WU, even i set 0.5 or 0.33 on preferences. Any clue?
The hosts are: (one with 690+670 and the other 2x670)
The change in the settings affect the work generator, that means after you make the change, NEW work that is sent to your PC get's the info that it needs only the specified shared of a full GPU. Existing tasks that you downloaded before will not be affected.
Cheers
HB
Thanks for the info.
That radicaly different form the aproach on app_info.html, but cleary understood, will wait and see what happens after few days.
Cheers
Unfortunately, it's not true. The number of WUs to run at once is specified via a setting in the segment of client_state.xml, exactly as it would be with an app_info.xml file - check client_state and sched_reply for confirmation.
Where Bikeman is right is in saying that the new data following a change is only transferred from the server to your host when new work is being allocated. Once received, however, it applies to all tasks - including tasks previously cached - assigned to the same plan_class.
All of this was fully discussed when the option to run more than one task at a time was first introduced - but at this time of night, I can't turn up the relevant thread quickly.
As always, Richard is right, sorry for the misinformation.
If you still see that the "More than one GPU task at a time" setting doesn't apply to all intended hosts, you should double check that this setting applies to all the 'venues' that you have computers for. There is an alternative view in the Project preferences web page that shows venues side by side in a tabular view which is very nice to compare settings across venues (link near top left of the view).
It would be very nice if someone of the management would create a static topic like: How To Work With More Than 1 WU At The Same Time
Compare it with the “brp cuda requirements†topic.
It avoids many questions like this thread started.
A good ideia, for most of the people BRP have no meaning, specialy the for new arrived as me, even now when i know who to use and program, does not know realy what the BRP initals realy means, try google and had no success , i get lost in the to many out of focus info.
Maybe just change the Thread title for something more easely to understand will do that easeley.
A good ideia, for most of the people BRP have no meaning, specialy the for new arrived as me, even now when i know who to use and program, does not know realy what the BRP initals realy means, try google and had no success , i get lost in the to many out of focus info.
BRP stands for Binary Radio Pulsar
you can find info about the search and latest (re-)discoveries here
RE: Test and works, the
)
The change in the settings affect the work generator, that means after you make the change, NEW work that is sent to your PC get's the info that it needs only the specified shared of a full GPU. Existing tasks that you downloaded before will not be affected.
Cheers
HB
RE: RE: Test and works,
)
Thanks for the info.
That radicaly different form the aproach on app_info.html, but cleary understood, will wait and see what happens after few days.
Cheers
RE: RE: RE: Test and
)
Unfortunately, it's not true. The number of WUs to run at once is specified via a setting in the segment of client_state.xml, exactly as it would be with an app_info.xml file - check client_state and sched_reply for confirmation.
Where Bikeman is right is in saying that the new data following a change is only transferred from the server to your host when new work is being allocated. Once received, however, it applies to all tasks - including tasks previously cached - assigned to the same plan_class.
All of this was fully discussed when the option to run more than one task at a time was first introduced - but at this time of night, I can't turn up the relevant thread quickly.
Hi! As always, Richard is
)
Hi!
As always, Richard is right, sorry for the misinformation.
If you still see that the "More than one GPU task at a time" setting doesn't apply to all intended hosts, you should double check that this setting applies to all the 'venues' that you have computers for. There is an alternative view in the Project preferences web page that shows venues side by side in a tabular view which is very nice to compare settings across venues (link near top left of the view).
Cheers
HB
Anyway thanks, all hosts
)
Anyway thanks, all hosts capable to do, are doing more than 1 WU now.
It would be very nice if
)
It would be very nice if someone of the management would create a static topic like: How To Work With More Than 1 WU At The Same Time
Compare it with the “brp cuda requirements†topic.
It avoids many questions like this thread started.
A good ideia, for most of the
)
A good ideia, for most of the people BRP have no meaning, specialy the for new arrived as me, even now when i know who to use and program, does not know realy what the BRP initals realy means, try google and had no success , i get lost in the to many out of focus info.
Maybe just change the Thread title for something more easely to understand will do that easeley.
RE: A good ideia, for most
)
BRP stands for Binary Radio Pulsar
you can find info about the search and latest (re-)discoveries here
http://einstein.phys.uwm.edu/radiopulsar/html/BRP4_discoveries/
and here http://einstein.phys.uwm.edu/radiopulsar/html/index.php
You can find more infomation about the science on the front page
http://einstein.phys.uwm.edu/, if you look for "Science information and progress reports"