I'm creating some experimental tasks for the Python app (made Beta). They are Linux and CUDA specific and serve in preparation for future batches.

They may use a relatively large amount of disk space (order of 1-10 GB) which persists between runs, and is cleared if you reset the project.

Looks harmless, thanks for reporting. It's because the "boinc" user doesn't have a HOME directory I think.

I got one of these tasks which confused me as I have not set "accept beta applications" in my project preferences.

Failed after 1200 seconds.

Any idea why I got this task even when I have not accepted the app through beta settings?

https://www.gpugrid.net/result.php?resultid=30508976

What is the difference between these test Python apps and the standard one? Is it just that this application is coded in Python? what language are the default apps coded in?
____________

Both apps are wrappered. One is the stock acemd3 and I assume is written in some form of C.

The new Anaconda Python task is a conda application. And Python.

I think Toni is going to have to explain what and how these new tasks and application work.

Very strange behavior. I think the conda and python parts run first and communicate with the project doing some intermediary calculation/configuration/formatting or something. Lots of upstream network activity and nothing going on in the client transfers screen.

I saw the tasks get to 100% progress and no time remaining and then stall out. No upload of the finished task.

Looked away from the machine and looked again and now both tasks have reset their progress and now have 3 hours to run.

I first saw conda show up in the process list and now that has disappeared to be replaced with a acemd3 and python process for each task.

Must be doing something other than insta-failing that the previous tries.

CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://conda.anaconda.org/conda-forge/linux-64/_libgcc_mutex-0.1-conda_forge.tar.bz2>
Elapsed: -

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.

Boy, mixing both regular acemd3 and the python anaconda tasks sure F*s up the APR for both tasks. The insanely low APR for the Python tasks is forcing all GPUGrid tasks into High Priority.

The regular acemd3 tasks are getting 3-6 day estimated completions.

Boy, mixing both regular acemd3 and the python anaconda tasks sure F*s up the APR for both tasks. The insanely low APR for the Python tasks is forcing all GPUGrid tasks into High Priority.

The regular acemd3 tasks are getting 3-6 day estimated completions.

Looks like I have 11 successful tasks, and 2 failures.

the two failures both failed with "196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED" after a few mins and on different hosts.
https://www.gpugrid.net/result.php?resultid=31680145
https://www.gpugrid.net/result.php?resultid=31678136

curious, since both systems have plenty of free space, and I've allowed BOINC to use 90% of it.

these tasks also have much different behavior compared to the default new version acemd tasks. and they don't seem well optimized yet.
-less reliance on PCIe bandwidth, seeing 2-8% PCIe 3.0 bus utilization
-more reliance on GPU VRAM, seeing 2-3GB memory used
-less GPU utilization, seeing 65-85% GPU utilization. (maybe more dependent on a fast CPU/mem subsystem. my 3900X system gets better GPU% than my slower EPYC systems)

contrast that with the default acemd3 tasks:
-25-50% PCIe 3.0 bus utilization
-about 500MB GPU VRAM used
-95+% GPU utilization

thinking about the GPU utilization being dependent on CPU speed. It could also have to do with the relative speed between the GPU:CPU. just something I observed on my systems. slower GPUs seem to tolerate slower CPUs better, which makes sense if the CPU speed is a limiting factor.

Ryzen 3900X @4.20GHz w/ 2080ti = 85% GPU Utilization
EPYC 7402P @3.30GHz w/ 2080ti = 65% GPU Utilization
EPYC 7402P @3.30GHz w/ 2070 = 76% GPU Utilization
EPYC 7642 @2.80GHz w/ 1660Super = 71% GPU Utilization

needs more optimization IMO. the default app sees much better performance keeping the GPU fully loaded.

Boy, mixing both regular acemd3 and the python anaconda tasks sure F*s up the APR for both tasks. The insanely low APR for the Python tasks is forcing all GPUGrid tasks into High Priority.

The regular acemd3 tasks are getting 3-6 day estimated completions.

Yeah, after I wrote that I realized I meant the DCF is what is messing up the runtime estimations.

I wonder if the regular acemd3 tasks will ever get their normal DCF's back to normal.

I haven't run ANY of my other gpu project tasks since these anaconda python tasks have shown up. I will eventually when the other projects deadlines approach of course.

what's DCF?
____________

what's DCF?

You can't talk about 'their DCFs' - there is only one (there could have been more than one, but that's the way David chose to play it)

You can see it in BOINC Manager, on the Projects|properties dialog. If it gets really, really high (above 90), it'll inch downwards at 1% per task. Below 90, it'll speed up to 10% par task. The standard advice used to be "two weeks to stabilise", but with modern machines (multi-core, multi-GPU, and faster), the tasks fly by, and it should be quicker.

What is also messed up is the size of the Anaconda Python task estimated computation size shown in the task properties.

The ones I crunched were only set for 3,000 GFLOPS.

The regular acemd3 tasks are set for 5,000,000 GFLOPS.

This also probably influenced the wildly inaccurate DCF's for the new python tasks.

You can't talk about 'their DCFs' - there is only one (there could have been more than one, but that's the way David chose to play it)

You can see it in BOINC Manager, on the Projects|properties dialog. If it gets really, really high (above 90), it'll inch downwards at 1% per task. Below 90, it'll speed up to 10% par task. The standard advice used to be "two weeks to stabilise", but with modern machines (multi-core, multi-GPU, and faster), the tasks fly by, and it should be quicker.

What is also messed up is the size of the Anaconda Python task estimated computation size shown in the task properties.

The ones I crunched were only set for 3,000 GFLOPS.

The regular acemd3 tasks are set for 5,000,000 GFLOPS.

This also probably influenced the wildly inaccurate DCF's for the new python tasks.

I've got one running now on an RTX 2070S and the only real issue is low GPU utilization (60-70%). The current task is using ~2 GB of VRAM and ~3 GB of system RAM. I have one thread free on a ryzen 3900X to support the GPU and that thread is running at 100%. This computer has complete 3 of the new python tasks successfully.

Linux Mint 20; Driver Version: 440.95.01; CUDA Version: 10.2

I've got one running now on an RTX 2070S and the only real issue is low GPU utilization (60-70%). The current task is using ~2 GB of VRAM and ~3 GB of system RAM. I have one thread free on a ryzen 3900X to support the GPU and that thread is running at 100%. This computer has complete 3 of the new python tasks successfully.

Linux Mint 20; Driver Version: 440.95.01; CUDA Version: 10.2

There's an explanation for 20 credit tasks over at Rosetta.
Has to do with a task being interrupted in calculation and restarted if I remember correctly.

what kind of BOINC install do you have? does it run as a service? or a standalone install that runs from an executable?

I'm almost positive he's running a standalone install.
____________

I've got one running now on an RTX 2070S and the only real issue is low GPU utilization (60-70%). The current task is using ~2 GB of VRAM and ~3 GB of system RAM. I have one thread free on a ryzen 3900X to support the GPU and that thread is running at 100%. This computer has complete 3 of the new python tasks successfully.

Linux Mint 20; Driver Version: 440.95.01; CUDA Version: 10.2

what kind of BOINC install do you have? does it run as a service? or a standalone install that runs from an executable?

what is the clock speed of your 3900X and memory speed as well?

try letting there be 2 spare free threads (so you have one doing nothing) to avoid maxing out the CPU to 100% utilization on all threads. this is known to slow down GPU work. this might increase your GPU utilization a bit.

So, then likely the main difference is that Mr. Kevvy is using the older glibc 2.29 instead of the glibc 2.31 that we Ubuntu 20 users are running.

Boinc runs as a service and was installed from the Mint repository (version 17.16.6). The CPU clock speed is 3.9 GHz and the RAM is DDR4 3200 CL16. I did free up another thread but I didn't see an obvious difference in GPU utilization.

So, then likely the main difference is that Mr. Kevvy is using the older glibc 2.29 instead of the glibc 2.31 that we Ubuntu 20 users are running.

difference in what sense?

you and I both have glibc 2.31 and we both have a bunch of successful completions. looks like Kevvy's Ubuntu 20 systems also have 2.31. all of us with these Ubuntu 20.04 systems have successful completions.

but of all of his Linux Mint (based on Ubuntu 19) systems, none have completed a single Python task successfully. I'm not sure if it's a problem with Linux Mint or what. I'm not sure its necessarily anything to do with the GLIBC since his error messages are varied, and none mention GLIBC as being the cause. It could just be that the app has some bugs to work out when running in different environments.

Mint 20 is based on Ubuntu 20.04 and has glibc 2.31. The 2 computers I have running GPUGrid have Mint 20 installed and the RTX cards on those computers are completing the new python tasks successfully.

Yes, I had over a half dozen failed tasks before the first successful task.
Why I was wondering if the failed tasks report the failed configuration upstream and change the future task configuration.

Pretty sure lots of prerequisite software is downloaded first from conda and configured on the system before finally actually starting real crunching.

And the configuration downloads happen for each task I think.

Not just some initial download and from then on all the file are static.

FYI, these tasks don't checkpoint properly.

if you need to stop BOINC or the system experiences a power outage, the tasks restart from the beginning (10%) but the task timer still tracks from where it left off even though the task restarted. if the tasks were short like MDAD (but MDAD checkpoints properly) it wouldn't be a huge problem. but when they run for 4-5hrs and need to start over for any interruption, it's a bit of a kick in the pants. even worse when these restarted tasks only get 20cred for up to 2x total run time. not worth finishing it at that point.

additionally as has been mentioned in the other thread, these tasks wreak havoc on the system's DCF since it seems to be set incorrectly for these tasks. you get these tasks that make boinc thing they will complete in 10 seconds, and they end up taking 4hrs, so BOINC counters with inflating the run time of normal tasks to 10+ days when they only take 20-40 min lol. and it swings wildly back and forth depending how many of each type you've completed.

and credit reward, other than being about 10x normal for tasks of this runtime, seems only tied to FLOPS and runtime without accounting for efficiency at all.

my 3900X/2080ti completes tasks on average much faster than my EPYC/2080ti system since the 3900X system is running higher GPU utilization allowing faster run times. but the 3900X system earns proportionally less credit. so both systems end up earning the same amount of credit per card. the 3900X/2080ti should be earning more credit since it's doing more tasks. reward is being overinflated for tasks that have longer run time due to inefficiency. it seems tied only to raw runtime and estimated flops. i understand that tasks can have varying run times, but if you wont account for efficiency you need to have a static reward not dependent on runtime at all. for reference, a static reward of about 175,000 would, on average, bring these tasks near the MDAD for cred/unit-time.
____________

My host switch to another project task then resume and after a while i had to update system and restart. So it indeed fail to resume from last state so it looks like checkpoint was far behind or no checkpoint at all. Time stay at around 2 hour which was hours behind and est percentage locked at 10%

I aborted it next day as it reached 14 hours.

https://www.gpugrid.net/result.php?resultid=31701824

I would expect it not to be fully working and checkpoint added later on. There is much testing of this but low info for us still so we need to take it for what it is and deal with it if the don't work.

Two outstanding issues are over-crediting (I am using some default BOINC formula) and, as far as i understand, the flops estimate (?).

Thanks for the details.

The flops estimate

An App which installs a self-contained Conda install

over-crediting

Over-crediting?

Over-crediting?

OK, make that 'inconsistent crediting'. Mine are all in the 600,000 - 900,000 range, for much the same runtime on a 1660 Ti.

Host 508381

Two outstanding issues are over-crediting (I am using some default BOINC formula) and, as far as i understand, the flops estimate (?).

Over-crediting? I am seeing the opposite problem.

https://www.gpugrid.net/result.php?resultid=31902208

20.83 credits for 4.5 hours of run time on an RTX 2080 Ti. That is practically nothing. And this is not a one-off. All my tasks so far are similar.

We should perhaps mention the lack of effective checkpointing while we have Toni's attention. Even though the tasks claim to checkpoint every 0.9% (after the initial 10% allowed for the setup), the apps are unable to resume from the point previously reached.

Over-crediting? I am seeing the opposite problem.

https://www.gpugrid.net/result.php?resultid=31902208

20.83 credits for 4.5 hours of run time on an RTX 2080 Ti. That is practically nothing. And this is not a one-off. All my tasks so far are similar.

this happens when the task is interrupted. started and resumed. you can't interrupt these tasks at all.

Over-crediting? I am seeing the opposite problem.

https://www.gpugrid.net/result.php?resultid=31902208

20.83 credits for 4.5 hours of run time on an RTX 2080 Ti. That is practically nothing. And this is not a one-off. All my tasks so far are similar.

this happens when the task is interrupted. started and resumed. you can't interrupt these tasks at all.

I'll check that out. But I have not suspended or otherwise interrupted any tasks. Unless BOINC is doing that without my knowledge. But I don't think so.

you also appear to have your hosts setup to ONLY crunch these beta tasks. is there a reason for that?

does your system process the normal tasks fine? maybe it's something going on with your system as a whole.

you also appear to have your hosts setup to ONLY crunch these beta tasks. is there a reason for that?

I have reached my wuprop goals for the other apps. So I am interested in only this particular app (for now).

does your system process the normal tasks fine? maybe it's something going on with your system as a whole.

Yep, all the other apps run fine, both here and on other projects.

Two outstanding issues are over-crediting (I am using some default BOINC formula) and, as far as i understand, the flops estimate (?).

CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://conda.anaconda.org/conda-forge/linux-64/_libgcc_mutex-0.1-conda_forge.tar.bz2>
Elapsed: -

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.

A second, identical machine, except it has dual RTX 1660 Ti cards, finally got some work. The tasks reported and were awarded the large credits. So that rules out the question WRT BOINC version. FWIW, that version of BOINC is the latest available from the repository.

So maybe it is due to interruptions after all, and I am just unaware? I am running some more tasks now, and will check again in the morning.
____________
Reno, NV
Team: SETI.USA

A second, identical machine, except it has dual RTX 1660 Ti cards, finally got some work. The tasks reported and were awarded the large credits. So that rules out the question WRT BOINC version. FWIW, that version of BOINC is the latest available from the repository.

So maybe it is due to interruptions after all, and I am just unaware? I am running some more tasks now, and will check again in the morning.

i also verified that restarting ALONE, wont necessarily trigger the 20-credit reward.

it depends WHEN you restart it. if you restart the task early, early enough that the combined runtime wont reach a point where you wont come close to the 2mil credit mark, you'll get the normal points

this task here: https://www.gpugrid.net/result.php?resultid=31934720

I restarted this task about 10-15mins into it. and it started over from the 10% mark, ran to completion, and still got normal crediting. and well below the threshold.
____________

A second, identical machine, except it has dual RTX 1660 Ti cards, finally got some work. The tasks reported and were awarded the large credits. So that rules out the question WRT BOINC version. FWIW, that version of BOINC is the latest available from the repository.

So maybe it is due to interruptions after all, and I am just unaware? I am running some more tasks now, and will check again in the morning.

aaaand your 2080ti just completed a task and got credit with the new BOINC version. called it.

http://www.gpugrid.net/result.php?resultid=31951281
____________

I'm willing to bet that if one of your tasks on that 1660ti system runs for ~30,000-40,000 seconds, it gets hit with 20 credits. ¯\_(ツ)_/¯

After upgrading all the BOINC clients, the tasks are erroring out. Ugh.
____________
Reno, NV
Team: SETI.USA

they were working fine on your 2080ti system when you had 7.17.0. why change it?

but the issue you're having now looks like the same issue that richard was dealing with here: https://www.gpugrid.net/forum_thread.php?id=5204

that thread has the steps they took to fix it. it's a permissions issue.
____________

they were working fine on your 2080ti system when you had 7.17.0. why change it?

but the issue you're having now looks like the same issue that richard was dealing with here: https://www.gpugrid.net/forum_thread.php?id=5204

that thread has the steps they took to fix it. it's a permissions issue.

There is such a thing. It’s the development branch. All of my systems use a version of BOINC based on 7.17.0 :)
____________

Well sure. I meant a released version.
____________
Reno, NV
Team: SETI.USA

So long start to end run times cause the 20 credit issue, not that they were restarted. But tasks that are interrupted cause them to restart at 0, thus having a longer start to end run time.

1070 or 1070Ti
27,656.18s received 1,316,998.40
42,652.74 received 20.83

1080Ti
21,508.23 received 1,694,500.25
25,133.86, 29,742.04, 38,297.41 tasks received 20.83

I doubt they were interrupted with the tasks being High Priority and nothing else but GPUGrid in the BOINC queue.

yup I confirmed this. I manually restarted a task that didnt run very long and it didnt have the issue.

the issue only happens if your credit reward will be greater than about 1.9 million.

take some of your completed tasks, divide the total credit by the runtime seconds to figure how much credit you earn per second. then figure how many seconds you need to hit 1.9 million, and that's the runtime limit for your system, anything over that and you get the 20-credit bug
____________

Why is the number of tasks in progress dwindling? Are no new tasks being issued?
____________
Reno, NV
Team: SETI.USA

most of the Python tasks I've received in the last 3 days have been "_0", so that indicates brand new. and a few resends here and there.

the rate in which they are creating them is likely slowed, and the demand is high since points chasers have come to try to snatch them up. also possible that the recent new (_0) ones are only recreations of earlier failed tasks that had some bug that needed fixing. it does seem that this run is concluding.
____________

...
Also Warnings about path not found:

WARNING conda.core.envs_manager:register_env(50): Unable to register environment. Path not writable or missing. environment location: /var/lib/boinc-client/projects/www.gpugrid.net/miniconda registry file: /root/.conda/environments.txt

Registry file location ( /root/ ) will not be accessible to boinc user unless conda is already installed on the host (by root user) and conda file is world readable
...

...
Also Warnings about path not found:

WARNING conda.core.envs_manager:register_env(50): Unable to register environment. Path not writable or missing. environment location: /var/lib/boinc-client/projects/www.gpugrid.net/miniconda registry file: /root/.conda/environments.txt

Registry file location ( /root/ ) will not be accessible to boinc user unless conda is already installed on the host (by root user) and conda file is world readable
...

Looks harmless, thanks for reporting. It's because the "boinc" user doesn't have a HOME directory I think.

I'm creating some experimental tasks for the Python app (made Beta). They are Linux and CUDA specific and serve in preparation for future batches.

They may use a relatively large amount of disk space (order of 1-10 GB) which persists between runs, and is cleared if you reset the project.

I'm creating some experimental tasks for the Python app (made Beta). They are Linux and CUDA specific and serve in preparation for future batches.

They may use a relatively large amount of disk space (order of 1-10 GB) which persists between runs, and is cleared if you reset the project.

What type of card minimum for this app. My 980Ti don't load WU.

I'm creating some experimental tasks for the Python app (made Beta). They are Linux and CUDA specific and serve in preparation for future batches.

They may use a relatively large amount of disk space (order of 1-10 GB) which persists between runs, and is cleared if you reset the project.

What type of card minimum for this app. My 980Ti don't load WU.

In "GPUGRID Preferences", ensure you select "Python Runtime (beta)" and "Run test applications?"
Your GPU, driver and OS should run these tasks fine

All of these seem now to error out after computation has finished. On several computers:

What causes this and how it can be fixed?

What causes this and how it can be fixed?

I've just posted instructions in the Anaconda Python 3 Environment v4.01 failures thread (Number Crunching).

Read through the whole post. If you don't understand anything, or you don't know how to do any of the steps I've described - back away. Don't even attempt it until you're sure. You have to edit a very important, protected, file - and that needs care and experience.

Stopping and starting the client is a recipe for instant errors, and where successful, this process will need to be repeated for every time you download new tasks. not really a viable option unless you want to babysit the system all day.

They're working on something...

WU 26917726

What causes this and how it can be fixed?

I've just posted instructions in the Anaconda Python 3 Environment v4.01 failures thread (Number Crunching).

Read through the whole post. If you don't understand anything, or you don't know how to do any of the steps I've described - back away. Don't even attempt it until you're sure. You have to edit a very important, protected, file - and that needs care and experience.

really needs to be fixed server side (or would be nice if it were configurable via cc_config but that doesnt look to be the case either).

stopping and starting the client is a recipe for instant errors, and where successful, this process will need to be repeated for every time you download new tasks. not really a viable option unless you want to babysit the system all day.

Opt out of the Beta test programme if you don't want to encounter those problems.

But as it happens, I haven't had a single over-run since they cancelled the one I highlighted in the post before yours.

Opt out of the Beta test programme if you don't want to encounter those problems.

But as it happens, I haven't had a single over-run since they cancelled the one I highlighted in the post before yours.

I see some new Python tasks have gone out. however they seem to be erroring for everyone.

https://www.gpugrid.net/results.php?userid=552015&offset=0&show_names=0&state=0&appid=31

seems to always error with this "os" not defined error. GPU load 0%

Environment
Traceback (most recent call last):
File "run.py", line 5, in <module>
for key, value in os.environ.items():
NameError: name 'os' is not defined

now seeing this:

==> WARNING: A newer version of conda exists. <==
current version: 4.8.3
latest version: 4.10.1

Please update conda by running

$ conda update -n base -c defaults conda


10:07:30 (341141): /usr/bin/flock exited; CPU time 42.091445
application ./gpugridpy/bin/python missing

09:57:32 (340085): wrapper (7.7.26016): starting
[input.zip]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of input.zip or
input.zip.zip, and cannot find input.zip.ZIP, period.
boinc_unzip() error: 9

just had my first two successful completions. doesn't look like it ran any GPU work though, the GPU was never loaded. just unpacked the WU, ran the setup. then exited. marked as complete with no error. only ran for about 45 seconds.

https://www.gpugrid.net/result.php?resultid=32570561
____________

just had my first two successful completions. doesn't look like it ran any GPU work though, the GPU was never loaded. just unpacked the WU, ran the setup. then exited. marked as complete with no error. only ran for about 45 seconds.

https://www.gpugrid.net/result.php?resultid=32570561

just had my first two successful completions. doesn't look like it ran any GPU work though, the GPU was never loaded. just unpacked the WU, ran the setup. then exited. marked as complete with no error. only ran for about 45 seconds.

https://www.gpugrid.net/result.php?resultid=32570561

Did you have to up-date conda for the two successful tasks? I received a few new WUs but all errored. I will not have access to this computer until tomorrow.

All of these Python WU's seem to fail. A pair of examples with different problems:

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

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

some succeed. but very few. out of the 94 python tasks i've received recently. only 4 of them succeeded.
____________

i see some new tasks going out.

still broken.

https://www.gpugrid.net/result.php?resultid=32584011

11:06:39 (1387708): /usr/bin/flock exited; CPU time 281.233647
11:06:39 (1387708): wrapper: running ./gpugridpy/bin/python (run.py)
WARNING: ray 1.3.0 does not provide the extra 'debug'
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
tensorflow 2.4.1 requires flatbuffers~=1.12.0, but you have flatbuffers 20210226132247 which is incompatible.
tensorflow 2.4.1 requires gast==0.3.3, but you have gast 0.4.0 which is incompatible.
tensorflow 2.4.1 requires grpcio~=1.32.0, but you have grpcio 1.36.1 which is incompatible.
tensorflow 2.4.1 requires opt-einsum~=3.3.0, but you have opt-einsum 3.1.0 which is incompatible.
/home/icrum/BOINC/slots/41/gpugridpy/lib/python3.7/site-packages/ray/autoscaler/_private/cli_logger.py:61: FutureWarning: Not all Ray CLI dependencies were found. In Ray 1.4+, the Ray CLI, autoscaler, and dashboard will only be usable via `pip install 'ray[default]'`. Please update your install command.
"update your install command.", FutureWarning)
Traceback (most recent call last):
File "run.py", line 296, in <module>
main()
File "run.py", line 35, in main
args = get_args()
File "run.py", line 283, in get_args
config_file = open(config_path, 'rt', encoding='utf8')
FileNotFoundError: [Errno 2] No such file or directory: '/home/icrum/BOINC/slots/41/data/conf.yaml'
11:07:04 (1387708): ./gpugridpy/bin/python exited; CPU time 20.831556
11:07:04 (1387708): app exit status: 0x1
11:07:04 (1387708): called boinc_finish(195)

some succeed. but very few. out of the 94 python tasks i've received recently. only 4 of them succeeded.

204 failed with 5 succeded.

Got one that was running for a while but got runtimerror

PyTorch uses SIGARLM internally, which seems to conflict with libboinc API's usage of SIGALRM.

Most off task for Anaconda Python 3 worked well today. Some changes have been made.

e1a1-ABOU_testzip13-0-1-RND2694_0 an higher appears to be good.

It seems that these Python tasks are being used to train some kind of AI/Machine Learning model.

can any of the admins or researchers comment on this? I'd like to know more about the work being done.
____________

Most off task for Anaconda Python 3 worked well today. Some changes have been made.

e1a1-ABOU_testzip13-0-1-RND2694_0 an higher appears to be good.

Looks like he only let one acemd3 task slip through to an Ampere card.

I don't think the Python tasks care much about the gpu architecture.

If the tasks are formatted correctly they appear to run fine on Ampere cards.

Looks like he only let one acemd3 task slip through to an Ampere card.

I don't think the Python tasks care much about the gpu architecture.

If the tasks are formatted correctly they appear to run fine on Ampere cards.

I see a bunch of Python tasks went out again.

I allowed my hosts to pick up one. I don't have high hopes for it though. it's a _6 already and constant errors from all the hosts before. so I'm expecting it'll fail as well.

anyone have a successful run?

Maybe an admin comment on why they keep sending out tasks that mostly fail and never seem to use the GPU?

-edit-
I was right, the Python task failed right around 2mins, never ran anything on the GPU. It's like they aren't even bothering to test that these tasks will fail before sending them out.
____________

All junk for me. None have completed. Pretty sure some have before for me. All around 525-530 seconds. Nice ETA of 646 days so BOINC freaks out.

CPU usage reported in BOINCTasks goes up to 4 threads worth before leveling off a bit. BOINC only reports CPU time = run time even though that doesn't match what I see. Run time is half of what is reported

A have 3 of these valid over the past couple days. None of them used the GPU. Did they complete any work?
https://www.gpugrid.net/result.php?resultid=32619357

This one worked for me after that same PC failed earlier in the week
https://www.gpugrid.net/result.php?resultid=32619337

A have 3 of these valid over the past couple days. None of them used the GPU. Did they complete any work?
https://www.gpugrid.net/result.php?resultid=32619357

Would be cool to hear what they are actually trying to accomplish with these tasks.

Would be cool to hear what they are actually trying to accomplish with these tasks.

I guess you will never hear any details from them.
As we know, the GPUGRID people are very taciturn on everything.

Thank you for this pearl!
Nice to know that everything is going on...

For the time being we are perfecting the WU machinery so to support ML packages + CUDA. All tasks are linux beta for now. Thanks!

I would like to know whether we are supposed to do the things requested in the output file. Things like updating the various packages that are called out.

Or are we supposed to do nothing and let the app/task packagers sort it out before generation?

I would like to know whether we are supposed to do the things requested in the output file. Things like updating the various packages that are called out.

Or are we supposed to do nothing and let the app/task packagers sort it out before generation?

I wonder if I should add the project to my Nvidia Nano. It has Tensorflow installed by default in the distro.

But I wonder if the app would even run on the Maxwell card even though it is mainly a cpu application for the time being and never touches the gpu it seems.

I wonder if I should add the project to my Nvidia Nano. It has Tensorflow installed by default in the distro.

But I wonder if the app would even run on the Maxwell card even though it is mainly a cpu application for the time being and never touches the gpu it seems.

Ah, yes . . . . forgot about that small matter . . . .

I would like to know whether we are supposed to do the things requested in the output file. Things like updating the various packages that are called out.

Or are we supposed to do nothing and let the app/task packagers sort it out before generation?

I'm relatively sure these tasks are sandboxed. the packages being referenced are part of the whole WU (tensorflow). they are installed by the extraction phase in the beginning of the WU. if you check your system you will find that you do not have tensorflow installed most likely.

the package updates need to happen on the project side before distribution to us.

emerge -v1p tensorflow

These are the packages that would be merged, in order:

Calculating dependencies .....

!!! Problem resolving dependencies for sci-libs/tensorflow
... done!

!!! The ebuild selected to satisfy "tensorflow" has unmet requirements.
- sci-libs/tensorflow-2.4.0::gentoo USE="cuda python -mpi -xla" ABI_X86="(64)" CPU_FLAGS_X86="avx avx2 fma3 sse sse2 sse3 sse4_1 sse4_2 -fma4" PYTHON_TARGETS="-python3_8"

The following REQUIRED_USE flag constraints are unsatisfied:
python? ( python_targets_python3_8 )

My Ubuntu 20.04.2 LTS distro has Python 3.8.5 installed so should satisfy the tensorflow requirements.

I'm curious enough to experiment and install tensorflow to see if the tasks will actually do something other than unpack the packages.

I was trying to catch some ACEMD tasks to test the oversized upload file report, but got a block of Pythons instead.

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

Can anyone advise on the multitude of gcc failures, starting with

Richard, I haven't had any GCC errors with any of the Python tasks on my hosts.

Never see it invoked.

Just see lots of unpacking and attempts to run other ML programs.

Interestingly, the task that failed to run gcc was re-issued to a computer on ServicEnginIC's account - and ran successfully. That gives me a completely different stderr_txt file to compare with mine. I'll make a permanent copy of both for reference, and try to work out what went wrong.

Interestingly, the task that failed to run gcc was re-issued to a computer on ServicEnginIC's account - and ran successfully. That gives me a completely different stderr_txt file to compare with mine. I'll make a permanent copy of both for reference, and try to work out what went wrong.

Thanks for the kind words. Yes, that's necessary, but not sufficient. My host 132158 got a block of four tasks when I re-enabled work fetch this morning.

The first task I ran - ID _621 - got

I was trying to catch some ACEMD tasks to test the oversized upload file report, but got a block of Pythons instead.

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

Can anyone advise on the multitude of gcc failures, starting with

gcc: fatal error: cannot execute &#226;&#128;&#152;cc1plus&#226;&#128;&#153;: execvp: No such file or directory
compilation terminated.

Machine is Linux Mint 20.1, freshly updated today (including BOINC v7.16.17, which is an auto-build test for the Mac release last week - not relevant here, but useful to keep an eye on to make sure they haven't broken anything else).

I have a couple of spare tasks suspended - I'll look through the actual runtime packaging to see what they're trying to achieve.

Finally got time to google my gcc error. Simples: turns out the app requires g++, and it's not installed by default on Ubuntu - and, one assumes, derivatives like mine.

All it needed was

Finally got time to google my gcc error. Simples: turns out the app requires g++, and it's not installed by default on Ubuntu - and, one assumes, derivatives like mine.

Finally got time to google my gcc error. Simples: turns out the app requires g++, and it's not installed by default on Ubuntu - and, one assumes, derivatives like mine.

All it needed was

sudo apt-get install g++

No restart needed, of either BOINC or Linux, and task 32623619 completed successfully.

No much sign of any checkpointing: one update at 10%, then nothing until the end.

This was a fairly recent (February 2021) clean installation of Linux Mint 20.1 'Ulyssa' - I decided to throw away my initial fumblings with Mint 19.1, and start afresh. So, let this be a warning: not every distro is as complete as you might expect.

Anyway, the solution is in public now, in case anyone else needs it.

errors on the Python tasks again.

https://www.gpugrid.net/result.php?resultid=32626713
____________

errors on the Python tasks again.

UnsatisfiableError: The following specifications were found to be incompatible with each other:

I'm now using my GPU preferably for tasks related to medical research. Could you mention whether the Python tasks are related to medical research and whether they use the GPU?