These are running just fine on both Windows and Linux so far. I haven't seen any run times near six hours yet. I also see that the Linux app is loading the GPU much higher than the Windows app is, about double.
____________
Team USA forum | Team USA page
Join us and #crunchforcures. We are now also folding:join team ID 236370!

Almost 20 tasks validated so far, but I have also had two WUs end in an error after a few seconds, on two different hosts so far:

<core_client_version>7.9.3</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
12:23:14 (10594): wrapper (7.7.26016): starting
12:23:14 (10594): wrapper (7.7.26016): starting
12:23:14 (10594): wrapper: running acemd3 (--boinc input --device 1)
ERROR: /home/user/conda/conda-bld/acemd3_1570536635323/work/src/mdsim/forcefield.cpp line 174: Cannot index the parameter files with the topology file
12:23:15 (10594): acemd3 exited; CPU time 0.081577
12:23:15 (10594): app exit status: 0x9e
12:23:15 (10594): called boinc_finish(195)

</stderr_txt>
]]>

Cool, got all 3 Linux NV cards happily crunching away at about 95% gpu usage.

I'm glad to process Science again! (please, note capital letter for this)
Thank so much to all GPUGrid's Team (please, see above)

What is the object of the research?
____________
John

Toni, Glad to get the work.
Is there any plan to upgrade your server or internet speed???

Toni, Glad to get the work.
Is there any plan to upgrade your server or internet speed???

What is the object of the research?

Trying to get some tasks and so far no luck. Am I doing it wrong?

Thanks

Trying to get some tasks and so far no luck. Am I doing it wrong?

Thanks

Out of work already! LOL
____________
Team USA forum | Team USA page
Join us and #crunchforcures. We are now also folding:join team ID 236370!

Is the policy still to reduce credits on work not uploaded within 24hrs of issue?

Out of work already! LOL

Out of work already! LOL

Is the policy still to reduce credits on work not uploaded within 24hrs of issue?

Thank you. Great job on the new WU incidentally.

As they are much shorter, could I ask that you please allow download of more than 2 WU per GPU

I believe the limit is 16 per host. That is what I got on my 3 hosts. After that I received the "you have reached the limit of tasks in progress message"

Thank you. Perhaps I'll see that once WU become freely available :-)

As they are much shorter, could I ask that you please allow download of more than 2 WU per GPU

I believe the limit is 16 per host. That is what I got on my 3 hosts. After that I received the "you have reached the limit of tasks in progress message"

An important issue I've noted after crunching these GPUGrid units in my Ubuntu 16.04 hosts, not in 18.04 ones, is that the rest of BOINC GPU projects (and folding#home) fail with error when trying to crunch. I tested with Amicable, Einstein and FAH.

I've had to reinstall NVIDIA drivers and restart to get things working again. A matter of libraries and links I guess.

I added GPUGrid to the projects list on one of my machines two years ago, I've never received a work unit. Other GPU projects are not having any trouble. Removed now.
____________

I added GPUGrid to the projects list on one of my machines two years ago, I've never received a work unit. Other GPU projects are not having any trouble. Removed now.

Some years ago there was a AMD application and is still possible to check the box for AMD wu's in the GPUGRID preferences.
Maybe there will be less confusion if this check-box is removed ..

I believe the limit is 16 per host. That is what I got on my 3 hosts. After that I received the "you have reached the limit of tasks in progress message"

It is a little ironic that a project specially for GPU's supports less GPU's than other projects. Einstein, Milky Way, Seti, etc. no problem.
____________

Any ideas when new workunits will be release?
____________

I see your computers are set up to run Seti, where it is common to "spoof" the server into "thinking" you have 32 coprocessors/GPUs per rig.

I believe the limit is 16 per host. That is what I got on my 3 hosts. After that I received the "you have reached the limit of tasks in progress message"

The limit is 2 per GPU. I see your computers are set up to run Seti, where it is common to "spoof" the server into "thinking" you have 32 coprocessors/GPUs per rig.

I see your computers are set up to run Seti, where it is common to "spoof" the server into "thinking" you have 32 coprocessors/GPUs per rig.

Tell me more !
Seti has the problem of not beeing always available and not having always wu's available, but the allowed runtime is quite long. So it makes sense to have a larger buffer, but this should only affect the Seti wu's.

The coproc_info.xml file that is created by the client controls the number of gpus detected.

For a serial process like this the optimum would be to only send one WU per GPU.

For a serial process like this the optimum would be to only send one WU per GPU.

not really; because what would happen then is that there always is some idle time between uploading/reporting the result of a task and downloading the next one.
Which means the GPU cools off for a (short) while and heats up once the new task starts being cruched.
If this happens several time per day, over a lenghty period of time, this so-called "thermal cycle" definitely shortens the lifetime of the GPU.
Hence, it's definitely better to have another task already waiting to start immediately after the previous one gets finished.

...the GPU cools off for a (short) while and heats up once the new task starts being cruched (sic).
If this happens several time per day, over a lengthy period of time, this so-called "thermal cycle" definitely shortens the lifetime of the GPU.

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

Fortunately simple manipulation doesn't work, as this file is overwitten by the BOINC manager at startup.

...the GPU cools off for a (short) while and heats up once the new task starts being cruched (sic).
If this happens several time per day, over a lengthy period of time, this so-called "thermal cycle" definitely shortens the lifetime of the GPU.

The degradation process for electronics is called electromigration. Flowing current while hot actually moves atoms. Where the conductors neck down, e.g. turning a sharp corner or going over bumps, the current density increases and hence the electromigration increases. This is an irreversible process that accelerates as the conductor chokes down and ultimately results in a broken line and failure.

Since GPUGrid is supply-limited one per GPU would assure that more hosts get a WU before hosts start getting additional WUs. Now that the WUs run in less than half the time two per GPU works well but folks still get left out.

The GPUGrid server is notoriously slow. If it were fast and they had over 10,000 WUs continuously available then one per GPU would be optimum.

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

Fortunately simple manipulation doesn't work, as this file is overwitten by the BOINC manager at startup.

You can prevent the coproc file from been overwritten by BOINC.

Which may explain tasks failing with

# Engine failed: Illegal value for DeviceIndex: 2

i.e. they attempt to run on non-existent gpus.

1. Ban people who rig the system.

2. Electromigration is a very real problem, and they study it extensively. Before any new chip is ready for production, they have that ironed out. If the chip fails in the next 100 years, it probably won't be for that reason unless you abuse it by overclocking and overheating it excessively.

1. Banning is a bit extreme. I think just asking people not to do it should be enough.

2. The spoofed client wasn't meant for GPUGrid. It was developed for Seti. It has no effect on Einstein@home and is surprising that it adversely affects the GPUGrid project. It wasn't meant to. As it was meant for a project with large pool of uncrunched data, it made sense to be able to download larger cache that ran in very short timeframes (42 secs average). It was not meant for GPUGrid where there is limited data that takes several hours to process. It is an unfortunately side effect of the spoofed client. It was not aimed at denying fellow crunchers access to data, if some people feel that way, it is unfortunate but not the intended purpose.

3. The comment that chips should last 100 years is an overstatement. Nothing last 100 years anymore. We are in a consumer driven economy. Meaning demand helps fuel our economy. If things lasted a hundred years, companies would go out of business as demand would drop off. More likely they are designed to last 3-5 years before they fail.

4. I agree it would be preferable to keep the chips warm and busy by having 1 extra task available so that there is little lag between switching so that voltages and temps don't fluctuate significantly over an extended period of time.

I agree it would be preferable to keep the chips warm and busy by having 1 extra task available so that there is little lag between switching so that voltages and temps don't fluctuate significantly over an extended period of time.

2. The spoofed client wasn't meant for GPUGrid. It was developed for Seti. It has no effect on Einstein@home and is surprising that it adversely affects the GPUGrid project.

(BTW, while there were no GPU tasks available during the past few days, I switched to Einstein - and these tasks showed a strange behaviour [as opposed to about a year ago]: for the first 80-100 seconds and the last 50-60 seconds of a task, only the CPU was crunching, NOT the GPU. Figuring that the tasks' lengh was about 12-14 minutes, the GPU was suffering a thermal cycle about 5 x per hour).

... But if you are concerned about thermal cycles, what about the gamers? They would have destroyed their cards long before you.

(BTW, while there were no GPU tasks available during the past few days, I switched to Einstein - and these tasks showed a strange behaviour [as opposed to about a year ago]: for the first 80-100 seconds and the last 50-60 seconds of a task, only the CPU was crunching, NOT the GPU. Figuring that the tasks' lengh was about 12-14 minutes, the GPU was suffering a thermal cycle about 5 x per hour).

Toni wrote

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

It's the motherboard, it's always the motherboard. The MB is the most unreliable part of a computer. I have a stack of dead ones. I wish there was a MB designed specifically for distributed computing with no baby blinky lights and other excessive features etc.

It's not just the speed. There's some DDOS prevention algorithm in operation, because my hosts gets blocked if they try to contact the server one by one in rapid succession (from the same public IP address).

Yes, Keith and by now I got 150 tasks, yesterday that is, but none this morning, so far.

Yes, Keith and by now I got 150 tasks, yesterday that is, but none this morning, so far.

Toni wrote

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

a short look at the users list easily reveals some of the "faked" GPUs - their hosts show 48 GPUs per host(!) So no wonder that they download dozens of tasks at a time and are still processing these tasks long time after other users are through with the only 2 tasks their hosts could download.

This procedure is highly unfair, and GPUGRID should quickly develop steps against it.

It's not just the speed. There's some DDOS prevention algorithm in operation, because my hosts gets blocked if they try to contact the server one by one in rapid succession (from the same public IP address).

What can we do to mitigate this effect???

OAS: Bunkering for serial projects should be banned one way or another. These "races" and "sprints" have some folks requesting as many WUs per host as they can get but they don't get submitted to the work server until after the race start time, i.e. bunkering.

I triggered something a few days ago on GPUGrid that I've never seen before on a BOINC project. It was a fluke combination of things that had me upgrade my drivers but delayed a reboot. It wouldn't have bothered anything else but an unbeknownst slug of GPUGrid WUs had appeared. All those WUs had computation errors.

Then both computers got banned with a Project Request.

I thought it would be a 24-hour timeout I'd seen folks mention before but it persisted for days.

After a few days I tried a manual Project Update and it started working again.

Can this Project Requested Ban be applied to bunkerers???

It's not just the speed. There's some DDOS prevention algorithm in operation, because my hosts gets blocked if they try to contact the server one by one in rapid succession (from the same public IP address).

What can we do to mitigate this effect???

There's no easy way to fix this in our end.

I triggered something a few days ago on GPUGrid that I've never seen before on a BOINC project. It was a fluke combination of things that had me upgrade my drivers but delayed a reboot. It wouldn't have bothered anything else but an unbeknownst slug of GPUGrid WUs had appeared. All those WUs had computation errors.

That's most probably because of the delayed reboot.

That's easy: limit the number of simultaneous tasks per host to 16.

To come back on topic, there is a batch ("MDADpr1") of ~50k workunits being created. I hope it's correct.

Actually they were only 500. Better this way - they came out too large. Feel free to abort them.

about an hour ago, I had two tasks (on two different hosts) that were "aborted by project" after about 5.900 seconds:

http://www.gpugrid.net/result.php?resultid=21644737
http://www.gpugrid.net/result.php?resultid=21644681

what happened?

edit: just now, two other ones like those mentioned in Toni's message

To come back on topic, there is a batch ("MDADpr1") of ~50k workunits being created. I hope it's correct.

Ok, I did not know the server would cancel running WUs. Good to know. They would have run around 6h-ish, but I was not sure they wouldn't fail at the end due to large uploads.

The next test batch (MDADpr2) is out.

As long a host turns in valid work and in a timely manner, I don't think any kind of new restriction is needed. The faster hosts get more work done for the project which should keep the scientists happy with the progress of their research.

Ok, I did not know the server would cancel running WUs. Good to know. They would have run around 6h-ish, but I was not sure they wouldn't fail at the end due to large uploads.

The next test batch (MDADpr2) is out.

[Edit] Also see Toni made good on the credit re-adjustment. Now only getting a quarter of what was awarded prior for 4 times the length of processing time.

[Edit] Also see Toni made good on the credit re-adjustment. Now only getting a quarter of what was awarded prior for 4 times the length of processing time.

hm, for the first time that I read someone complaining about too high credit :-)

It's not just the speed. There's some DDOS prevention algorithm in operation, because my hosts gets blocked if they try to contact the server one by one in rapid succession (from the same public IP address).

What can we do to mitigate this effect???

OAS: Many projects are adding a Max # WUs option in Preferences. Maybe add it with the choice of 1 or 2.

OAS: Bunkering for serial projects should be banned one way or another. These "races" and "sprints" have some folks requesting as many WUs per host as they can get but they don't get submitted to the work server until after the race start time, i.e. bunkering.

I triggered something a few days ago on GPUGrid that I've never seen before on a BOINC project. It was a fluke combination of things that had me upgrade my drivers but delayed a reboot. It wouldn't have bothered anything else but an unbeknownst slug of GPUGrid WUs had appeared. All those WUs had computation errors. Then both computers got banned with a Project Request. I thought it would be a 24-hour timeout I'd seen folks mention before but it persisted for days. After a few days I tried a manual Project Update and it started working again. Can this Project Requested Ban be applied to bunkerers???

Keith Myers wrote:

Also see Toni made good on the credit re-adjustment. Now only getting a quarter of what was awarded prior for 4 times the length of processing time.

Also Toni explained over in the QC Chemistry forum that tasks run for different lengths of times depending how many atoms are in the model.

So for the exact same MDADpr2 campaign, there can be differing credit awards depending on the task and whether it is hard to crunch or easy.

Throw on top of that the early return benefit and late return penalty, there can be a lot of variability.

I crunch competitively on up to 20 nVidia Turing cards and believe that every WU I do is returned within 24 hours.

You have already solved the 'bunkering' problem but if you want to improve the supply of WU to us volunteers it is very very simple. Just follow Primegrid's lead and remove GPUgrid from the projects white-listed by GridCoin. Keep it to unpaid volunteers

It is a little ironic that a project specially for GPU's supports less GPU's than other projects. Einstein, Milky Way, Seti, etc. no problem.

I crunch competitively on up to 20 nVidia Turing cards and believe that every WU I do is returned within 24 hours.

You have already solved the 'bunkering' problem but if you want to improve the supply of WU to us volunteers it is very very simple. Just follow Primegrid's lead and remove GPUgrid from the projects white-listed by GridCoin. Keep it to unpaid volunteers

Today is not impossible to convert Cuda code to OpenCl, but it seems that they are not able to do this.

[quote]... They have more than enough volunteers with Nvidia cards

It is a little ironic that a project specially for GPU's supports less GPU's than other projects. Einstein, Milky Way, Seti, etc. no problem.

If i'm not wrong the problem is that they have not an "hard" gpu developer.
Today is not impossible to convert Cuda code to OpenCl, but it seems that they are not able to do this.

I crunch competitively on up to 20 nVidia Turing cards and believe that every WU I do is returned within 24 hours.

You have already solved the 'bunkering' problem but if you want to improve the supply of WU to us volunteers it is very very simple. Just follow Primegrid's lead and remove GPUgrid from the projects white-listed by GridCoin.

Keep it to unpaid volunteers

Thank you for the explanation. $9 is indeed a paltry amount

Got 3 today, for 4 computers, could use many more. It started great a few days back, but now getting too few.

Thank you Toni, just got one more.

The current situation at GPUGRID is definitely better than the situation at the Predictor@Home project for several months before it shut down. Their development team had split up. One part kept the server, the right to use the Predictor @Home name, and so on. The part that left took away the knowledge of how to create useful new workunits. The remainder of the team could only increase the number of failures each workunit could have every time a previous task for that workunit failed, so for several months. For several months, this meant that very few tasks were available, and all of them failed.

Which if any of you would prefer that situation?

The message is:
02/02/2020 7:38:19 | GPUGRID | Mensaje del servidor : New version of ACEMD needs 953.20MB more disk space. You currently have 2861.49 MB available and it needs 3814.70 MB.

I have free to use BOINC = 963.65GB

You currently have 2861.49 MB = 2.8 GB
available and it needs 3814.70 MB = 3.8GB

Then 3.8GB > 963GB???

Don't make me sense.

Anyone having issues with the GPU work units crashing their Geforce RTX 2080 Ti's?

Before this series came out this month my systems was working like a champ.

Suddenly this month it seems like something is making my system overheat if I enable the GPU tasks.

Have a Ryzen 9 3900X that I've been running full tilt for like 6 months now, no problems.

Then suddenly system hangs, with all the fans (CPU, GPU, Chassis, etc) all off and the motherboard unresponsive to the reset buttons and the power button. The LED's on the Chipset and Motherboard remain lit.

To resolve I have to turn power off at the PSU, and then boot.

The only thing that comes up in the system error logs is when I turn the PSU power off, that there is an unexpected Kernel power failure at that time (in the Windows error logs).

Almost like it is in a sleep/suspend mode, but all that is off.

Last night I left the GPU disabled and the CPU only tasks worked fine.

Anyone having issues with the GPU work units crashing their Geforce RTX 2080 Ti's?

Jacosito, in the BOINC Manager look at Options/Computing Preferences/Disk & Memory tab. There are 3 check boxes. I uncheck the first two and only check the third. Mine says "Use no more than 80% of total." Make sure you give BOINC permission to use enough storage.

Then suddenly system hangs, with all the fans (CPU, GPU, Chassis, etc) all off and the motherboard unresponsive to the reset buttons and the power button. The LED's on the Chipset and Motherboard remain lit.

To resolve I have to turn power off at the PSU, and then boot.

Anyone having issues with the GPU work units crashing their Geforce RTX 2080 Ti's?

Before this series came out this month my systems was working like a champ.

Suddenly this month it seems like something is making my system overheat if I enable the GPU tasks.

Have a Ryzen 9 3900X that I've been running full tilt for like 6 months now, no problems.

Then suddenly system hangs, with all the fans (CPU, GPU, Chassis, etc) all off and the motherboard unresponsive to the reset buttons and the power button. The LED's on the Chipset and Motherboard remain lit.

To resolve I have to turn power off at the PSU, and then boot.

The only thing that comes up in the system error logs is when I turn the PSU power off, that there is an unexpected Kernel power failure at that time (in the Windows error logs).

Almost like it is in a sleep/suspend mode, but all that is off.

Last night I left the GPU disabled and the CPU only tasks worked fine.

...Then suddenly system hangs, with all the fans (CPU, GPU, Chassis, etc) all off and the motherboard unresponsive to the reset buttons and the power button. The LED's on the Chipset and Motherboard remain lit...

Yes (2) 8 pin supplies to my RTX 2080Ti.

The powersupply is a Corsair CX750M.

I probabably am over-taxing it.

Nothing overclocked beyond factory OC (if any).

Thanks.

Was odd, before it ran with everything fully loaded all night long no problem.

Thanks.

Yes I tried that, still did it.

Right now disabling GPU work units.

I am thinking my powersupply is struggling as others suggested.

At least your receiving work units. Last two weeks I have not received any work units. All equipment running good. Work units average five hours.Please send some work.

At least your receiving work units. Last two weeks I have not received any work units. All equipment running good. Work units average five hours.Please send some work.

... some OpenCL work.

Supporting both is more for political-correctness reasons rather than need.

The powersupply is a Corsair CX750M.

Suddenly this month it seems like something is making my system overheat if I enable the GPU tasks.

Have a Ryzen 9 3900X that I've been running full tilt for like 6 months now, no problems.

Then suddenly system hangs, with all the fans (CPU, GPU, Chassis, etc) all off and the motherboard unresponsive to the reset buttons and the power button. The LED's on the Chipset and Motherboard remain lit.

To resolve I have to turn power off at the PSU, and then boot.).

The same, not WU.

Can you send me your app_config.xml?

My GPU and CPU, both with liquid refrigeration.

Cheers

I'm not getting any work units. Why?
____________

I get "no tasks available" over and over
____________

I get "no tasks available" over and over

Why don't you click on Donate and send them enough money that they can hire another person to create workunits?

I should be able to make WUs this week.

I should be able to make WUs this week.

Wait and see !!!
Toni, so many times announcing WU and never something.

And when there are, the first take all WU, crunch it of course, but nothing for the other.

It will say the first takes all, and so can falsify the world competition.
I suggest to limit the WU by user, not by host.
A user with hundred GPU, receive hundred of of WU, user with one or two GPU, receive ... nothing !!!

And world competitions is so falsified (like SETIBZH )

It is more or less the same on Xanson, latest year !
The user who knows when WU will be released have a serious advantage, can take a lot of and nothing for other.

So I suggest ti set limitations also on user. Limitations on 2WU/GPU is not enough.

Wait and see !!!
Toni, so many times announcing WU and never something.

And when there are, the first take all WU, crunch it of course, but nothing for the other.

It will say the first takes all, and so can falsify the world competition.
I suggest to limit the WU by user, not by host.
A user with hundred GPU, receive hundred of of WU, user with one or two GPU, receive ... nothing !!!

And world competitions is so falsified (like SETIBZH )

It is more or less the same on Xanson, latest year !
The user who knows when WU will be released have a serious advantage, can take a lot of and nothing for other.

So I suggest ti set limitations also on user. Limitations on 2WU/GPU is not enough.

It will say the first takes all, and so can falsify the world competition.

It will say the first takes all, and so can falsify the world competition.

This is not a competition. This is cooperation.

Competition?!? Pffftt! I'm in it for the money. Cheques are mailed out at the end of the month, right?

@Toni - you must absolutely do what you consider best for the project at all times.

However, I do also think that the challenges such as Formula Boinc, BoincStats etc are truly excellent in that they provide other reasons for people to become / remain interested. Challenges provide a willing and motivated source of crunchers so that is quite clearly an advantage to science.

The only 'nasties' I am aware of are basically people who THINK that there is cheating taking place - or that it is even possible

The powersupply is a Corsair CX750M.

I have the same power supply Corsair CX750M. And I have the same problem you describe:

Suddenly this month it seems like something is making my system overheat if I enable the GPU tasks.

Have a Ryzen 9 3900X that I've been running full tilt for like 6 months now, no problems.

Then suddenly system hangs, with all the fans (CPU, GPU, Chassis, etc) all off and the motherboard unresponsive to the reset buttons and the power button. The LED's on the Chipset and Motherboard remain lit.

To resolve I have to turn power off at the PSU, and then boot.).

My system is AMD 1700x and a GTX1070. I tried to resolve the problem by lowering clocks on the CPU since the beginning. What seems to help, is lowering the frequency of the GPU by 120 MHz and increase the fan speed to 97% on this particular GPU. But still the computer freezes frequently.
Lately I was wondering if it might be the PSU as well, as I had a "bluescreen" problem on another computer, I solved with a certified, higher Watt PSU a few years ago.
So it seems to me, that this might be a bad PSU design for 24/7 crunching.

Watching to the header of this thread: “Large scale experiment: MDAD”
Large scale suits perfectly the current situation: 211,715 WUs ready to send... And growing.
Amusing

Where can I find information on the relative performances of GTX 10 series graphics boards to the newer GTX 16 and RTX 20 series boards for MDAD workunits?

I'm not interested in their relative performance for games.

Where can I find information on the relative performances of GTX 10 series graphics boards to the newer GTX 16 and RTX 20 series boards for MDAD workunits?