.... You can really see the project "slowing down" since the 3's gave way to the 4's.
Almost returning to 'normal' would probably be a better description :-).
The search (on GPUs) for pulsars emitting at gamma ray frequencies has been going on for many years and the long term average for task elapsed times was traditionally even slightly longer than for the current batch. It's only fairly recently that we've seen batches of tasks with these variable and somewhat shorter run times.
I have GPUs (AMD HD7850s) that have crunched these tasks continuously so I get to notice the variations as they unfold.
FWIW, my 2070 Super (X2) are doing 322 per day, or 161 each.
That works out to ~8:56 per task, but my BOINC Manager is showing ~8:19 to ~8:22 per task. I need to work on this, I'm sure they should do better than that.
...[EDIT]...
If I recall correctly, they used to do a GPU task in ~6:00 to ~6:15, but that was a different task description. But then again, I just may be dreaming.
...[EDIT]...
I'm talking about the current batch of LATeah4011L01 tasks which I'm doing well over 8 min per task.
I think you should ask from Ian & Steve to help you to get them jobs flying with your hard ware. He's twiddling with his own constantly and everyone can see it!
do we know the allotment per CPU core and per GPU?
Yes we do.
32 tasks/day for each CPU, plus 256 for each GPU.
But if you limit what fraction of your CPUs are allowed for BOINC to consider as available for use using the Preferences|Advanced Settings|Processor Usage|
Use at most nn% of the processors
mechanism, that cuts the count for daily task download quota purposes.
I just ran into this issue again (the 512 quota). So, if I only want to use 8 physical processors, I'm only going to get 512 work units a day. (8*32)+(256*1). No matter what I tell it in cc_config.xml. I'm currently chewing through 480 GPU work units a day by running two work units in parallel on one GPU and 2 CPUs, plus about 40 CPU work units per day. on the remaining 6 physical CPUs. Is there just no way to keep this computer running 24X7? Is there some way to fool the quota system into thinking I have two GPU's?
you need to increase the ncpus value in cc_config like arch explained in the second post.
then change your compute preferences (lower the CPU use %) to prevent jobs running on the "phantom" CPU cores. or use a project_max_concurrent line in an app_config file to restrict how many tasks run.
I just ran into this issue again (the 512 quota). So, if I only want to use 8 physical processors, I'm only going to get 512 work units a day. (8*32)+(256*1). No matter what I tell it in cc_config.xml.
In addition to core client configuration (cc_config.xml) there is a separate file you migh use for Project-level configuration. It's called app_config.xml and you install it in the project directory (einstein.phys.uwm.edu). Its typical use is for specifying fractional CPU and GPU values for budgeting purposes when running concurrent GPU tasks.
I don't use CPUs for crunching so if I set ncpus to some fictitious value, it doesn't create any problem for me. In your case, doubling the value would double the number of CPU tasks attempting to run. As a further work-around that might work (I don't know - I've never tried it) for a situation with 8 real cores, you could try setting ncpus to 16 in cc_config.xml (and still allowing BOINC to use 100% of the cores) whilst simultaneously having an app_config.xml file specifying the CPU app you are running with a max_concurrent setting having a value of 8. It would be interesting to know if that worked :-).
Unfortunately, I don't know of a way to fudge the number of GPUs.
then change your compute preferences (lower the CPU use %) to prevent jobs running on the "phantom" CPU cores
That does not work, as I explained in my post, and the OP reported in his experience.
can you explain why this wont work? the cpu use% isn't communicated back to the Project, it's used locally in the boinc software to calculate how many CPUs are used for running jobs.
Does anyone reading here know any other mechanism for limiting actual CPU tasks active which might somehow duck around this problem?
limiting CPU use percentage, or limiting runnable jobs via app_config with <project_max_concurrent> or <max_concurrent> (see BOINC Client configuration docs for usage between them) are the only ways to limit CPU jobs in BOINC.
I have several ways to fudge GPU numbers, and one of them that doesn't even require custom software, but it's probably best if I don't post it, to prevent the pitchforks from coming out :D
I'll just say that the way BOINC knows how many GPUs you have is based solely on the contents of your coproc_info.xml file... if you have duplicate entries, and BOINC doesn't have permission to change the file at startup, it'll be forced to believe the contents ;)
(you'll still need some max_concurrent line in app_config to prevent phantom jobs from running on GPUs that don't exist)
Well, I think I might have found a bug/loophole. I ran up against the 512 quota again (happens same time every day). I went to the project preferences web page and changed Resource Share from 100 to 50. Einstein is my only BOINC client. I went to the BOINC Manager project tab and hit update. The scheduler immediately requested new GPU tasks and downloaded 16 in the first batch and 11 more a minute later. I'll keep an eye on it and see what else happens.
Burned wrote:.... You can
)
Almost returning to 'normal' would probably be a better description :-).
The search (on GPUs) for pulsars emitting at gamma ray frequencies has been going on for many years and the long term average for task elapsed times was traditionally even slightly longer than for the current batch. It's only fairly recently that we've seen batches of tasks with these variable and somewhat shorter run times.
I have GPUs (AMD HD7850s) that have crunched these tasks continuously so I get to notice the variations as they unfold.
Cheers,
Gary.
GWGeorge007 wrote: FWIW, my
)
I think you should ask from Ian & Steve to help you to get them jobs flying with your hard ware. He's twiddling with his own constantly and everyone can see it!
I've done that. I've been there. I've seen it!
It may not be that hard. Imagine the rest of it!
Continue with flying colours!
archae86 wrote: Ian&Steve C.
)
I just ran into this issue again (the 512 quota). So, if I only want to use 8 physical processors, I'm only going to get 512 work units a day. (8*32)+(256*1). No matter what I tell it in cc_config.xml. I'm currently chewing through 480 GPU work units a day by running two work units in parallel on one GPU and 2 CPUs, plus about 40 CPU work units per day. on the remaining 6 physical CPUs. Is there just no way to keep this computer running 24X7? Is there some way to fool the quota system into thinking I have two GPU's?
you need to increase the
)
you need to increase the ncpus value in cc_config like arch explained in the second post.
then change your compute preferences (lower the CPU use %) to prevent jobs running on the "phantom" CPU cores. or use a project_max_concurrent line in an app_config file to restrict how many tasks run.
_________________________________________________________________________
Burned wrote:I just ran into
)
In addition to core client configuration (cc_config.xml) there is a separate file you migh use for Project-level configuration. It's called app_config.xml and you install it in the project directory (einstein.phys.uwm.edu). Its typical use is for specifying fractional CPU and GPU values for budgeting purposes when running concurrent GPU tasks.
I don't use CPUs for crunching so if I set ncpus to some fictitious value, it doesn't create any problem for me. In your case, doubling the value would double the number of CPU tasks attempting to run. As a further work-around that might work (I don't know - I've never tried it) for a situation with 8 real cores, you could try setting ncpus to 16 in cc_config.xml (and still allowing BOINC to use 100% of the cores) whilst simultaneously having an app_config.xml file specifying the CPU app you are running with a max_concurrent setting having a value of 8. It would be interesting to know if that worked :-).
Unfortunately, I don't know of a way to fudge the number of GPUs.
Cheers,
Gary.
Ian&Steve C. wrote:then
)
That does not work, as I explained in my post, and the OP reported in his experience.
That seems worth trying.
Does anyone reading here know any other mechanism for limiting actual CPU tasks active which might somehow duck around this problem?
archae86 wrote: Ian&Steve C.
)
can you explain why this wont work? the cpu use% isn't communicated back to the Project, it's used locally in the boinc software to calculate how many CPUs are used for running jobs.
_________________________________________________________________________
archae86 wrote:Does anyone
)
limiting CPU use percentage, or limiting runnable jobs via app_config with <project_max_concurrent> or <max_concurrent> (see BOINC Client configuration docs for usage between them) are the only ways to limit CPU jobs in BOINC.
_________________________________________________________________________
I have several ways to fudge
)
I have several ways to fudge GPU numbers, and one of them that doesn't even require custom software, but it's probably best if I don't post it, to prevent the pitchforks from coming out :D
I'll just say that the way BOINC knows how many GPUs you have is based solely on the contents of your coproc_info.xml file... if you have duplicate entries, and BOINC doesn't have permission to change the file at startup, it'll be forced to believe the contents ;)
(you'll still need some max_concurrent line in app_config to prevent phantom jobs from running on GPUs that don't exist)
_________________________________________________________________________
Well, I think I might have
)
Well, I think I might have found a bug/loophole. I ran up against the 512 quota again (happens same time every day). I went to the project preferences web page and changed Resource Share from 100 to 50. Einstein is my only BOINC client. I went to the BOINC Manager project tab and hit update. The scheduler immediately requested new GPU tasks and downloaded 16 in the first batch and 11 more a minute later. I'll keep an eye on it and see what else happens.