No higher credits for the tasks I've crunched yesterday and today.

I stop and will try to understand what is happening.

I've also been having trouble with work units erroring out in this way. I have over 150 cpu cores spread out across a variety of machines, all under linux. Just a few moments ago I attempted to attach to GPUGRID only to have computational error after computational error. I hope this is fixed shortly as I would love to have GPUGRID as one of my default projects.

Yes, credit is doing something very strange. I got 111 credits for 3292 seconds of cpu time.

klepel got 1362 credits for the same time.

Run time 3,262.28
CPU time 12,834.34
Validate state Valid
Credit 1,361.79

Task 13118994

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Are you seriously comparing SETI to GPUGRID?!

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Are you seriously comparing SETI to GPUGRID?!

CreditNew is CreditNew.

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Are you seriously comparing SETI to GPUGRID?!

CreditNew is CreditNew.

You cannot compare one project's credit to another.

You cannot compare one project's credit to another.

At least it should be comparable as described in the BOINC documentation.
See: http://boinc.berkeley.edu/trac/wiki/CreditNew#Cross-projectversionnormalization

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Are you seriously comparing SETI to GPUGRID?!

CreditNew is CreditNew.

You cannot compare one project's credit to another.

One of the stated objectives of CreditNew it to make credit the same across all projects for the same amount of cobblestones used to compute.

Thus my comment about CreditNew. CPU projects that have higher or lower then typical RAC are most likely using something else besides CreditNew like a fixed credit or another algorithm.

Yes I understood your post and sentiment. My post was directed at the other poster's incredulous comment.

This project itself utilize both mechanisms. CreditNew for cpu tasks and fixed credit awards for gpu tasks.

As far as I have been able to find, that is unique among projects. Usually it is either/or not both.

Yes I understood your post and sentiment. My post was directed at the other poster's incredulous comment.

This project itself utilize both mechanisms. CreditNew for cpu tasks and fixed credit awards for gpu tasks.

As far as I have been able to find, that is unique among projects. Usually it is either/or not both.

I wasn't referencing you as I didn't quote you. ;)

I agree.

Would you please list the QC project progress on the server status page as well:

http://www.gpugrid.net/server_status.php

Thanks.

Another issue is that your app does not dynamically allocate CPU cores according to the BOINC settings. Instead it claims all physically present cores. That is a major problem when trying to run computations on the GPU as well because to do so, the GPU project automatically (or I manually) reserve(s) one CPU core per GPU task.
Example: When the BOINC manager is set to use 7 of the 8 cores to do CPU computations, your CPU client grabs all 8 cores (or since recently 2x 4 cores).
That is not acceptable.
Please fix this to attract more people to donate CPU cycles to your project.

Michael.

---

President of Rechenkraft.net - Germany's first and largest distributed computing organization.

Another issue is that your app does not dynamically allocate CPU cores according to the BOINC settings. Instead it claims all physically present cores.

I'm seeing this behavior as well. On my Ryzen 1700X system with 2 GPUs, these WUs basically take over all CPUs and throw the GPUs into "Waiting to run".

I suppose one could set max_concurrent in an app_config.xml to fix this...what would be the proper app name to use?

QC is the proper app name. This is how I limit QC to 2 threads per task.

<app>
<name>QC</name>
<max_concurrent>1</max_concurrent>
</app>
<app_version>
<app_name>QC</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>2.000000</avg_ncpus>
<cmdline>--nthreads 2</cmdline>

I also just run 1 task at a time to avoid the starting two tasks at the same time flaw in the application.

An error on a wu (task 17040682):

<core_client_version>7.8.3</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.
ConnectionError(MaxRetryError("HTTPSConnectionPool(host='repo.continuum.io', port=443): Max retries exceeded with url: /pkgs/main/linux-64/repodata.json.bz2 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc2a3f56860>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))",),)


Traceback (most recent call last):
File "pre_script.py", line 13, in <module>
raise Exception("Error installing h5py")
Exception: Error installing h5py
08:49:09 (1252): $PROJECT_DIR/miniconda/bin/python exited; CPU time 0.469942
08:49:09 (1252): app exit status: 0x1
08:49:09 (1252): called boinc_finish(195)

Hi, we need more CPUs on Linux to run QM simulations. Anybody can help?

okay, I'm going to install Linux right now on my computer and it should be ready tonight or early tomorrow.

---

Cruncher/Learner in progress.

Traceback (most recent call last):
File "pre_script.py", line 13, in <module>
raise Exception("Error installing h5py")
Exception: Error installing h5py
08:49:09 (1252): $PROJECT_DIR/miniconda/bin/python exited; CPU time 0.469942
08:49:09 (1252): app exit status: 0x1
08:49:09 (1252): called boinc_finish(195)

If you are running the latest distros from Ubuntu or Mint you may need to install the python-support package.

wget http://launchpadlibrarian.net/109052632/python-support_1.0.15_all.deb

sudo dpkg -i python-support_1.0.15_all.deb

One of my CPUs is crunching linux jobs, I will add two more next week.

I have added three. Athlon 5350, I3 3240, I3 6100. Not the best ones but doing their job. I can add more but I would like to know how many WUs can we expect for the Linux QM app?

BTW ATM just 92 users are crunching QM, that's sad :(

I have added another machine, and now have four on it (2 i7-3770, 1 i7-4790 and 1 Ryzen 1700), with two to four cores per machine allocated via the resource share. The main problem in running them is that when two or more start up at the same time, they error out. That happens mainly during reboots, but otherwise they never start up at the same time. I leave my machines running 24/7, so I don't reboot very often.

And to minimize the problem, you can run with the default 4 cores per work unit and only 4 cores (or less) per machine on average, so that they usually don't start more than one work unit at a time anyway. In that way, it is a manageable problem for me, though it would be best if they fix it. I am sure more people would then be willing to run it.

Also a Windows version would help of course, and for that they had better be seriously thinking about VirtualBox.