Discussion Thread for the Continuous GW Search known as O2MD1 (now O2MDF - GPUs only)
Language
Copyright © 2025 Einstein@Home. All rights reserved.
Copyright © 2025 Einstein@Home. All rights reserved.
I just got done running my GW
)
I just got done running my GW gpu tasks down to zilch so I would have a chance to process my pulsar gpu tasks.
Is anyone sucessfully getting both GW's and Pulsar gpu tasks to run at the same time?
I tried using the concurrent_max to reduce the GW's below my gpu count and was unable to get the Pulsar tasks to start until I had run completely out of GW tasks.
Tom M
A Proud member of the O.F.A. (Old Farts Association).
Tom M wrote:I just got done
)
I have no problems getting them to run at once, apart from they're too slow. The gravity takes 2.5-3.5GB of GPU RAM depending on the frequency used. 4 of my cards only have 3GB so I don't bother with gravity. The one with 4GB will get filled up with gravity and gamma, so it slows right down having to use system RAM. So I've set the 3GB cards to gamma only and the 4GB card to run either 2 gamma or 1 gravity, by choice of the server.
As for your problem - could you paste your app_config.xml from the Einstein folder in here, and someone will tell you what's up. There are several limits in force and you may have overlooked one.
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.
wow, I happened to catch a
)
wow, I happened to catch a few VelaJr tasks using a LOT of GPU memory. 3200MB on a single task.
_________________________________________________________________________
Ian&Steve C. wrote:wow, I
)
Half of mine use that much, which is why I've banned gravity from my 3GB cards, even after I get a CPU powerful enough to assist. STILL waiting on that heatsink bracket. The UK's Royal Mail system is horrendously slow, if only Ebay sellers would use the couriers, which are keeping up just fine.
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.
--edit--Quote:I tried
)
--edit--
--edit---
<app_config><app>
<name>hsgamma_FGRPB1G</name>
</app>
<app>
<name>einstein_O2MD1</name>
</app>
<app>
<name>einstein_O2MDF</name>
<max_concurrent>2</max_concurrent>
</app>
<app>
<name>einstein_O2MD1</name>
<max_concurrent>2</max_concurrent>
</app>
</app_config>
This is comments from here down.
<app>
<name>hsgamma_FGRPB1G</name>
</app>
<app>
<name>einstein_O2MD1</name>
</app>
hsgamma_FGRP5', 'einstein_O2MDF', 'hsgamma_FGRPB1G', 'einstein_O2MD1'
<project_max_concurrent>24</project_max_concurrent>
<max_concurrent>7</max_concurrent>
A Proud member of the O.F.A. (Old Farts Association).
If you want to prevent a GPU
)
If you want to prevent a GPU from crunching GW, you have to exclude it from the cc_config.xml. You will have to add it to the xml, identify the GPU and identify the work unit and project. Trying to figure out the numbering sequence of the GPUs is the tricky part. This is an example of what it would look like. It's an older one, trying to find the one I used to use for Einstein but basically it's the same. This was for Seti when I split 2 of 4 GPUs to run seti and the other 2 to run Einstein.
<cc_config>
<options>
<exclude_gpu>
<url>setiweb.ssl.berkeley.edu/beta</url>
<device_num>0</device_num>
<app>setiathome_v8</app>
</exclude_gpu>
<exclude_gpu>
<url>setiweb.ssl.berkeley.edu/beta</url>
<device_num>2</device_num>
<app>setiathome_v8</app>
</exclude_gpu>
</options>
</cc_config>
Tried to edit but Einstein
)
Tried to edit but Einstein isn't having it. I was running Seti Beta on 2 of 4 and Einstein on the other 2.
Edit 2.. Found an old Einstein exclude cc_config.xml
<cc_config>
<options>
<exclude_gpu>
<url>http://einstein.phys.uwm.edu/</url>
<device_num>1</device_num>
<app>einsteinbinary_BRP4G</app>
</exclude_gpu>
<exclude_gpu>
<url>http://einstein.phys.uwm.edu/</url>
<device_num>0</device_num>
<app>einsteinbinary_BRP5</app>
</exclude_gpu>
<exclude_gpu>
<url>http://einstein.phys.uwm.edu/</url>
<device_num>2</device_num>
<app>einsteinbinary_BRP5</app>
</exclude_gpu>
</options>
</cc_config>
Don't know if it will help,
)
Don't know if it will help, but I had a similar issue. I have a system with 2 gpu's and had to exclude the GW app from the 1060 3GB to stop the errors. This is the change I made, and so far it's working.
In the <options> section of cc_config.xml in the /BOINC directory.
From the first few lines in the event log after startup to know which device number to exclude.
Hope this helps.
Thank you for your
)
Thank you for your responses.
I may try that because I have two different groups of gpus so could segment them. However,
I was able to reduce the # of GW gpu tasks. I was NOT able to get the Pulsar tasks to run until all the GW tasks were gone.
As far as I can tell it was not an issue of all the Pulsar tasks had due dates later than the GW tasks. (Maybe?)
It was not a case of not enough cpu memory (32 GB) and I am running rtx 2060 Super and gtx 1660 Super. So it probably was not a case of gpu ram.
Plus "the night before" it was happily running both kinds of task. The next morning it refused to run the Pulsar tasks.
Its beginning to look like I will need to test this problem again. I would like to run 1 or 2 GW gpu tasks while mainly running the Pulsar tasks.
Tom M
A Proud member of the O.F.A. (Old Farts Association).
Tom M wrote:Thank you for
)
I too, tried that, but no luck, or partial luck. By excluding GW GPU tasks from one device in cc_config, I was able to have the excluded GPU run 3X pulsar tasks and the other GPU run 2x GW tasks, but only if I had my work queue already filled with both sets of tasks before setting the exclusion. As soon as pulsar tasks were all completed, the server did not reload them; only GW GPU tasks continued to download. I tried all combinations of exclude_gpu and gpu_usage in the two config files, but no luck. It seems that the E@H download server is interpreting <exclude_gpu> differently than we understand it to work. Is it a task priority issue?
Ideas are not fixed, nor should they be; we live in model-dependent reality.