12/31/2021 2:08:13 PM | Einstein@Home | Sending scheduler request: Requested by user.
12/31/2021 2:08:13 PM | Einstein@Home | Requesting new tasks for NVIDIA GPU
12/31/2021 2:08:16 PM | Einstein@Home | Scheduler request completed: got 0 new tasks
12/31/2021 2:08:16 PM | Einstein@Home | No work sent
12/31/2021 2:08:16 PM | Einstein@Home | No work is available for Binary Radio Pulsar Search (Arecibo)
12/31/2021 2:08:16 PM | Einstein@Home | No work is available for Binary Radio Pulsar Search (Arecibo, GPU)
12/31/2021 2:08:16 PM | Einstein@Home | No work is available for Gamma-ray pulsar search #5
12/31/2021 2:08:16 PM | Einstein@Home | No work is available for Gamma-ray pulsar binary search #1 on GPUs
12/31/2021 2:08:16 PM | Einstein@Home | (reached daily quota of 704 tasks)
12/31/2021 2:08:16 PM | Einstein@Home | Project has no jobs available
How come there is a limit of 704 task per day? My computer can crunch more than that. See below:
ID: 12095349 Details | Tasks Cross-project stats: 2 1,695,617.85 363,068,458 7.16.20 GenuineIntel Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz [Family 6 Model 63 Stepping 2] (12 processors) [2] NVIDIA NVIDIA GeForce RTX 2080 Ti (4095MB) driver: 471.11 Microsoft Windows 10 Professional x64 Edition, (10.00.18363.00)
Copyright © 2024 Einstein@Home. All rights reserved.
Einstein allocates 32 tasks
)
Einstein allocates 32 tasks per CPU thread, and 256 tasks per GPU.
(32*12)+(2*256) = 896. but it also factors in your compute settings for the CPU (using less CPU means you are allocated less). to get to 704 tasks, I'm guessing you have your "use at most % CPU" setting to 50%.
you can increase this to 100% to get up to 896. or you can set the <ncpus> flag in your cc_config.xml file to make boinc think you have more CPU cores than you do, then limit CPU use with a <max_concurrent> or <project_max_concurrent> flag in the appropriate app_config.xml file for the project that you want to limit CPU use on.
_________________________________________________________________________
Just for completeness, in
)
Just for completeness, in case someone gets to this thread by title or by search, I'll mention that your quota is temporarily reduced for errors. However this reduction is very, very rapidly retired with successful work returns. As I saw no errors at all in a glance at the task list for the Original Poster, this point has no bearing on his current situation.
One last point--"Errors" here does not mean WU's returned successfully but judged to be invalid. The two most common ways people get enough of them to get a meaningful quota reduction are either to abort a large number of tasks or to suffer a host abnormality which suddenly starts running tasks in rapid sequence, with all terminating very early. That one happened to me recently, and it consumed my entire onboard queue, and my entire daily quota, so even after I rebooted meant I could not fetch work again until the "day" had turned to a new one. In my case that turned out to be midnight one time zone east of Newfoundland on that occasion. I've never seen it be midnight of any of the three of UTC, my own time zone, nor Berkeley. One of BOINC's little mysteries, that.
Regarding when a "new day"
)
Regarding when a "new day" occurs, I would state it isn't a BOINC mystery, rather an Einstein one.
I thing Einstein picks some quantum state time zone somewhere between the three Einstein download servers which occupy different geographical locations.
</p> <pre> 2022-01-26
)
Yeah, I know, mixing CPU and GPU tasks causes problems like this (above) but I was running a mix in a stable configuration for many months. Then, upon upgrading the boinc client from 7.14 to 7.16, I did a Project Reset. I knew that would erase the project's knowledge of my CPU and GPU work-unit performance but was prepared for some instability until new numbers would be derived. The initial (after Reset) download batch was entirely CPU work, and seriously overcommitted as well. I aborted only as many as necessary to let the CPU finish as many as possible before deadline. That process finished yesterday. Made a minor(?) change to the app_config.xml, adjusting project_max_concurrent from 8 down to 5; re-read config files and all appeared to be normal, with work fetch resumed and GPU tasks also being downloaded. I did not notice until this morning that work fetches were taking place every 60 seconds and 3 or 4 CPU tasks downloaded at each instance - until the daily quota of 512 was reached during the night. OBTW, cache parameters are 0.3 + 0.1 day.
I only know of two recovery strategies: (1) abort nearly all the buffered tasks down to a manageable number; or (2) let boinc run until tasks are automatically aborted for not being started before the deadline. Wing-persons probably prefer #1 but, from a project scheduler point of view, would #2 lead more quickly to a balance of downloaded work and the 0.3 day buffer parameter?
In the host log (above) I am puzzled by "max jobs on host cpu 999999". Is that just a place-holder until the project scheduler calculates a value for this host?
Hindsight is wonderful... I should have enabled new tasks only occasionally, and briefly, to let the task run-time history statistics rebuild.