I have also been seeing this behaviour over the 2 to 3 few days or so.
Here is the full message log from the last time one of my hosts contacted the server:
2012-05-17 16:45:12.8747 [PID=22609] [version] project prefs setting 'also_run_cpu' (1.000000) prevents using plan class.
2012-05-17 16:45:12.8747 [PID=22609] [version] Don't need CUDA jobs, skipping version 125 for einsteinbinary_BRP4 (BRP4cuda32)
2012-05-17 16:45:12.8748 [PID=22609] [version] no app version available: APP#19 (einsteinbinary_BRP4) PLATFORM#2 (windows_intelx86) min_version 0
2012-05-17 16:45:12.8797 [PID=22609] [send] stopping work search - no locality app selected
2012-05-17 16:45:12.8816 [PID=22609] [debug] [HOST#4876288] MSG(high) No work available for the applications you have selected. Please check your preferences on the web site.
Here is what actually happened:
- you once set not to run CPU apps where GPU apps are available, thus you didn't get BRP4 (CPU) tasks
- S6Bucket is phased out, there isn't much work available
- You never had "opted in" to run S6LV1 tasks. This isn't your fault. It's just the way how BOINC handles "app selection". If you ever once selected anything else than to run all applications, you will need to opt-in for every new app that comes out afterwards. As the default for every app is to run it, it is enough to just save your preferences (again) to propagate this default to your preferences. That's what you implicitly did when you saved your preferences after opting-out of ATI work; this switch itself shouldn't have any effect at all.
I understand and agree that this is pretty confusing, but that's how BOINC handles things. I'm not sure how much we as a project that uses BOINC can improve this.
Unlike I suspected there is no (obvious bug in the server code. The only thing is that the log / notification message is somewhat misleading. If there is work for any application version which has a limit on the Core Client version that is not satisfied by your client, you will get this message. This is slightly stupid, because this check is made before checking whether your computer can actually run that type of work or even asked for it. But the 'outdated' Client is just the reason why you don't get that particular type of work, and certainly not the reason why you don't get any work at all.
These two things I could fix: I moved the client version check last, which means that it isn't executed when the host can't run or didn't ask for that particular type of work. Also I disabled sending this particular message to the client it is more confusing than anything else. Finally I made the scheduler log message a bit more descriptive, saying that this client restriction is limited to a particular application version.
These two things I could fix: I moved the client version check last, which means that it isn't executed when the host can't run or didn't ask for that particular type of work. Also I disabled sending this particular message to the client it is more confusing than anything else. Finally I made the scheduler log message a bit more descriptive, saying that this client restriction is limited to a particular application version.
BM
Thanks, what you did stopped the 24Hs delays.
There is something Im not understanding: sometimes I see the "stopping work search - no locality app selected" message... Is this part of the "oddity of the mixed locality schedulling"?
(Its just curiosity, now that the long delay is gone, Im getting enough work for the all the selected apps.)
Thanks, that solved my issue as well. I am kind of curious and this may be completely unrelated, but could the power loss at SSL at UC-Berkeley been a problem?
Maybe, the scheduler may have been trying to use an xml application file in the berkeley.edu domain. However, since E@H server couldn't contact it, it failed over to a local copy which may have had a beta client application file.
I don't have much in the way of the exact timing of the problem. When the power outage started and when it ended and when the communication deferred issue started and ended. But it seemed like too much of a coincidence to ignore.
RE: I have also been seeing
)
Here is what actually happened:
- you once set not to run CPU apps where GPU apps are available, thus you didn't get BRP4 (CPU) tasks
- S6Bucket is phased out, there isn't much work available
- You never had "opted in" to run S6LV1 tasks. This isn't your fault. It's just the way how BOINC handles "app selection". If you ever once selected anything else than to run all applications, you will need to opt-in for every new app that comes out afterwards. As the default for every app is to run it, it is enough to just save your preferences (again) to propagate this default to your preferences. That's what you implicitly did when you saved your preferences after opting-out of ATI work; this switch itself shouldn't have any effect at all.
I understand and agree that this is pretty confusing, but that's how BOINC handles things. I'm not sure how much we as a project that uses BOINC can improve this.
BM
BM
RE: Unlike I suspected
)
These two things I could fix: I moved the client version check last, which means that it isn't executed when the host can't run or didn't ask for that particular type of work. Also I disabled sending this particular message to the client it is more confusing than anything else. Finally I made the scheduler log message a bit more descriptive, saying that this client restriction is limited to a particular application version.
BM
BM
RE: These two things I
)
Thanks, what you did stopped the 24Hs delays.
There is something Im not understanding: sometimes I see the "stopping work search - no locality app selected" message... Is this part of the "oddity of the mixed locality schedulling"?
(Its just curiosity, now that the long delay is gone, Im getting enough work for the all the selected apps.)
Thanks, that solved my issue
)
Thanks, that solved my issue as well. I am kind of curious and this may be completely unrelated, but could the power loss at SSL at UC-Berkeley been a problem?
Maybe, the scheduler may have been trying to use an xml application file in the berkeley.edu domain. However, since E@H server couldn't contact it, it failed over to a local copy which may have had a beta client application file.
I don't have much in the way of the exact timing of the problem. When the power outage started and when it ended and when the communication deferred issue started and ended. But it seemed like too much of a coincidence to ignore.