GW GPU O2MDFS2_Spotlight work

Jim1348
Jim1348
Joined: 19 Jan 06
Posts: 449
Credit: 220,003,284
RAC: 388,646

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.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,033
Credit: 5,219,014,031
RAC: 5,065,582

Jim1348 wrote:Thanks.  Your

Jim1348 wrote:
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.

Betreger
Betreger
Joined: 25 Feb 05
Posts: 959
Credit: 711,086,344
RAC: 323,712

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. 

Peter Hucker
Peter Hucker
Joined: 12 Aug 06
Posts: 298
Credit: 234,738,618
RAC: 3,304

Betreger wrote: I allow

Betreger wrote:

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.

cecht
cecht
Joined: 7 Mar 18
Posts: 968
Credit: 1,272,940,119
RAC: 1,586,296

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.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,033
Credit: 5,219,014,031
RAC: 5,065,582

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.

 

Holmis
Joined: 4 Jan 05
Posts: 1,118
Credit: 1,055,935,564
RAC: 17,557

cecht wrote:As an aside, has

cecht wrote:
As an aside, has anyone picked up tasks of DF 0.35 or higher?  Has anyone measured the VRAM usage of those?

I've just picked up some DF 0.35 tasks (272.55Hz base) and I show them using 1.14 GB of VRAM.

cecht
cecht
Joined: 7 Mar 18
Posts: 968
Credit: 1,272,940,119
RAC: 1,586,296

Holmis wrote:I've just picked

Holmis wrote:
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.

cecht
cecht
Joined: 7 Mar 18
Posts: 968
Credit: 1,272,940,119
RAC: 1,586,296

cecht wrote:It is only with

cecht wrote:
It is only with tasks with a DF of 0.20, however, that I see a progressive increase in VRAM requirement to run them. ...

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.

cecht
cecht
Joined: 7 Mar 18
Posts: 968
Credit: 1,272,940,119
RAC: 1,586,296

Peter Hucker wrote:Any idea

Message 179752 in response to (parent removed)

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.