Thanks. Your improvement is probably due to the number of cores. I will be able to do two i7-4771 cores on the Windows machine, which should allow two work units; maybe three. It will take cooler weather before I can get serious about it.
Thanks. Your improvement is probably due to the number of cores.
The processing speed of the core supporting GW probably also matters quite a bit. This is very different from the Einstein GRP GPU situation, where rather modest and elderly processors sitting on motherboards with unimpressive grades of PCI-e can happily support a pretty high-grade GPU.
The GW task needs a lot more CPU support, and during the initial phase the CPU is doing nearly all the work, so a slower CPU will definitely give longer task elapsed times than a faster one. This also means there is probably a detectable benefit to fiddling things so that the starting times of the multiple GW GPU tasks one is running are spaced apart.
I allow Pulsars to download when GWs aren't available and I keep getting some pulsars. This is causing my RAC not to drop as fast as an all GW diet would give me. I want to find a GW and I consider Pulsars to be 2nd prize. Oh well I shall crunch on.
I allow Pulsars to download when GWs aren't available and I keep getting some pulsars. This is causing my RAC not to drop as fast as an all GW diet would give me. I want to find a GW and I consider Pulsars to be 2nd prize. Oh well I shall crunch on.
Not sure about this project, but I've found both LHC and Milkyway to ignore certain settings in your server preferences.
For example in LHC, if you tick next to "Run only the selected applications", "Atlas". Then tick "If no work for selected applications is available, accept work from other applications?" then you will get nothing but Theory tasks, even though there are plenty Atlas all the time. When I inquired about it, they said something about whatever is in the RAM buffer gets priority. I can only assume a lot of folk take Atlas only, so there's way too many Theories waiting.
And in Milkyway, they have "Seperation" tasks that run on GPU or CPU (with GPU being phenominally faster), and Nbody tasks that run on only CPU. I have 4 machines with a GPU and CPU and obviously wanted to run Seperation on the GPUs and Nbody on the CPUs, but that's not possible! I can't deny it to download Seperation, as the GPU needs it, so I have to say I only want Nbody but allow from other applications if necessary. I still get Seperation on the CPU.
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
I've been monitoring memory usages of the Spotlight tasks on my Linux systems. One host has a couple RX 570s running at 3X concurrent tasks, the other an RX 5600xt running at 4X. So far, tasks have had a delta frequency (DF) of 0.10 to 0.30. (For background on DF for O2MDF tasks, see this post and neighboring posts in the "All Things Navi 10" forum."
It is only with tasks with a DF of 0.20, however, that I see a progressive increase in VRAM requirement to run them. When a series of runs for DF 0.20 tasks first begins, each task uses 0.75 GB VRAM. Over the next 45 - 60 minutes VRAM need rises gradually to 1.16 GB/task. I haven't seen an increase over that level yet, probably because the tasks by then switch out to other DF classes that have lower or equal VRAM requirements. All other groups of tasks with different DFs maintain over time whatever VRAM requirement they start out with. Has anyone else observed this?
As an aside, has anyone picked up tasks of DF 0.35 or higher? Has anyone measured the VRAM usage of those?
Ideas are not fixed, nor should they be; we live in model-dependent reality.
I've not learned anything further about VRAM requirements, but I've noticed a thing or two about CPU usage.
I currently run GW GPU tasks on one system which has a heavily power limited (-50%) RX5700 GPU and fairly modest dual-core i3-4130 hyperthreaded CPU. I run GW tasks at 2X and no other distributed computing work.
The actual elapsed times for individual tasks don't vary all that much. A fairly typical elapsed time is 18 minutes. But the CPU time shows some large systematic variation.
Recently it ran down a long string of consecutive issue number tasks at DF 0.10 getting to the bottom of base frequency 0214.85. These generally were reported as using CPU at a 89% rate, with remarkably little variation.
The preceding batch of tasks from the same base frequency at DF 0.15 only consumed CPU at 65% rate.
The next batch of tasks from the base frequency 214.90 at DF of 0.25 show somewhat more CPU usage variability, but are heavily centered near 45%. So nearly a factor of two difference in CPU needs.
My main point is a caution: performance findings need to consider a range of tasks, or risk confounding systematic changes in task requirements with changes in system configuration.
All of these tasks use a lot more CPU support than I see on Einstein GRP, and the high end is quite high indeed.
I've just picked up some DF 0.35 tasks (272.55Hz base) and I show them using 1.14 GB of VRAM.
Good, thanks. Yes, I too picked up some of those last night. I'm seeing ~1.25 VRAM usage (263.35 Hz base) on my system. 1.14 GB is what I see for 0.25 DF tasks.
Looks like it will be awhile before we see the full range of task DF classes. I'm curious whether the DF breakpoints between notable changes in VRAM demands will be the same as with the VelaJr. data series.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
That intermittent VRAM requirement of DF 0.20 tasks is back, so nothing has been 'cured'. I've since learned that VRAM usages of that DF class are bound between ~ 0.70 GB and 1.15 GB, which coincide with the stable VRAM requirements of the DF 0.15 and 0.25 tasks, respectively. DF 0.20 tasks that use the higher VRAM take longer to complete than those with the lower VRAM.
These VRAM variations can happen in the middle of a task series of consecutive workunit indices for the same parent frequency. For example, from workunit ID h1_0235.75_O2C02Cl4In0__O2MDFS2_Spotlight_235.95Hz_235 through to h1_..._160, task times averaged 6:05 and used 0.69 GB VRAM. From ..._159 to ... _153, task times averaged 9:05 and used ~1.13 GB VRAM. Workunit IDs that precede _153 in the series returned to taking ~ 6 min to complete with lower VRAM (on a RX 5600 XT running @ 4X). How odd. The rest of that workunit series is currently running.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Thanks. Your improvement is
)
Thanks. Your improvement is probably due to the number of cores. I will be able to do two i7-4771 cores on the Windows machine, which should allow two work units; maybe three. It will take cooler weather before I can get serious about it.
Jim1348 wrote:Thanks. Your
)
The processing speed of the core supporting GW probably also matters quite a bit. This is very different from the Einstein GRP GPU situation, where rather modest and elderly processors sitting on motherboards with unimpressive grades of PCI-e can happily support a pretty high-grade GPU.
The GW task needs a lot more CPU support, and during the initial phase the CPU is doing nearly all the work, so a slower CPU will definitely give longer task elapsed times than a faster one. This also means there is probably a detectable benefit to fiddling things so that the starting times of the multiple GW GPU tasks one is running are spaced apart.
I allow Pulsars to download
)
I allow Pulsars to download when GWs aren't available and I keep getting some pulsars. This is causing my RAC not to drop as fast as an all GW diet would give me. I want to find a GW and I consider Pulsars to be 2nd prize. Oh well I shall crunch on.
Betreger wrote: I allow
)
Not sure about this project, but I've found both LHC and Milkyway to ignore certain settings in your server preferences.
For example in LHC, if you tick next to "Run only the selected applications", "Atlas". Then tick "If no work for selected applications is available, accept work from other applications?" then you will get nothing but Theory tasks, even though there are plenty Atlas all the time. When I inquired about it, they said something about whatever is in the RAM buffer gets priority. I can only assume a lot of folk take Atlas only, so there's way too many Theories waiting.
And in Milkyway, they have "Seperation" tasks that run on GPU or CPU (with GPU being phenominally faster), and Nbody tasks that run on only CPU. I have 4 machines with a GPU and CPU and obviously wanted to run Seperation on the GPUs and Nbody on the CPUs, but that's not possible! I can't deny it to download Seperation, as the GPU needs it, so I have to say I only want Nbody but allow from other applications if necessary. I still get Seperation on the CPU.
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
I've been monitoring memory
)
I've been monitoring memory usages of the Spotlight tasks on my Linux systems. One host has a couple RX 570s running at 3X concurrent tasks, the other an RX 5600xt running at 4X. So far, tasks have had a delta frequency (DF) of 0.10 to 0.30. (For background on DF for O2MDF tasks, see this post and neighboring posts in the "All Things Navi 10" forum."
It is only with tasks with a DF of 0.20, however, that I see a progressive increase in VRAM requirement to run them. When a series of runs for DF 0.20 tasks first begins, each task uses 0.75 GB VRAM. Over the next 45 - 60 minutes VRAM need rises gradually to 1.16 GB/task. I haven't seen an increase over that level yet, probably because the tasks by then switch out to other DF classes that have lower or equal VRAM requirements. All other groups of tasks with different DFs maintain over time whatever VRAM requirement they start out with. Has anyone else observed this?
As an aside, has anyone picked up tasks of DF 0.35 or higher? Has anyone measured the VRAM usage of those?
Ideas are not fixed, nor should they be; we live in model-dependent reality.
I've not learned anything
)
I've not learned anything further about VRAM requirements, but I've noticed a thing or two about CPU usage.
I currently run GW GPU tasks on one system which has a heavily power limited (-50%) RX5700 GPU and fairly modest dual-core i3-4130 hyperthreaded CPU. I run GW tasks at 2X and no other distributed computing work.
The actual elapsed times for individual tasks don't vary all that much. A fairly typical elapsed time is 18 minutes. But the CPU time shows some large systematic variation.
Recently it ran down a long string of consecutive issue number tasks at DF 0.10 getting to the bottom of base frequency 0214.85. These generally were reported as using CPU at a 89% rate, with remarkably little variation.
The preceding batch of tasks from the same base frequency at DF 0.15 only consumed CPU at 65% rate.
The next batch of tasks from the base frequency 214.90 at DF of 0.25 show somewhat more CPU usage variability, but are heavily centered near 45%. So nearly a factor of two difference in CPU needs.
My main point is a caution: performance findings need to consider a range of tasks, or risk confounding systematic changes in task requirements with changes in system configuration.
All of these tasks use a lot more CPU support than I see on Einstein GRP, and the high end is quite high indeed.
cecht wrote:As an aside, has
)
I've just picked up some DF 0.35 tasks (272.55Hz base) and I show them using 1.14 GB of VRAM.
Holmis wrote:I've just picked
)
Good, thanks. Yes, I too picked up some of those last night. I'm seeing ~1.25 VRAM usage (263.35 Hz base) on my system. 1.14 GB is what I see for 0.25 DF tasks.
Looks like it will be awhile before we see the full range of task DF classes. I'm curious whether the DF breakpoints between notable changes in VRAM demands will be the same as with the VelaJr. data series.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
cecht wrote:It is only with
)
This no longer is an issue on my systems. I don't know why it happened or why it cleared up. All's well that ends well!
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Peter Hucker wrote:Any idea
)
That intermittent VRAM requirement of DF 0.20 tasks is back, so nothing has been 'cured'. I've since learned that VRAM usages of that DF class are bound between ~ 0.70 GB and 1.15 GB, which coincide with the stable VRAM requirements of the DF 0.15 and 0.25 tasks, respectively. DF 0.20 tasks that use the higher VRAM take longer to complete than those with the lower VRAM.
These VRAM variations can happen in the middle of a task series of consecutive workunit indices for the same parent frequency. For example, from workunit ID h1_0235.75_O2C02Cl4In0__O2MDFS2_Spotlight_235.95Hz_235 through to h1_..._160, task times averaged 6:05 and used 0.69 GB VRAM. From ..._159 to ... _153, task times averaged 9:05 and used ~1.13 GB VRAM. Workunit IDs that precede _153 in the series returned to taking ~ 6 min to complete with lower VRAM (on a RX 5600 XT running @ 4X). How odd. The rest of that workunit series is currently running.
Ideas are not fixed, nor should they be; we live in model-dependent reality.