Discussion Thread for the Continuous GW Search known as O2MD1 (now O2MDF - GPUs only)
Language
Copyright © 2024 Einstein@Home. All rights reserved.
Copyright © 2024 Einstein@Home. All rights reserved.
This is weird. My
)
This is weird. My GTX1660Super runs GWs 2X in ~30min.
When it picks up the odd pulsar running 2X they also take ~30min.
When it is simultaneously running a pulsar and a GW the GW time drops to ~17min and the GW has gone up to as much as 2.5hrs.
Does anyone have an explanation?
Tullio why not run both at
)
Tullio why not run both at the same time then nothing is wasted?
I have dedicated my older PC
)
I have dedicated my older PC with an AMD Ryzen 5 1400 and and a GTX 1060 to WCG, Rosetta@home and GPUGRID. WCG has already given me three Bronze Badges and one Silver badge. My newer PC with an Intel i5 and GTX 1650 is running altenatively Einstein@home tasks and LHC@home tasks. I have been dealing with GW since 1969 when I took note of Joe Weber's experiments in the Mondadori Yearbook of Science and Technology, for which I worked in Mondadori Edizioni Scientifiche, and was scolded by prof. Antonino Zichichi since I had published that Weber had discovered GW. Of course he was right, but Weber had titled his article in "Physical Review Letters" as "Evidence for discovery of gravitational radiation", which was too long to stay in a title., so my managing editor shortened it in a caption as "scoperte le onde gravitazionali".But Weber's idea of putting two detectors at a great distance and considering only those eventes appearing simultaneously in both was correct and applied later in LIGO and VIRGO.
Tullio
As you noticed, GW tasks are
)
As you noticed, GW tasks are back.
Tech details:
The FFT we're using (on NVidia GPUs) can only handle sizes of powers of two. So at some point there is memory allocated the size of a power of two that is the "next larger" than the memory currently occupied but the data. The workunit generator estimates the memory of the data before that step. At this point, even a tiny underestimation of the memory can have a rather huge effect if this is close enough to such a power-of-two boundary, as it will underestimate the memory size by a factor of two.
We now fixed the memory estimation to be more conservative. Thus such a large underestimate (factor of two) shouldn't happen anymore. However, the exact amount of memory of a given process especially on the GPU is pretty hard to predict, it depends on a lot of local properties. So it may still happen that there are tasks assigned to GPUs where the (available) memory is (slightly) too low, and memory allocation ultimately fails. This applies particularly to workunits that have already been generated before fixing the memory estimation, as we had to apply a rule-of-thumb to bump up the memory estimation there. But all in all we hope to have reduced such errors now to a bearable amount.
BM
Thanks for the info
)
Thanks for the info Bernd.
did you also look at the value for memory given by the client? It was obvious in my testing of the issue that the project is using the value for GLOBAL memory given by BOINC for making the check if it had enough memory. but I think using the value for AVAILABLE memory would be better (this value also given by BOINC and you could use), since some memory is usually used in running the desktop in those OS's which have a GUI. So in the case of a 2GB GPU for example, if it is driving a monitor on an OS with a GUI the project will see that it has 2GB memory to use, and be sent a WU that requires 1800MB of space, but the client will have 3-500MB of GPU memory tied up in running the desktop and hence not truely have enough space.
_________________________________________________________________________
Bernd, i saw exactly same
)
Bernd, i saw exactly same behavior with jump of ~doubling amount of GPU RAM used (and exceeds 3 GB per 1 task) at some point of WU running on my AMD GPUs (RX 570) too as I have reported few days ago: https://einsteinathome.org/content/discussion-thread-continuous-gw-search-known-o2md1-now-o2mdf-gpus-only?page=66#comment-178903
Is this expected (like common code initially programmed for NVidia GPUs but now used on AMD too)?
Or is it not normal for AMD and there some fix needed in AMD GW app?
Hi. Is it normal that
)
Hi. Is it normal that Gravitational Wave search on GPU on my 1080 Ti uses only ~70% of the GPU power? On HWinfo I see Core Load on 70-71% and the temperature is always under 60°.
Is it normal?
ASUS X570 E-Gaming
AMD Ryzen 9 3950X, 16 core / 32 thread 4.4 GHz
AMD Radeon Sapphire RX 480 4GB Nitro+
Nvidia GTX 1080 Ti Gaming X Trio
4x16 GB Corsair Vengeance RGB 3466 MHz
Alessio Susi wrote:Is it
)
Yes it is normal.
The GW GPU application requires far more CPU support than does the Gamma-Ray pulsar GPU application so the GPU can spend quite a lot of time waiting for required CPU activity. The GPU can be kept somewhat more fully occupied by a faster CPU than a slower one. If the onboard GPU memory is large enough, running at a higher multiplicity will also keep the GPU busier (and raise the temperature). However there is a big range in the memory requirement of GW tasks, and a multiplicity that will work well for low DF tasks will run very slowly or outright fail for high DF tasks.
Ever since the memory
)
Ever since the memory estimation fix a week ago, my computer with multiple GPUs have stopped receiving bigger then 2GB O2MDF tasks for AMD Vega 11 (12GB ?) and AMD RX 5500 XT 8GB.
Computer: https://einsteinathome.org/host/12828664
Sometimes runs out of 2GB O2MDF tasks, and it appears the project server refused to send any 4GB O2MDF tasks to my AMD GPU. All because of NVidia GT 1030 2GB in the computer, but I have Nvidia disabled in project settings.
Maybe fix it to only look at AMD GPU RAM for AMD tasks, and look at NVidia RAM for NVidia tasks, and/or add GPU RAM limit override in project settings.
sam6861 wrote:Sometimes
)
Have you reviewed the most recent request log for your machine to see what is said there about the reason?
your mixed machine request log