We can also make a copy of the application of 1.05 and 1.04 renamed ...
True, but why clutter your project directory with two copies (but different names) of the same app when you can simply insert the correct code in app_info.xml and have all tasks, whatever their "branding", crunched by the one true copy of the correct app?
your file can not receive ABP2 (Arecibo Pulsar Binary Search (STSP))
Perhaps he doesn't want any of those :-).
After all, there are going to be very few of these reissued in the future so even if you did want to receive them, your chance is extremely small.
Having said that, I should also add that one of my hosts did receive one about two days ago - I just happened to notice it sitting there in the cache when I (quite by chance) happened to look at the tasks on board. Each time a major run comes to an end, I usually take the trouble of setting up an appropriate app_info.xml on a certain number of hosts so that those hosts participate exclusively in the cleanup work. When the host can no longer survive on cleanup work alone, I awitch it back to normal operation. By the time that happens, the new replacement run is usually well established with any startup glitches already dealt with and out of the road :-).
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 assumptions about this are a bit different. They are just assumptions but I'll throw them into the discussion for what they're worth.
I've noticed over a period of time that you don't always get the 4 hour backoff. On some occasions, probably about 10 - 20% of the time, there is no red message suggesting that you need to delete the app_info.xml file "because it doesn't contain a version of the GW app ..." and there is no 4 hr backoff - just the normal 1 minute one. I interpret this behaviour in the following way.
The scheduler is programmed to send either GW tasks or BRP3 tasks according to a formula that favours GW over BRP3. The scheduler evaluates this formula at the time of a work request and if the result was that the scheduler was intending to send GW tasks but your app_info.xml precluded it from doing so, it will grumble about it and give you a 4 hr backoff. On the other hand for those smaller number of occasions where the scheduler was actually intending to supply BRP3 tasks, there is no complaint and no backoff - except for the normal 1 minute delay. I may be quite wrong with this assumption but that's the way it seems to me.
Another bit of evidence is that I have hosts with app_info.xml files that specify both GC1HF and BRP3. The scheduler sends GC1HF most of the time and occasionally BRP3. I don't recall ever seeing any grumbles or 4 hour backoffs with those hosts. I interpret that as meaning that the scheduler is happy because it can always send exactly what it was intending to send anyway.
It's actually quite trivial to defeat the 4 hour backoff if it's preventing you from getting more tasks when you really need more. You can click 'update' any time after the 1 minute delay and get an immediate fresh feed of tasks. You could quite easily automate this so that you didn't have to do it manually. Boinccmd is your friend :-). Google it on the BOINC website if you don't know how to use it.
Anonymous platform is the official name for the BOINC system which allows people to compile and run their own programs under BOINC. The app_info.xml file is an essential part of that process: whenever you use an app_info.xml file, you are invoking at least part of the anonymous platform framework, and the server is merely acknowledging that fact.
My assumptions about this are a bit different. They are just assumptions but I'll throw them into the discussion for what they're worth.
I've noticed over a period of time that you don't always get the 4 hour backoff. On some occasions, probably about 10 - 20% of the time, there is no red message suggesting that you need to delete the app_info.xml file "because it doesn't contain a version of the GW app ..." and there is no 4 hr backoff - just the normal 1 minute one. I interpret this behaviour in the following way.
The scheduler is programmed to send either GW tasks or BRP3 tasks according to a formula that favours GW over BRP3. The scheduler evaluates this formula at the time of a work request and if the result was that the scheduler was intending to send GW tasks but your app_info.xml precluded it from doing so, it will grumble about it and give you a 4 hr backoff. On the other hand for those smaller number of occasions where the scheduler was actually intending to supply BRP3 tasks, there is no complaint and no backoff - except for the normal 1 minute delay. I may be quite wrong with this assumption but that's the way it seems to me.
Another bit of evidence is that I have hosts with app_info.xml files that specify both GC1HF and BRP3. The scheduler sends GC1HF most of the time and occasionally BRP3. I don't recall ever seeing any grumbles or 4 hour backoffs with those hosts. I interpret that as meaning that the scheduler is happy because it can always send exactly what it was intending to send anyway.
It's actually quite trivial to defeat the 4 hour backoff if it's preventing you from getting more tasks when you really need more. You can click 'update' any time after the 1 minute delay and get an immediate fresh feed of tasks. You could quite easily automate this so that you didn't have to do it manually. Boinccmd is your friend :-). Google it on the BOINC website if you don't know how to use it.
Thanks for the info. I did add in the other apps like BRP3 CPU and APB2 to the app_info.xml but still get the 4-hour backoff. I setup a hourly update using boinccmd for now which has helped a lot with keeping the client fed with work.
I am now running into a message saying that a daily quota of 96-tasks has been reached. By my calculations, I should be able to process around 131 a day with current setup but I am not sure if there is a way around this quota.
Currently the PC shows to have a max quota of 32 tasks per CPU. I always thought that a maximum of 4 CPUs is considered for the quota calculation, which would give you 128 tasks per day. Hmm...strange.
RE: We can also make a copy
)
True, but why clutter your project directory with two copies (but different names) of the same app when you can simply insert the correct code in app_info.xml and have all tasks, whatever their "branding", crunched by the one true copy of the correct app?
Cheers,
Gary.
RE: your file can not
)
Perhaps he doesn't want any of those :-).
After all, there are going to be very few of these reissued in the future so even if you did want to receive them, your chance is extremely small.
Having said that, I should also add that one of my hosts did receive one about two days ago - I just happened to notice it sitting there in the cache when I (quite by chance) happened to look at the tasks on board. Each time a major run comes to an end, I usually take the trouble of setting up an appropriate app_info.xml on a certain number of hosts so that those hosts participate exclusively in the cleanup work. When the host can no longer survive on cleanup work alone, I awitch it back to normal operation. By the time that happens, the new replacement run is usually well established with any startup glitches already dealt with and out of the road :-).
Cheers,
Gary.
RE: RE: I'm not at all
)
My assumptions about this are a bit different. They are just assumptions but I'll throw them into the discussion for what they're worth.
I've noticed over a period of time that you don't always get the 4 hour backoff. On some occasions, probably about 10 - 20% of the time, there is no red message suggesting that you need to delete the app_info.xml file "because it doesn't contain a version of the GW app ..." and there is no 4 hr backoff - just the normal 1 minute one. I interpret this behaviour in the following way.
The scheduler is programmed to send either GW tasks or BRP3 tasks according to a formula that favours GW over BRP3. The scheduler evaluates this formula at the time of a work request and if the result was that the scheduler was intending to send GW tasks but your app_info.xml precluded it from doing so, it will grumble about it and give you a 4 hr backoff. On the other hand for those smaller number of occasions where the scheduler was actually intending to supply BRP3 tasks, there is no complaint and no backoff - except for the normal 1 minute delay. I may be quite wrong with this assumption but that's the way it seems to me.
Another bit of evidence is that I have hosts with app_info.xml files that specify both GC1HF and BRP3. The scheduler sends GC1HF most of the time and occasionally BRP3. I don't recall ever seeing any grumbles or 4 hour backoffs with those hosts. I interpret that as meaning that the scheduler is happy because it can always send exactly what it was intending to send anyway.
It's actually quite trivial to defeat the 4 hour backoff if it's preventing you from getting more tasks when you really need more. You can click 'update' any time after the 1 minute delay and get an immediate fresh feed of tasks. You could quite easily automate this so that you didn't have to do it manually. Boinccmd is your friend :-). Google it on the BOINC website if you don't know how to use it.
Cheers,
Gary.
since using the app_info file
)
since using the app_info file my status page shows anonymous platform. Where does this come from
Anonymous platform is the
)
Anonymous platform is the official name for the BOINC system which allows people to compile and run their own programs under BOINC. The app_info.xml file is an essential part of that process: whenever you use an app_info.xml file, you are invoking at least part of the anonymous platform framework, and the server is merely acknowledging that fact.
RE: Only for advanced
)
Can anybody explain this procedure step by step for people, who do not know what they do like me?
My system:
CPU: Intel i7 860
GPU: NVIDIA GeForce GTS 240 (997 MB)
Windows 7 Home x64
Where can I find the percentage of my GPU-load?
CU
Sven
Show Page
)
Show Page http://www.myfavoritegadgets.info/monitors/GPUMonitor/GPUMonitor.html
Wiki German Language, Wiki in deutscher Sprache
View
RE: My assumptions about
)
Thanks for the info. I did add in the other apps like BRP3 CPU and APB2 to the app_info.xml but still get the 4-hour backoff. I setup a hourly update using boinccmd for now which has helped a lot with keeping the client fed with work.
I am now running into a message saying that a daily quota of 96-tasks has been reached. By my calculations, I should be able to process around 131 a day with current setup but I am not sure if there is a way around this quota.
Wow, that's an impressive
)
Wow, that's an impressive host!
I brought this to the attention of the admins.
Currently the PC shows to have a max quota of 32 tasks per CPU. I always thought that a maximum of 4 CPUs is considered for the quota calculation, which would give you 128 tasks per day. Hmm...strange.
CU
HB
That` strange I have 256
)
That` strange I have 256 tasks a day quota