At least it was quickly resolved, unlike Keith Myers intermittent download issues on main.

EDIT-
From the Release notes for v5.24
- Fixed a memory leak in server side of remote sensor monitoring.

---

Grant
Darwin NT.

Why are the new (8.13/8.14) opencl_nvidia tasks (both SoG and sah) using so much CPU time ? I have specified -use_sleep, but I still seem to need nearly an entire CPU core to feed the GPU.

Examples:

8.13 SoG: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24206772
8.14 SoG: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24217433
8.14 SoG: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24225616
8.14 sah: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24225173

Previous versions did not have this problem:

8.12 SoG: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24146549
8.12 SoG: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23934991
8.12 sah: https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23868462

I don't like wasting my CPU time just feeding the GPU and by using -use_sleep there were no problems (BOINC would soon select cuda50 over opencl versions), but now I am not so sure.

Tom

Why are the new (8.13/8.14) opencl_nvidia tasks (both SoG and sah) using so much CPU time ? I have specified -use_sleep, but I still seem to need nearly an entire CPU core to feed the GPU.

Add -v 6 to tuning line. And post few results with this option ON.

---

News about SETI opt app releases: https://twitter.com/Raistmer

Yikes!!, we're in the middle of a perfect Arecibo VLAR storm again. No wonder the tasks all of a sudden takes more than twice as long as before :-)

This is going to screw up the APR again, so Non SoG will be chosen just when the Arecibo VLAR storm is over, and then Non SoG will be chosen as the fastest app, because it never did run any Arecibo VLARs.

Just like the last Arecibo VLAR storm, one has to then manually abort so many Non SoG, so that SoG again can come into play. Not good at all when there is so many WU's of one type being split, and not a good mix.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

Dropping on the fly <ngpus>, to 0.50 (from 0.33) for SoG and Non SoG, in app_config.xml, because I already know that SoG is the fastest app, no matter the AR.

Just to avoid APR rot, getting slower apps, due to this Arecibo VLAR storm.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

Dropping on the fly <ngpus>, to 0.50 (from 0.33) for SoG and Non SoG, in app_config.xml, because I already know that SoG is the fastest app, no matter the AR.

Just to avoid APR rot, getting slower apps, due to this Arecibo VLAR storm.

That's what I do change applications, no need to abort. Just load up the undesirable applications with 2, 3, or 4 WUs per GPU and watch it's APR plummet, then go back to the usual values when the VLAR or Guppie storm is over and you've got your preferred application back.

---

Grant
Darwin NT.

Well, the best solution would be to have a better mix of AR's here on Beta, like it is on main. Having a full day of only VLARs for Arecibo, really screws things up, unless you manually intervene.

Had I not lowered the <ngpus> for SoG, I would by now only get the much slower Non SoG. The system had already decided that SoG was the fastest, in fact I didn't have even one non SoG, until this Arecibo VLAR storm started.

And if I had not intervened, the APR of SoG would be so low, that I would only get non SoG, and by then the VLAR storm would be over, so the non SoG would not drop its APR. Of course leading to that the system would only give me non SoG, even on normal ARs, until the next VLAR storm, when the APR of non SoG would drop lower than the low APR SoG had from the last VLAR storm.

And then it would start over again...

No, a better mix of Arecibo AR's on Beta, thank you.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

And then it would start over again...

Yep.

No, a better mix of Arecibo AR's on Beta, thank you.

Or a way to disable the manager's best application selection when on Beta.
The more applications, and the greater the mix of work that are run on given hardware, the better.
10WUs for this application, 10 for that application, 10 for the next & so on, then repeat.

---

Grant
Darwin NT.

Oh man!!!
Is there no end to this suffering?
Thanks for all the VLARs. Can I have something else now?

LOL

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

Why are the new (8.13/8.14) opencl_nvidia tasks (both SoG and sah) using so much CPU time ? I have specified -use_sleep, but I still seem to need nearly an entire CPU core to feed the GPU.

Add -v 6 to tuning line. And post few results with this option ON.

First two results (both opencl_nvidia_sah):

https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24227184
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24227503

The second one resulted in a computation error: Disk usage limit exceeded

BOINC manager shows "free, available to BOINC: 226.47 GB".
Is there some limit on the output file size that is exceeded because using -v 6 ?

I will post SoG results as soon as they are available.

Tom

The second one resulted in a computation error: Disk usage limit exceeded

That will be the individual workunit limit:

<rsc_disk_bound>33554432.000000</rsc_disk_bound>

or 32 MByte.

The second one resulted in a computation error: Disk usage limit exceeded

That will be the individual workunit limit:

<rsc_disk_bound>33554432.000000</rsc_disk_bound>

or 32 MByte.

Hi Richard,

Thanks for the explanation. Can I change this limit and if so, where and how ?

Tom

Why are the new (8.13/8.14) opencl_nvidia tasks (both SoG and sah) using so much CPU time ? I have specified -use_sleep, but I still seem to need nearly an entire CPU core to feed the GPU.

Add -v 6 to tuning line. And post few results with this option ON.

And here are two SoG tasks (unfortunately both errored out with "Disk usage limit exceeded". I hope they still contain some useful information.

https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24229292
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24230098

I'm changing back to -v 1 to prevent further errors.
If you need more examples or other options please let me know.

Thank you for looking into this.

Tom

Can I change this limit and if so, where and how ?

I wrote that up at the main project. Message 1796590

Await new version.

---

News about SETI opt app releases: https://twitter.com/Raistmer

With r3482 I don't see memory leak for own iGPU. Worth to check on other iGPUs before full-scale deployment: https://cloud.mail.ru/public/J5f8/HGuG3Vp4R

---

News about SETI opt app releases: https://twitter.com/Raistmer

Very happy to test if you can give me instructions on what I need to do to run this app rather than the stock one :-)

With r3482 I don't see memory leak for own iGPU. Worth to check on other iGPUs before full-scale deployment: https://cloud.mail.ru/public/J5f8/HGuG3Vp4R

If I'm not half dead when I get home from work, I'll run it on my iGPU on main this evening. Just throwing it in, and editing my app_info.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

Very happy to test if you can give me instructions on what I need to do to run this app rather than the stock one :-)

I took an educated guess and renamed the MB8_win_x86_SSSE3_OpenCL_Intel.aistub file to app_info.xml and copied that and the contents of Raistmer's zip file into my Beta project directory.

When I restarted BOINC Manager it has downloaded new tasks but is now only running GPU tasks. Not sure what has happened to the tasks I already had downloaded.

Obviously my guess was, at least partially, wrong. Can anyone tell me what I need to do to get the CPU tasks running again please?

Cheers

SusieQ

I would volunteer information if I had it, but I only run GPU work for some time now.

Sorry.

I tend to manually edit my app_info.xml

I copy what i have from main and paste it into a notepad and then change the different parts of it to match Raistmer's new versions.