What I have found is, that after applying the app_info.xml file, the GPU load increases an additional bit, if you run a benchmark. The variance on the GPU load decreases from a range 48% - 99% to a range from 79 - 99% on a GT240
Why do I get this messag? New BRP Cuda tasks and GWHF tasks are still downloaded despite the message.
------ message -------------
Message from server: To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
------ message -------------
Why do I get this messag? New BRP Cuda tasks and GWHF tasks are still downloaded despite the message.
------ message -------------
Message from server: To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
------ message -------------
Don't worry. It's a feature of BOINC itself. Your client is asking certain work to do and right now (this moment) server doesn't have any suitable WU's as is written in your app_info.xml. So, the server replies back this message. It is OK. You can ask for work a minute later, just press "Refresh" button in "Projects" tab or wait alittle and client will do this itself.
Why do I get this messag? New BRP Cuda tasks and GWHF tasks are still downloaded despite the message.
------ message -------------
Message from server: To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
------ message -------------
Don't worry. It's a feature of BOINC itself. Your client is asking certain work to do and right now (this moment) server doesn't have any suitable WU's as is written in your app_info.xml. So, the server replies back this message. It is OK. You can ask for work a minute later, just press "Refresh" button in "Projects" tab or wait alittle and client will do this itself.
Actually I suspect the reason is a different one. This message will appear whenever the set of applications (including the version numbers) is different than the most up-to-date set of active apps. The app info file listed here is missing altogether the CPU version of the BRP3 app, so the BOINC server thinks: "oh oh, that host might be missing workunits because it doesn't have the most up-to-date apps in its app_info.xml file and doesn't allow to update the apps automatically" So BOINC warns you about this situation. It cannot know that you really don't want to use the CPU variant of BRP3, of course ;-)
Why do I get this messag? New BRP Cuda tasks and GWHF tasks are still downloaded despite the message.
------ message -------------
Message from server: To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
------ message -------------
I get that message also and have to do manual updates since the project says that communication is deferred for 4:00 hours after each update.
I get that message also and have to do manual updates since the project says that communication is deferred for 4:00 hours after each update.
I'm not at all convinced this is necessary. That the "communication is deferred" is normal: BOINC is just scheduling the next time it will talk to the project. If there are enough jobs left in the "cache", why should the BOINC client talk to the project anyway? Once the 4 hours have passed, BOINC will report any jobs finished in the meantime and if the "cache" needs filling, it will also ask for new tasks. Give it a try to let BOINC do the updates by itself.
I'm not at all convinced this is necessary. That the "communication is deferred" is normal: BOINC is just scheduling the next time it will talk to the project. If there are enough jobs left in the "cache", why should the BOINC client talk to the project anyway? Once the 4 hours have passed, BOINC will report any jobs finished in the meantime and if the "cache" needs filling, it will also ask for new tasks. Give it a try to let BOINC do the updates by itself.
CU
HB
What happened the last time was that I had a dozen or so work units completed at 100% but no new work came in since the counter was still counting down. At this point, the GPU would be idle due to not having new work. As soon as I hit update, new work came in. I'll give it another try though and see what happens.
My previous app_info (GC S5HF for CPU (SSE2) + 3 BRP3 cuda (1.04 + 1.05)) is working.
But the scheduler gives WU for 1.04 application.
I appreciate what you are saying but it's not quite correct. The scheduler gives out work - exactly the same for either version. Your app_info.xml file controls the version number that the work is "branded" with. As I tried to explain in my previous message, you can make sure that all tasks (even tasks "branded" as 1.04) are crunched by the V1.05 app and that new tasks are "branded" as 1.05 as soon as they arrive. The server doesn't send out tasks that are "pre-branded" for a particular app only. The "branding" is done at your end.
Quote:
Below will app_info only using 1.05
1. disable the get of new WU.
2. finish all BRP3 tasks.
3. update the project.
4. replace app_info.
5. allow to get new WU.
You don't need to do this.
Quote:
if you do not complete all 1.04BRP3 WU and replace app_info, then all 1.04BRP3 WU will be aborted.
There is a much simpler way to guarantee that no 1.04 tasks are trashed. You don't have to set NNT and wait for the cache to drain and then reconfigure your app_info.xml file. As I pointed out in my previous message, you just need to put the V1.05 specifications before the V1.04 specifications in your app_info.xml file. The order is important.
Also, if you explicitly specify that 104 tasks can be crunched by the V1.05 app, you don't need both apps to be present and you don't need any 'tricks' like having two copies of the V1.05 app with the second copy renamed as V1.04.
Please re-read my previous message and if anything is not clear, please ask.
It is no need more in ABP2
)
It is no need more in ABP2 STSP work rigs.
What I have found is, that
)
What I have found is, that after applying the app_info.xml file, the GPU load increases an additional bit, if you run a benchmark. The variance on the GPU load decreases from a range 48% - 99% to a range from 79 - 99% on a GT240
Why do I get this messag? New
)
Why do I get this messag? New BRP Cuda tasks and GWHF tasks are still downloaded despite the message.
------ message -------------
Message from server: To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
------ message -------------
RE: Why do I get this
)
Don't worry. It's a feature of BOINC itself. Your client is asking certain work to do and right now (this moment) server doesn't have any suitable WU's as is written in your app_info.xml. So, the server replies back this message. It is OK. You can ask for work a minute later, just press "Refresh" button in "Projects" tab or wait alittle and client will do this itself.
RE: RE: Why do I get this
)
Thanks for the info.
Actually I suspect the reason
)
Actually I suspect the reason is a different one. This message will appear whenever the set of applications (including the version numbers) is different than the most up-to-date set of active apps. The app info file listed here is missing altogether the CPU version of the BRP3 app, so the BOINC server thinks: "oh oh, that host might be missing workunits because it doesn't have the most up-to-date apps in its app_info.xml file and doesn't allow to update the apps automatically" So BOINC warns you about this situation. It cannot know that you really don't want to use the CPU variant of BRP3, of course ;-)
CU
HB
RE: Why do I get this
)
I get that message also and have to do manual updates since the project says that communication is deferred for 4:00 hours after each update.
RE: I get that message
)
I'm not at all convinced this is necessary. That the "communication is deferred" is normal: BOINC is just scheduling the next time it will talk to the project. If there are enough jobs left in the "cache", why should the BOINC client talk to the project anyway? Once the 4 hours have passed, BOINC will report any jobs finished in the meantime and if the "cache" needs filling, it will also ask for new tasks. Give it a try to let BOINC do the updates by itself.
CU
HB
RE: I'm not at all
)
What happened the last time was that I had a dozen or so work units completed at 100% but no new work came in since the counter was still counting down. At this point, the GPU would be idle due to not having new work. As soon as I hit update, new work came in. I'll give it another try though and see what happens.
RE: My previous app_info
)
I appreciate what you are saying but it's not quite correct. The scheduler gives out work - exactly the same for either version. Your app_info.xml file controls the version number that the work is "branded" with. As I tried to explain in my previous message, you can make sure that all tasks (even tasks "branded" as 1.04) are crunched by the V1.05 app and that new tasks are "branded" as 1.05 as soon as they arrive. The server doesn't send out tasks that are "pre-branded" for a particular app only. The "branding" is done at your end.
You don't need to do this.
There is a much simpler way to guarantee that no 1.04 tasks are trashed. You don't have to set NNT and wait for the cache to drain and then reconfigure your app_info.xml file. As I pointed out in my previous message, you just need to put the V1.05 specifications before the V1.04 specifications in your app_info.xml file. The order is important.
Also, if you explicitly specify that 104 tasks can be crunched by the V1.05 app, you don't need both apps to be present and you don't need any 'tricks' like having two copies of the V1.05 app with the second copy renamed as V1.04.
Please re-read my previous message and if anything is not clear, please ask.
Cheers,
Gary.