Hi!
I'v got this message, is there a problem?
The Server Status seams to be ok.
2009-05-04 18:17:54|Einstein@Home|Message from server: (Project has no jobs available)
The admins are looking into this, but in general the distribution of workunits is fine. Even tho you'll ghet this misleading message, you should still get fresh work.
Hi!
I'v got this message, is there a problem?
The Server Status seams to be ok.
2009-05-04 18:17:54|Einstein@Home|Message from server: (Project has no jobs available)
The admins are looking into this, but in general the distribution of workunits is fine. Even tho you'll ghet this misleading message, you should still get fresh work.
CU
Bikeman
I have been noticing this a lot. I run down to 0 jobs before I get work. I run 4 projects, all equal time, 8 day cache (2 days of work each). Einstein is always running. I have a quad-cpu with 2 cuda cards on two systems. My cuda cards run my seti projects. I run climate prediction and Einstein mainly on the cpu. Cpdn was averaging 1500 a day, but now is at over 6000.
I am down to 1 job on this system with a little over 3 hours remaining. Of course CPDN is running 3 jobs.
I have been noticing this a lot. I run down to 0 jobs before I get work. I run 4 projects, all equal time, 8 day cache (2 days of work each).
This is quite different to the situation where the server actually sends work but then claims it has none. Your situation is most likely due to the difficulty that BOINC would be having trying to honour your resource shares with an 8 day cache. You are wrong to assume that 4 equal projects and an 8 day cache always means 2 days each. There will be times when some of your projects will have way more than 2 days of work stored up. If any one project can't supply work when BOINC requests it, the next project in line may very well supply the entire shortfall and so you end up with a large overfetch for that project. You can also get overfetching due to bugs in various versions of BOINC. You are likely to get much smoother behaviour if you set your cache size to around 2-3 days maximum.
Your large (8 day) cache size is a recipe for exactly what you are seeing - periods where BOINC doesn't want to get work because that project has already had more than its fair share for the moment. I see your two hosts now have plenty of EAH tasks each so BOINC must have decided that whatever project needed to be paid back has now had enough and new work for EAH is again appropriate.
Quote:
I am down to 1 job on this system with a little over 3 hours remaining. Of course CPDN is running 3 jobs.
Is CPDN in deadline trouble? Were you sent extra CPDN tasks because other projects couldn't supply at some point?
EDIT: You might care to look at this message from Richard Haselgrove about the work fetch bugs in what appears to be the version of BOINC you are using. I have no experience with any BOINC version later than 6.2.x. Richard has also included some information about the new properties page a couple of posts after (more recent than) the one I linked.
What looks odd to me is that your client isn't asking for a specific amount of work. Every client I've used (all wintel) has. I am however seeing the no jobs available message along with the last few successful E@H WU requests despite being geven enough work to meet my requests. The last two requests were manual, the two E@H requests before were triggered automatically.
11-May-2009 17:32:30 [Einstein@Home] Sending scheduler request: To fetch work. Requesting 72 seconds of work, reporting 0 completed tasks
11-May-2009 17:32:35 [Einstein@Home] Scheduler request completed: got 1 new tasks
11-May-2009 17:32:35 [Einstein@Home] Message from server: (Project has no jobs available)
11-May-2009 17:33:35 [Einstein@Home] Sending scheduler request: To fetch work. Requesting 216 seconds of work, reporting 0 completed tasks
11-May-2009 17:33:40 [Einstein@Home] Scheduler request completed: got 1 new tasks
11-May-2009 17:33:40 [Einstein@Home] Message from server: (Project has no jobs available)
11-May-2009 17:40:43 [GPUGRID] Sending scheduler request: Requested by user. Requesting 25651 seconds of work, reporting 1 completed tasks
11-May-2009 17:40:48 [GPUGRID] Scheduler request completed: got 0 new tasks
11-May-2009 17:40:48 [GPUGRID] Message from server: No work sent
11-May-2009 17:40:48 [GPUGRID] Message from server: Full-atom molecular dynamics on Cell processor is not available for your type of computer.
11-May-2009 17:40:48 [GPUGRID] Message from server: (won't finish in time) BOINC runs 99.9% of time, computation enabled 100.0% of that
11-May-2009 17:50:11 [Einstein@Home] Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
11-May-2009 17:50:16 [Einstein@Home] Scheduler request completed: got 0 new tasks
(PS The won't finish in time GPUgrid message is because I've got it set to a 1% share despite being my only GPU app because it gives a bonus for fast WU returns, and I want to keep its queue minimal as a result)
They didn't take it out, but classed it as "low level messages", not needed to confuse the user with. So it has to be enabled in cc_config.xml with the option... which on the downside that this option will add a lot more crud for the user to filter through. ;-)
They didn't take it out, but classed it as "low level messages", not needed to confuse the user with. So it has to be enabled in cc_config.xml with the option... which on the downside that this option will add a lot more crud for the user to filter through. ;-)
It can also be made visible with the flag, as noted in the post of mine that Gary linked yesterday.
But neither flag is retrospective: you can't use them after the event to work out what happened, and whether it should have happened or not.
Instead, you either have to be telepathic - know in advance that a problem is going to happen, and enable logging to capture it: or enable logging afterwards, and hope that it happens again - which implies that you have a pretty good idea what it is you're looking for. That's helpful for convincing a skeptical audience, but not much use for inital diagnosis.
Or you can encourage all users to run in debug mode all the time, which is hardly efficient or less 'confusing' for the average user.
Message from server: (Project has no jobs available)
)
The admins are looking into this, but in general the distribution of workunits is fine. Even tho you'll ghet this misleading message, you should still get fresh work.
CU
Bikeman
RE: RE: Hi! I'v got this
)
I have been noticing this a lot. I run down to 0 jobs before I get work. I run 4 projects, all equal time, 8 day cache (2 days of work each). Einstein is always running. I have a quad-cpu with 2 cuda cards on two systems. My cuda cards run my seti projects. I run climate prediction and Einstein mainly on the cpu. Cpdn was averaging 1500 a day, but now is at over 6000.
I am down to 1 job on this system with a little over 3 hours remaining. Of course CPDN is running 3 jobs.
Thanks
This is what I am
)
This is what I am seeing.
5/10/2009 11:00:11 PM Einstein@Home Sending scheduler request: To fetch work.
5/10/2009 11:00:11 PM Einstein@Home Requesting new tasks
5/10/2009 11:00:21 PM Einstein@Home Scheduler request completed: got 0 new tasks
5/10/2009 11:00:21 PM Einstein@Home Message from server: No work sent
5/10/2009 11:02:24 PM Einstein@Home Sending scheduler request: To fetch work.
5/10/2009 11:02:24 PM Einstein@Home Requesting new tasks
5/10/2009 11:02:34 PM Einstein@Home Scheduler request completed: got 0 new tasks
5/10/2009 11:02:34 PM Einstein@Home Message from server: No work sent
5/10/2009 11:06:36 PM Einstein@Home Sending scheduler request: To fetch work.
5/10/2009 11:06:36 PM Einstein@Home Requesting new tasks
5/10/2009 11:06:46 PM Einstein@Home Scheduler request completed: got 0 new tasks
5/10/2009 11:06:46 PM Einstein@Home Message from server: No work sent
5/10/2009 11:09:48 PM Einstein@Home Sending scheduler request: To fetch work.
5/10/2009 11:09:48 PM Einstein@Home Requesting new tasks
5/10/2009 11:09:58 PM Einstein@Home Scheduler request completed: got 0 new tasks
5/10/2009 11:09:58 PM Einstein@Home Message from server: No work sent
RE: I have been noticing
)
This is quite different to the situation where the server actually sends work but then claims it has none. Your situation is most likely due to the difficulty that BOINC would be having trying to honour your resource shares with an 8 day cache. You are wrong to assume that 4 equal projects and an 8 day cache always means 2 days each. There will be times when some of your projects will have way more than 2 days of work stored up. If any one project can't supply work when BOINC requests it, the next project in line may very well supply the entire shortfall and so you end up with a large overfetch for that project. You can also get overfetching due to bugs in various versions of BOINC. You are likely to get much smoother behaviour if you set your cache size to around 2-3 days maximum.
Your large (8 day) cache size is a recipe for exactly what you are seeing - periods where BOINC doesn't want to get work because that project has already had more than its fair share for the moment. I see your two hosts now have plenty of EAH tasks each so BOINC must have decided that whatever project needed to be paid back has now had enough and new work for EAH is again appropriate.
Is CPDN in deadline trouble? Were you sent extra CPDN tasks because other projects couldn't supply at some point?
EDIT: You might care to look at this message from Richard Haselgrove about the work fetch bugs in what appears to be the version of BOINC you are using. I have no experience with any BOINC version later than 6.2.x. Richard has also included some information about the new properties page a couple of posts after (more recent than) the one I linked.
Cheers,
Gary.
What looks odd to me is that
)
What looks odd to me is that your client isn't asking for a specific amount of work. Every client I've used (all wintel) has. I am however seeing the no jobs available message along with the last few successful E@H WU requests despite being geven enough work to meet my requests. The last two requests were manual, the two E@H requests before were triggered automatically.
11-May-2009 17:32:30 [Einstein@Home] Sending scheduler request: To fetch work. Requesting 72 seconds of work, reporting 0 completed tasks
11-May-2009 17:32:35 [Einstein@Home] Scheduler request completed: got 1 new tasks
11-May-2009 17:32:35 [Einstein@Home] Message from server: (Project has no jobs available)
11-May-2009 17:33:35 [Einstein@Home] Sending scheduler request: To fetch work. Requesting 216 seconds of work, reporting 0 completed tasks
11-May-2009 17:33:40 [Einstein@Home] Scheduler request completed: got 1 new tasks
11-May-2009 17:33:40 [Einstein@Home] Message from server: (Project has no jobs available)
11-May-2009 17:40:43 [GPUGRID] Sending scheduler request: Requested by user. Requesting 25651 seconds of work, reporting 1 completed tasks
11-May-2009 17:40:48 [GPUGRID] Scheduler request completed: got 0 new tasks
11-May-2009 17:40:48 [GPUGRID] Message from server: No work sent
11-May-2009 17:40:48 [GPUGRID] Message from server: Full-atom molecular dynamics on Cell processor is not available for your type of computer.
11-May-2009 17:40:48 [GPUGRID] Message from server: (won't finish in time) BOINC runs 99.9% of time, computation enabled 100.0% of that
11-May-2009 17:50:11 [Einstein@Home] Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
11-May-2009 17:50:16 [Einstein@Home] Scheduler request completed: got 0 new tasks
(PS The won't finish in time GPUgrid message is because I've got it set to a 1% share despite being my only GPU app because it gives a bonus for fast WU returns, and I want to keep its queue minimal as a result)
RE: What looks odd to me is
)
That's what's known as progress in the development world. They took it out - deliberately - from the latest versions. Most unhelpful, in my view.
They didn't take it out, but
)
They didn't take it out, but classed it as "low level messages", not needed to confuse the user with. So it has to be enabled in cc_config.xml with the option... which on the downside that this option will add a lot more crud for the user to filter through. ;-)
RE: They didn't take it
)
It can also be made visible with the flag, as noted in the post of mine that Gary linked yesterday.
But neither flag is retrospective: you can't use them after the event to work out what happened, and whether it should have happened or not.
Instead, you either have to be telepathic - know in advance that a problem is going to happen, and enable logging to capture it: or enable logging afterwards, and hope that it happens again - which implies that you have a pretty good idea what it is you're looking for. That's helpful for convincing a skeptical audience, but not much use for inital diagnosis.
Or you can encourage all users to run in debug mode all the time, which is hardly efficient or less 'confusing' for the average user.
RE: Instead, you either
)
Aren't you? No feelings of clairvoyance? Never had a déjà vu while running BOINC?
Constantly here. :D
My computer is idle...
)
My computer is idle... :(
03/05/2009 05:44:54||Starting BOINC client version 6.2.14 for windows_intelx86
03/05/2009 05:44:54||log flags: task, file_xfer, sched_ops
03/05/2009 05:44:54||Libraries: libcurl/7.18.0 OpenSSL/0.9.8e zlib/1.2.3
03/05/2009 05:44:54||Data directory: C:\Program Files\BOINC_Data
03/05/2009 05:44:54||Running under account Olenenok
03/05/2009 05:44:54||Processor: 2 GenuineIntel Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz [x86 Family 6 Model 15 Stepping 11]
03/05/2009 05:44:54||Processor features: fpu tsc pae nx sse sse2 mmx
03/05/2009 05:44:54||OS: Microsoft Windows XP: Professional Edition, Service Pack 2, (05.01.2600.00)
03/05/2009 05:44:54||Memory: 1.99 GB physical, 3.83 GB virtual
03/05/2009 05:44:54||Disk: 32.00 GB total, 13.79 GB free
03/05/2009 05:44:54||Local time is UTC +4 hours
03/05/2009 05:44:54||No coprocessors
03/05/2009 05:44:54|DrugDiscovery|URL: http://boinc.drugdiscoveryathome.com/; Computer ID: 12; location: (none); project prefs: default
03/05/2009 05:44:54|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 1593201; location: home; project prefs: default
03/05/2009 05:44:54|lhcathome|URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: 9708244; location: home; project prefs: default
...
...
19/05/2009 07:25:39|Einstein@Home|Sending scheduler request: To fetch work. Requesting 60480 seconds of work, reporting 0 completed tasks
19/05/2009 07:25:44|Einstein@Home|Scheduler request succeeded: got 0 new tasks
19/05/2009 07:25:44|Einstein@Home|Message from server: No work sent
19/05/2009 07:25:44|Einstein@Home|Message from server: (reached daily quota of 2 results)
19/05/2009 07:25:44|Einstein@Home|Message from server: (Project has no jobs available)