Thanks for the explanations! I'll be reading those preprints soon.

Do we need to check the Run Test Applications preference?

There's no acemd4 option in preferences?

Why are there 2 Use CPU boxes?

Thanks! I have added the ACEMD 4 option.

Why are there 2 Use CPU boxes?

Where do you see these boxes?

Thanks! I have added the ACEMD 4 option.

Why are there 2 Use CPU boxes?

Where do you see these boxes?

Click on Edit Preferences and there's one at the top and one at the bottom.

Resource share

Use CPU Enforced by version 6.10+ no
Use ATI GPU Enforced by version 6.10+ no
Use NVIDIA GPU Enforced by version 6.10+ yes

Run test applications? yes
Is it OK for GPUGRID and your team (if any) to email you? yes
Should GPUGRID show your computers on its web site? yes

Default computer location ---

Maximum CPU % for graphics 0 ... 100 20

Run only the selected applications ACEMD 3: no
ACEMD 4: no
Quantum Chemistry (CPU): no
Quantum Chemistry (CPU, beta): no
Python Runtime (CPU, beta): no
Python Runtime (GPU, beta): yes

If no work for selected applications is available, accept work from other applications? yes

Use Graphics Processing Unit (GPU) if available yes
Use Central Processing Unit (CPU) yes

Resource share

Use CPU Enforced by version 6.10+ no
Use ATI GPU Enforced by version 6.10+ no
Use NVIDIA GPU Enforced by version 6.10+ yes

Run test applications? yes
Is it OK for GPUGRID and your team (if any) to email you? yes
Should GPUGRID show your computers on its web site? yes

Default computer location ---

Maximum CPU % for graphics 0 ... 100 20

Run only the selected applications ACEMD 3: no
ACEMD 4: no
Quantum Chemistry (CPU): no
Quantum Chemistry (CPU, beta): no
Python Runtime (CPU, beta): no
Python Runtime (GPU, beta): yes

If no work for selected applications is available, accept work from other applications? yes

Use Graphics Processing Unit (GPU) if available yes
Use Central Processing Unit (CPU) yes

This is what my default location looks like.
The CPU is at the top and bottom.

Thanks! I have added the ACEMD 4 option.

Why are there 2 Use CPU boxes?

Where do you see these boxes?

Next week, we are aiming to start sending production WUs.

Just tried to run one of the new v1.01 tasks. Failed with this error message:

13:16:51 (224808): wrapper: running bin/conda-unpack ()
/usr/bin/env: ‘python’: No such file or directory
13:16:52 (224808): bin/conda-unpack exited; CPU time 0.000612
13:16:52 (224808): app exit status: 0x7f

Don't worry, I'll get rid of that conda-unpack.

One out of nine have passed so far. Here's the latest failure, I can't help with what code 195 means, just sharing.
Edit: Dr Google found it: "ERR_NO_APP_VERSION -195 - BOINC couldn't find the application's version number."
https://boinc.mundayweb.com/wiki/index.php?title=Error_code_-191_to_-200_explained

Your computers are hidden, so I can't see the details of the task which succeeded. Was it the most recent (implying that Raimondas has fixed conda-unpack already), or an old v100 left over from the previous (working) run?

Raimondas wrote:

About 400 WUs

He said earlier it would be a Linux only application. For now.

Raimondas has issued a new download - 2.86 gigabytes this time. It's downloading (for now) at around 7.5 megabytes/sec, which is great. But I fear that speeds may drop if too many people try to download it at once (as some people reported yesterday).

Other BOINC projects have overcome this problem by redirecting these big downloads for new releases to a caching online server service: because everyone is downloading the identical file, caching is viable and valuable.

The new file has now completed downloading, and is running as v1.02 - seemingly successfully. It started making accurate progress reports with 50%, and then progressed in 5% steps. It completed without errors in 6 minutes 44 sec (GTX 1660). Just waiting for a slot in the DDOS protection to report.

Task 32747705

Mine will take almost 11 hours to download. It might finish in time on a GTX 1070.

T13_7-RAIMIS_TEST-0-2-RND0280_1 did a bad thing. It took over from an acemd3 WU that was 88% done. It should wait its turn.
I'm checking to see if it'll Suspend On Checkpoint.

Edit: It got to 80% at 9:06 minutes and suspended. So it has at least one checkpoint.

My task took 9.5 hours to download, and ran for 8 minutes. Of those 8 minutes, the first several minutes showed zero load on the GPU. I assume it was unpacking the task then. So it really ran for only about 5 minutes on the GPU.
____________
Reno, NV
Team: SETI.USA

My task took 9.5 hours to download, and ran for 8 minutes. Of those 8 minutes, the first several minutes showed zero load on the GPU. I assume it was unpacking the task then. So it really ran for only about 5 minutes on the GPU.

My hosts received WUs, but they error out after 5 minutes:

<core_client_version>7.16.6</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
14:39:40 (150677): wrapper (7.7.26016): starting
14:39:40 (150677): wrapper (7.7.26016): starting
14:39:40 (150677): wrapper: running /bin/tar (xf x86_64-pc-linux-gnu__cuda1121.tar.bz2)
14:44:45 (150677): /bin/tar exited; CPU time 299.093084
14:44:45 (150677): wrapper: running bin/acemd (--boinc --device 0)
ERROR: /home/user/conda/conda-bld/acemd_1646158992086/work/src/mdio/amberparm.cpp line 76: Unsupported PRMTOP version!
14:44:46 (150677): bin/acemd exited; CPU time 0.205850
14:44:46 (150677): app exit status: 0x9e
14:44:46 (150677): called boinc_finish(195)

</stderr_txt>
]]>

I noticed that the only ones failing are v1.02. v2.19 ones validate (well, one did so far, the rest are still running). I'm a bit confused, so is v1 ACEMD 3 and v2 ACEMD 4? Or are both different versions of ACEMD 4?

You've also had errors like one I've just encountered: EXIT_DISK_LIMIT_EXCEEDED

Like you, my first failure was with Unsupported PRMTOP version! (task 32749480), followed by

<workunit>
<name>T1_NNPMM_1ajv_07-RAIMIS_NNPMM-0-2-RND3217</name>
<app_name>acemd4</app_name>
<version_num>102</version_num>
<rsc_fpops_est>5000000000000000.000000</rsc_fpops_est>
<rsc_fpops_bound>250000000000000000.000000</rsc_fpops_bound>
<rsc_memory_bound>4000000000.000000</rsc_memory_bound>
<rsc_disk_bound>10000000000.000000</rsc_disk_bound>

Could it have anything to do with your running Borg BOINC? Resistance is futile :-)

ah, so the failing tasks are actually acemd3?

I'm not sure what that disk limit error is about. All my relevant hosts are set to allow between 30-75 GB of space for BOINC. The event logs confirm this setting.

Also, unrelated and nothing new, but this site is such a supreme pain in the butt to navigate if you are running multiple hosts from the same external IP... Ridiculous.

We currently have:

Advanced molecular dynamics simulations for GPUs v2.19 - that's acemd3
Advanced molecular dynamics simulations for GPUs v1.02 - that's acemd4

Clear as mud ??!!

I'm not sure what that disk limit error is about.

And the next one - workunit 27113095, created 15:43:59 UTC - already has the fix in place. Kudos to whoever was watching our conversation here.

It's also running a lot slower - nearly two minutes for each 2.5% step - so hopefully we're starting to get some real science done.

And the next one - workunit 27113095, created 15:43:59 UTC - already has the fix in place. Kudos to whoever was watching our conversation here.

It's also running a lot slower - nearly two minutes for each 2.5% step - so hopefully we're starting to get some real science done.

Thanks for the explanation, RH. :)

Getting validating acemd4 tasks now.

Did the fix require the whole app to be re-downloaded? Please say no...

i just downloaded the 2.8GB tar package and it only took about a few minutes to download at the roughly 15Mbps transfer rate.

the ~500MB model file however is going quite slow at ~200Kbps and is dragging along
____________

Up to 3GB file. 3hr45min to get to 66% download.

3GB got downloaded in few minutes and unit looks to working fine.

Task: http://www.gpugrid.net/result.php?resultid=32751730

stderr out

is it really necessary to spend 4-5 mins every task to extract the same 3GB file? seems unnecessary. if it's not downloading a new file every time, then why extract the same file over and over? why not just leave it extracted?
____________

Up to 3GB file. 3hr45min to get to 66% download.

Since the original task, I have received several more, with no giant file to download again. Then I got a task for the same machine, and it is downloading another beast of a file, veeeery slowly. 4.5 hours so far, and only 29% complete. BOINCtasks says it 9.71KBps. Ouch.

____________
Reno, NV
Team: SETI.USA

Since the original task, I have received several more, with no giant file to download again. Then I got a task for the same machine, and it is downloading another beast of a file, veeeery slowly. 4.5 hours so far, and only 29% complete. BOINCtasks says it 9.71KBps. Ouch.

This project need to get their networking in order.

it's also interesting to see that this new ACEMD4 application does not have the same high PCIe bus use as the ACEMD3 app. should allow faster processing on systems that might be on smaller bus widths (cards on USB risers, cards plugged in via chipsets, older systems with PCIe 2.0 or less, etc)

it seems fairly bound on the memory bandwidth though. my 3080Ti is using up to about 80% memory bus which is a bit higher than the ACEMD3 app, fast cards with a smaller bus will be more bound. but this is better for speed I think, reaching back and forth to GPU RAM is a lot faster than reaching back and forth over the PCIe bus to system RAM.

still curious about the constant unpacking of the compressed file for every task. wastes 5 mins for each task doing the same thing over and over. if you just leave it unpacked then you save 5 mins on each subsequent task.
____________

still curious about the constant unpacking of the compressed file for every task. wastes 5 mins for each task doing the same thing over and over. if you just leave it unpacked then you save 5 mins on each subsequent task.

Another problem in P0_NNPMM_2p95_19-RAIMIS_NNPMM-0-20-RND5821_0 (task 32755591:

Exit status 198 (0xc6) EXIT_MEM_LIMIT_EXCEEDED
working set size > client RAM limit: 14361.16MB > 14353.11MB

unless they build a single binary file for processing, like most other projects do. then they just dump the binary into the projects folder and it gets used over and over.
____________

Another problem in P0_NNPMM_2p95_19-RAIMIS_NNPMM-0-20-RND5821_0 (task 32755591:

Exit status 198 (0xc6) EXIT_MEM_LIMIT_EXCEEDED
working set size > client RAM limit: 14361.16MB > 14353.11MB

And I had P0_NNPMM_1hpo_19-RAIMIS_NNPMM-1-20-RND4653_0 cancelled as well, same machine. Same sequence, also ran ~50 minutes. Maybe somebody pulled the batch?

thanks for giving some attention to the package decompression :). much faster now.

another comment I have is regarding the credit reward for the ACEMD4 tasks. they seem to be set to a static 1500cred. it might make sense to implement the same credit reward model from the ACEMD3 tasks (higher credit and actually scaled to difficulty/runtime).
____________

Thank you for your responses and explanations. Two further points - one an amplification, and the other something different.

Long download time of the software package.
The GPUGRID server is connected to a university network with a substantial bandwidth, so it is not a limiting factor. Most likely, your ISPs are throttling the download speed. As mentioned before, the software package has increased due to PyTorch, which by itself takes ~ 1 GB. I have removed some more unnecessary files, but still it is ~3 GB. The software package is cached by the Boinc client, so it is only downloaded once for each app version and reused.

yeah I agree about the est flops size. it throws things all out of wack. my task now which will run for about 3hrs, started with an estimated runtime of 10 days lol.
____________

Hello everyone,

after restarting the boinc-client.service the progress indication reset from about 35% to just 1% and ist working from there (ACEMD 4 simulations for GPUs 1.03). Rather surprising that the task did not manage to save results and work from there as other applications are.

Any explanation?

Best
Sven

Thank you for your responses and explanations. Two further points - one an amplification, and the other something different.

Long download time of the software package.
The GPUGRID server is connected to a university network with a substantial bandwidth, so it is not a limiting factor. Most likely, your ISPs are throttling the download speed. As mentioned before, the software package has increased due to PyTorch, which by itself takes ~ 1 GB. I have removed some more unnecessary files, but still it is ~3 GB. The software package is cached by the Boinc client, so it is only downloaded once for each app version and reused.

I'm on the end of a pretty stable 70 megabit ISP download connection - I don't think they are throttling it, either. I think the answer probably lies in the intermediate routing - the switching centres and interconnectors that the signals pass through between the University and our ISPs. Sometimes they work well, sometimes they drop packets, and sometimes they slow to a crawl. I don't think that's something that can be fixed at the research lab level, but it might be worth mentioning it upstream to the University's technical support team - they might be able to monitor it.

Another 3+ GB download, for ACEMD4 v1.03

This one is coming down at 6MB/sec (so far - the average speed figure is still stabilising while the data download shares the connection), but it looks on target to finish within 5 minutes. Not a problem by itself, but users with slow connections might choose to delay requesting new work until the surge is over.

another comment I have is regarding the credit reward for the ACEMD4 tasks. they seem to be set to a static 1500cred. it might make sense to implement the same credit reward model from the ACEMD3 tasks (higher credit and actually scaled to difficulty/runtime).

Still having issues with the acemd4 application.

Time exceeded 1800 seconds errors still.

Can't download the python/anaconda environment in time.

<core_client_version>7.17.0</core_client_version>
<![CDATA[
<message>
exceeded elapsed time limit 1803.39 (1000000.00G/554.51G)</message>
<stderr_txt>
08:51:16 (3808596): wrapper (7.7.26016): starting
08:51:16 (3808596): wrapper (7.7.26016): starting
08:51:16 (3808596): wrapper: running /bin/tar (xf x86_64-pc-linux-gnu__cuda1121.tar.gz)
08:52:11 (3808596): /bin/tar exited; CPU time 52.866473
08:52:11 (3808596): wrapper: running bin/acemd (--boinc --device 0)

</stderr_txt>
]]>

Still having issues with the acemd4 application.

Time exceeded 1800 seconds errors still.

Can't download the python/anaconda environment in time.

<core_client_version>7.17.0</core_client_version>
<![CDATA[
<message>
exceeded elapsed time limit 1803.39 (1000000.00G/554.51G)</message>
<stderr_txt>
08:51:16 (3808596): wrapper (7.7.26016): starting
08:51:16 (3808596): wrapper (7.7.26016): starting
08:51:16 (3808596): wrapper: running /bin/tar (xf x86_64-pc-linux-gnu__cuda1121.tar.gz)
08:52:11 (3808596): /bin/tar exited; CPU time 52.866473
08:52:11 (3808596): wrapper: running bin/acemd (--boinc --device 0)

</stderr_txt>
]]>

You are probably correct Ian. I fixated on the 1800 seconds error since that was the errors I saw with the python tasks.

But since this is acemd4, no python involved here I believe.

The reduction in estimated gflops was likely the culprit.

Got an ACEMD4 task on Linux: T0_NNPMM_frag_00-RAIMIS_NNPMM-1-3-RND2497_5. The five previous attempts have all timed out, in between 2,400 seconds and 5,000 seconds.

My metrics are
<flops>181962433195.469788</flops>
<rsc_fpops_est>1000000000000.000000</rsc_fpops_est>
<rsc_fpops_bound>1000000000000000.000000</rsc_fpops_bound>
<duration_correction_factor>12.396821</duration_correction_factor>

size / speed gives 5.5 seconds uncorrected estimate. With DCF, that becomes 68 seconds, and that's what's displayed in BOINC Manager.

'bound' is 1000 x 'est', so it will time out in 5,500 seconds (if DCF is ignored, as I suspect it is). I'll bump them both by 1000 x, and see how it fares while I'm out.

Edit - with a new estimate of 18.5 hours, and a 24 hour deadline, it's gone straight into panic mode. Should get an idea how its doing before I go to bed.

It's reached 50% in 2 hours 7 minutes, so this task is heading for about four and a quarter hours on my GTX 1660 Super. That would have failed without manual intervention.

@ Raimondas - you need to consider both speed and size when making adjustments.

File size too big by both users on upload.
https://www.gpugrid.net/result.php?resultid=32882663

Just take all the limits and x100000000.

Ok, not that much, but its sad tasks error out on artificial limits esp on upload.

Thu 14 Apr 2022 09:27:26 AM CDT | GPUGRID | Aborting task T1_GAFF2_frag_00-RAIMIS_NNPMM-0-1-RND6653_1: exceeded elapsed time limit 7231.33 (1000000.00G/138.29G)
Thu 14 Apr 2022 09:27:28 AM CDT | GPUGRID | Computation for task T1_GAFF2_frag_00-RAIMIS_NNPMM-0-1-RND6653_1 finished
Thu 14 Apr 2022 09:27:28 AM CDT | GPUGRID | Output file T1_GAFF2_frag_00-RAIMIS_NNPMM-0-1-RND6653_1_4 for task T1_GAFF2_frag_00-RAIMIS_NNPMM-0-1-RND6653_1 exceeds size limit.
Thu 14 Apr 2022 09:27:28 AM CDT | GPUGRID | File size: 137187308.000000 bytes. Limit: 10000000.000000 bytes

Still getting elapsed time limit errors. Looks like the estimated GFLOPS was changed but still not enough.

exceeded elapsed time limit 2675.08 (1000000.00G/373.82G)</message>

exceeded elapsed time limit 1758.43 (1000000.00G/568.69G)</message>

exceeded elapsed time limit 1803.39 (1000000.00G/554.51G)</message>

bombed out after 25mins and 20% completion on a 3080Ti

exceeded elapsed time limit 1538.81


____________

Just got T1_GAFF2_frag_00-RAIMIS_NNPMM-0-1-RND6653_5.

Mine don't (usually) start immediately, so I could get to it before it started. Added x1000 to the fpops measures, x100 to the _4 upload size (thanks captainjack). It's running now, should finish overnight.

got another new task.

flops bound had been increased by 10x from previous values (based on previous comments of what the value used to be).

however, the max_nbytes of the _4 output file has not been increased at all, so I expect another computation error if the file size ends up too big.

computation has already begun, and it's in a system with mixed GPUs so stopping BOINC to edit the size limit and restarting is not a great option, risks restarting on another GPU and insta-error.

as far as run behavior:
on an RTX 3080Ti
~80% GPU core use
~50% GPU memory bus use
~1% PCIe bus use
~2300MB VRAM used
~265W (with a 300W limit set)

not really taking full advantage of the GPU resources.
____________

however, the max_nbytes of the _4 output file has not been increased at all, so I expect another computation error if the file size ends up too big.

upload failure: <file_xfer_error>
<file_name>T2_NNPMM_frag_01-RAIMIS_NNPMM-0-2-RND4664_0_4</file_name>
<error_code>-131 (file size too big)</error_code>
</file_xfer_error>

Tue 19 Apr 2022 02:13:28 PM EDT | GPUGRID | File size: 20443520.000000 bytes. Limit: 10000000.000000 bytes

it's important for the devs to see that these error out rather than fiddling with things on my end to ensure I get credit. otherwise they may be under the impression that it's not a problem.

File size: 137187308.000000 bytes. Limit: 10000000.000000 bytes

i just edited with that info from the log.

____________

Two more, half the run time, and 10x the file size for _4 output file. both run on 3080Tis again.

odd that these ones showed different run behavior. more similar to how the ACEMD3 app works.

~96% GPU core use
~1-2% GPU memory bus use
~12% PCIe bus use

T2_GAFF2_frag_02-RAIMIS_NNPMM-0-1-RND3120_1

Tue 19 Apr 2022 07:54:14 PM EDT | GPUGRID | File size: 213191804.000000 bytes. Limit: 10000000.000000 bytes

Tue 19 Apr 2022 07:53:26 PM EDT | GPUGRID | File size: 213539276.000000 bytes. Limit: 10000000.000000 bytes

Same thing here. Ran 2 1/2 hours to completion and then failed on too large an upload file.

upload failure: <file_xfer_error>
<file_name>T2_GAFF2_frag_02-RAIMIS_NNPMM-0-1-RND3120_2_4</file_name>
<error_code>-131 (file size too big)</error_code>

Waste of resources.

Wish the app admin dev would fix this issue. Like right now!

Woke up this morning to find two unstarted ACEMD4 tasks awaiting my attention (and downloaded a third since).

I've fixed the file size problem, partly to stop them recirculating to other users, but also to get some real science done, if possible.

The initial estimates (10 - 12 minutes, with DCF) look tight, but I've left them alone to check if the devs' adjustments are adequate.

the estimated runtime of my tasks were very close. at inception they started right at around 2hrs and that's how long it took. that was with no adjustments. so the estimated flops seems correct.

they just need to bump the file size limit by at least 25x. maybe 100x to be safe. it really is a waste to trash good work on something like an arbitrary and artificial file size limit.
____________

The other thing they still have to sort out is checkpointing. I've just come home to find that BOINC had downloaded and started a new ACEMD4 task - for some reason, it pre-empted the two Einstein tasks running on the GPU I dedicate to GPUGrid. That must have been EDF kicking in, but with a six hour cache and a 24 hour deadline, it shouldn't have been needed.

Anyway, I applied the upload correction, and the task restarted from 1% - I had stopped it at something like 16% in 44 minutes. That implies a longer runtime than this morning's group, so the output size may be larger as well. 25x may not be enough, if not all tasks are created equal. I'll check it when it finishes.

Another 3 hours wasted because of too large an upload file.

I've fixed the file size problem, partly to stop them recirculating to other users, but also to get some real science done, if possible.

I've fixed the file size problem, partly to stop them recirculating to other users, but also to get some real science done, if possible.

It is highly likely that the one (and only) at current Server Status page "successful users in last 24h" for ACEMD 4 tasks, is you ;-)

That implies a longer runtime than this morning's group, so the output size may be larger as well.

That implies a longer runtime than this morning's group, so the output size may be larger as well.

Turned out not to be a problem - the file size was 20.4 MB, despite running nearly twice as long. I can't see anything about the filename which would reliably distinguish between "quick run, large file" and "slow run, small file" tasks.

Yup, that works.

Got another Python. I will let it run its course this time.
BOINC thinks 167 days and 19 hours after just 3 hours run time.
CPU usage is 104%

Estimated app speed 3,176.92 GFLOPs/sec
Virtual memory size 5,589.28 MB
Working set size 2,517.45 MB

Running on a GTX 1080.

a handful of new ACEMD4 tasks went out today. I got one.

worked fine this time. great job :)

T3_NNPMM_frag_01-RAIMIS_NNPMM-1-2-RND2943_0

looks like they finally ironed out the config issues. open the floodgates :)
____________

Same here. Got two tasks today that completed and validated successfully.

Agree . . . . open the floodgates for more.

I also got yesterday an ACEMD 4 task:
T3_NNPMM_frag_02-RAIMIS_NNPMM-1-2-RND2618_1
It was processed to the end and validated successfully.

However, I noticed that it belonged to branch work unit #27219575, and it had failed at a previous system. The reported message:

exceeded elapsed time limit 16199.05 (10000000.00G/617.32G)

Yes, bummer for missing the expected compute time by less than 90 seconds.

Looks like the fpops estimate needs to be increased by as little as 500 to get the fast cards like his 3080 Ti to meet the estimated crunching time.

Maybe pad it out by another 10K or 100K to be safe.

my 3080Ti completed one no problem. I think something was wrong with that persons machine and it was hung up or there was something slowing down the computation. My 3080Ti completed it in half the time.

many people are blissfully unaware that you need to leave some breathing room for the CPU on GPU tasks. they just set CPU use to 100% and walk away. especially when the project has set <1.0 CPU use per GPU task (which BOINC basically sees as 0). CPU overcommit is common.
____________

I doubt that there's much large-scale tuning of flops (the speed measure) by general users out in the community. The few who post here regularly might well have tweaked it, of course.

Instead, it's more likely that the BOINC server software is still tuning it. In general,

1) The initial value for a new application is initialised to some very low value. Low speed ==> very long estimated run times.

2) After the first 100 "completed" (success, valid) tasks have been returned - by the fastest hosts in the population of users, naturally - the running average of the most recent 100 completed tasks is used to replace the initial values.

3) Once any single host has reached 11 "completed" tasks, it's own individual average speed is used as the basis for future tasks.

That's my best attempt at understanding the combined effect of
Client scheduling changes
Job runtime estimation
But only David Anderson would have an authoritative overview of the current server code.

fpops (the size estimate) is much simpler: you have complete control of the value declared by the server, through your workunit generator.

I'm loaded up as much as possible for now. one on each GPU. short 1-day deadlines (can't remember if they were always that short)

but i'm getting interesting error messages when asking for more work.

two systems report that it wont send more work because they "wont complete in time", but that seems at odds with the fact that I have a 3-day cache set and BOINC's estimates are that it will take only ~2hours to complete. so why does it think it wont complete in time?

another system (7-GPU) says I do not have enough disk space, claiming i need an additional ~6GB, saying I have 12GB free and need 18GB for the task. but again this is at odds with BOINC preferences set to allow ~95% disk use, and that I have 100+GB free (BOINC reports this as "free, available to BOINC"). although this system does have ~86GB being used for GPUGRID alone. is there a 100GB per project limit somewhere? otherwise it seems nonsensical and my settings should be allowing plenty of space.
____________

While I was typing the previous post, the server sent my host 132158 task 32888461.

The server has sent me

Received 25 tasks on Linux. Ran about 45 - 60 seconds. All error. Error message:

process exited with code 195 (0xc3, -61)

Received 25 tasks on Linux. Ran about 45 - 60 seconds. All error. Error message:

process exited with code 195 (0xc3, -61)

Received 0 tasks on Windows.

captainjack is running a GTX 970 under Linux, and the acemd child is failing with

has anyone had successful ACEMD4 runs on Maxwell or Pascall cards?

captainjack is running a GTX 970 under Linux, and the acemd child is failing with

app exit status: 0x87

I don't recognise that one, but it should be in somebody's documentation.

has anyone had successful ACEMD4 runs on Maxwell or Pascall cards?

I just allowed tasks on my 1080Ti to see if it will run on Pascal.

has anyone had successful ACEMD4 runs on Maxwell or Pascall cards?

I just allowed tasks on my 1080Ti to see if it will run on Pascal.

that'll be a good test. thanks.

has anyone had successful ACEMD4 runs on Maxwell or Pascall cards?

I just allowed tasks on my 1080Ti to see if it will run on Pascal.

that'll be a good test. thanks.

It will be a while before I can report success or failure.
Have to download the 3.5GB application file still before starting the task.

Pascal works: https://gpugrid.net/result.php?resultid=32888358
____________

Mine just started. So far, so good.

I had a lot of _0..._5 failures before getting to one of mine and they were all on low RAM Maxwell or low RAM Pascal cards like a 1050 or 950.

So maybe the low RAM count cards are the suspect ones.

Looks like even a 8GB 1070 works. My 11GB 1080 Ti should have no issues.

The 1080 Ti can crunch the acemd4 tasks with no issues.
1000 seconds faster than my 2070 Supers or 2080's

i think the CPU speed plays a pretty significant roll in GPU speed on these tasks. so your fast 5950X is helping out a good bit.

my 300W 3080Ti under the 7443P runs roughly 700s faster than equivalent 300W 3080Ti under a 7402P.
____________

Same speed for all my 5950X hosts which the 1080 Ti is the newest. So the cpu speed is not the reason for the speedup.

Must be 11GB VRAM versus 8GB VRAM on the 2080's, 2070 Supers

Checkpointing is still not active.

Both my Linux machines crashed hard overnight - I've yet to work out why. But one machine I've restarted had an ACEMD 4 at about the midway point: it's started again from 1%.

Edit - very odd. Second machine looks completely inert - no post, no beep, no video output. But BOINC remote monitoring shows all tasks are running, including both GPUs (I got a clue from the SSD activity LED). I'm draining the cache - may call out for some help later.

exceeded elapsed time limit 12932.15 (10000000.00G/773.27G)</message>
exceeded elapsed time limit 7695.31 (10000000.00G/1299.49G)</message>

Why are there time limits? Up them!

Same speed for all my 5950X hosts which the 1080 Ti is the newest. So the cpu speed is not the reason for the speedup.

Must be 11GB VRAM versus 8GB VRAM on the 2080's, 2070 Supers

exceeded elapsed time limit 12932.15 (10000000.00G/773.27G)</message>
exceeded elapsed time limit 7695.31 (10000000.00G/1299.49G)</message>

Why are there time limits? Up them!

Checkpointing is still not active.

exceeded elapsed time limit 12932.15 (10000000.00G/773.27G)</message>
exceeded elapsed time limit 7695.31 (10000000.00G/1299.49G)</message>

Why are there time limits? Up them!

your hosts are hidden. what are the system specifics? what CPU/RAM specs, etc.

the time limit is set by BOINC, not the project directly. BOINC bases the limits on the speed of the device and the estimated flops set by the project.