It happens on windows 10 too.

I was blaming my AMD CPU, but my Intels do the same, it's just I don't usually interact with them directly. Somebody somewhere said the CPU has to do quite a lot of work to switch a core between VB and native Windows. But even if I just run some cores on VB and leave loads free for Windows, it's still sluggish.

Are they real cores or hyperthreaded ones?

Are they real cores or hyperthreaded ones?

I have 12 cores, 24 if with HT. Even if I run one 8 core Atlas from LHC, the interface sticks sometimes. It's not evenly slow, it's a 3 second pause every so often. Maybe windows doesn't share the cores around evenly so they get swapped? Someone did tell me that once, not sure if Windows 11 improved.

And beeping in the speakers?

And beeping in the speakers?

I got that a few times.....

Are they real cores or hyperthreaded ones?

OT friendly message:

I see you are in Russia. How are things doing over there? In my opinion the West is punishing the civilians and not the leader. We're also punishing ourselves with these stupid sanctions, everything costs more everywhere.

tacc is empty too.

tacc is leftovers and very rarely has anything.
I tried them and left them after getting about 20 tasks and then a long dry spell.
They are a waste of time for the serious cruncher.

Maybe there isn't enough ram for python gpu?

48 gigs? not enough?
I got a ACEMD 3 and running ATLAS and Prime Grid and only using 32% of my total RAM
I don't think its RAM.

The STDERR goes on about memory leaks in its setup, but this is fresh RAM (well half new and half less new but not ancient)

You could run memtest (I always do for any new/used RAM I obtain), but I think a memory leak is a programming error, not a hardware fault.

I figured as much as well since it is in the starting sequence.
I've never had a memory leak error for real since I have been on BOINC.

But it still doesn't tell me what the 195 (0xc3) EXIT_CHILD_FAILED error is caused by.
Run through this log and see if you can identify what the problem is: https://www.gpugrid.net/result.php?resultid=32886434

Oops, yes Treesize. I can see how useful it might be, but I keep a pretty tight ship at the best of times, so no need for it here.
I'd used Boinctasks before, but prior to installing VirtualBox, and I didn't have the kind of problems that BoincTasks would solve back then, so it just seemed an unnecessary duplication.
Nothing against it - just not enough going for it with my limited uses. Until now.

I have 7 computers, controlling all those individually would be ridiculous. AFAIK you have 4 active machines. That would be enough for me to use Boinctasks.

Yes, 4 in 3 different physical locations.
I'm not so bothered by how any of them run in locations that I'm not in tbh. I got over that a long time ago.
They do what they can until they don't and I'll eventually turn up and sort out any problems

---

Maybe there isn't enough ram for python gpu?

48 gigs? not enough?
I got a ACEMD 3 and running ATLAS and Prime Grid and only using 32% of my total RAM
I don't think its RAM.

The STDERR goes on about memory leaks in its setup, but this is fresh RAM (well half new and half less new but not ancient)

You could run memtest (I always do for any new/used RAM I obtain), but I think a memory leak is a programming error, not a hardware fault.

I figured as much as well since it is in the starting sequence.
I've never had a memory leak error for real since I have been on BOINC.

But it still doesn't tell me what the 195 (0xc3) EXIT_CHILD_FAILED error is caused by.
Run through this log and see if you can identify what the problem is: https://www.gpugrid.net/result.php?resultid=32886434

I was correct, memory leak on Wikipedia: https://en.wikipedia.org/wiki/Memory_leak

The child error you get looks like their screwup too. Not much we can do when no staff here never reply.

This made me laugh: https://forums.virtualbox.org/viewtopic.php?t=102910 - Super hard child purify. Sounds like someone went to boot camp.

Well I found this in your log: "Everything is Ok" - so what are you concerned about? :-)
After that it just detects memory leaks everywhere. This requires a programmer to run through the code and sort something. Nothing we can do here without access to it.

Oops, yes Treesize. I can see how useful it might be, but I keep a pretty tight ship at the best of times, so no need for it here.
I'd used Boinctasks before, but prior to installing VirtualBox, and I didn't have the kind of problems that BoincTasks would solve back then, so it just seemed an unnecessary duplication.
Nothing against it - just not enough going for it with my limited uses. Until now.

I have 7 computers, controlling all those individually would be ridiculous. AFAIK you have 4 active machines. That would be enough for me to use Boinctasks.

Yes, 4 in 3 different physical locations.
I'm not so bothered by how any of them run in locations that I'm not in tbh. I got over that a long time ago.
They do what they can until they don't and I'll eventually turn up and sort out any problems

I think it's possible to control them from Boinctasks if you can access the network they're on. Or you could use an account manager to allow you to change what projects they run on remotely, without needing to access them. I used to have 500 machines running at my work. I installed Boinc on each and added an account manager. Then adjusted everything from home. The only time I ever visited one was when the owner complained the fan was too loud!

Maybe there isn't enough ram for python gpu?

48 gigs? not enough?
I got a ACEMD 3 and running ATLAS and Prime Grid and only using 32% of my total RAM
I don't think its RAM.

The STDERR goes on about memory leaks in its setup, but this is fresh RAM (well half new and half less new but not ancient)

You could run memtest (I always do for any new/used RAM I obtain), but I think a memory leak is a programming error, not a hardware fault.

I figured as much as well since it is in the starting sequence.
I've never had a memory leak error for real since I have been on BOINC.

But it still doesn't tell me what the 195 (0xc3) EXIT_CHILD_FAILED error is caused by.
Run through this log and see if you can identify what the problem is: https://www.gpugrid.net/result.php?resultid=32886434

I was correct, memory leak on Wikipedia: https://en.wikipedia.org/wiki/Memory_leak

The child error you get looks like their screwup too. Not much we can do when no staff here never reply.

This made me laugh: https://forums.virtualbox.org/viewtopic.php?t=102910 - Super hard child purify. Sounds like someone went to boot camp.

Well I found this in your log: "Everything is Ok" - so what are you concerned about? :-)
After that it just detects memory leaks everywhere. This requires a programmer to run through the code and sort something. Nothing we can do here without access to it.

Everything ok in the setup was ok.
It ran for blah blah blah seconds and then blew up.
If child error is their thing well so be it.
It's their new beta python work, so some of us run it fine and others blow it up.
ok...back to RAH. That was GPU.

RAH - F'ing project knocked me off again. But all the tasks are out of my account so no idea what blew up this time. STUPID!

Everything ok in the setup was ok.
It ran for blah blah blah seconds and then blew up.
If child error is their thing well so be it.
It's their new beta python work, so some of us run it fine and others blow it up.
ok...back to RAH. That was GPU.

Do you know if GPUGrid will ever support AMD cards? I doubt I'll ever buy one of those overpriced slow Nvidias. I found people mentioning they were trialling it in 2011 and 2015....

Anyway looks like GPUGrid ran out of work. I've shoved all my PCs on it to see if I ever get anything, seems they have a CPU and an ATI tickbox, not sure if those ever actually produce anything though.

[snip]

Do you know if GPUGrid will ever support AMD cards? I doubt I'll ever buy one of those overpriced slow Nvidias. I found people mentioning they were trialling it in 2011 and 2015....

Anyway looks like GPUGrid ran out of work. I've shoved all my PCs on it to see if I ever get anything, seems they have a CPU and an ATI tickbox, not sure if those ever actually produce anything though.

They tried it for a while, and found that that OpenCL translations would be much slower than running in CUDA. So they dropped the idea of supporting AMD cards, at least until they start writing some new application.

CPU tasks are more likely, but only for new work for which they haven't written CUDA applications. Those are occasionally available these days.

I've thought of a way we might get them to offer more OpenCL work:

First, modify, BOINC so that if it can identify a GPU used in either CUDA or OpenCL, translate it to the identification of the same GPU used in the other of these, and mark that one as reserved also. It should also be able to say that the GPU is not available for the other one.

Next someone should identify all calls to the CUDA library used by the current application, and how much time that application uses in each.

Then, have Khronos develop equivalent calls to the OpenCL library that are especially fast on AMD GPUs.

Finally, give the GPUGRID project enough money to do something that they cannot do with only Nvidia GPUs.

How many of these do you think you can persuade all of the right people to do?

These changes also make it possible to start a task under either CUDA or OpenCL, run part of the task and produce files that are the input for the other part. It can then run the other part under the other GPU language if a translation is available, or just send those files back if there is no translation.

[snip]

Do you know if GPUGrid will ever support AMD cards? I doubt I'll ever buy one of those overpriced slow Nvidias. I found people mentioning they were trialling it in 2011 and 2015....

Anyway looks like GPUGrid ran out of work. I've shoved all my PCs on it to see if I ever get anything, seems they have a CPU and an ATI tickbox, not sure if those ever actually produce anything though.

They tried it for a while, and found that that OpenCL translations would be much slower than running in CUDA. So they dropped the idea of supporting AMD cards, at least until they start writing some new application.

CPU tasks are more likely, but only for new work for which they haven't written CUDA applications. Those are occasionally available these days.

I've thought of a way we might get them to offer more OpenCL work:

First, modify, BOINC so that if it can identify a GPU used in either CUDA or OpenCL, translate it to the identification of the same GPU used in the other of these, and mark that one as reserved also. It should also be able to say that the GPU is not available for the other one.

Next someone should identify all calls to the CUDA library used by the current application, and how much time that application uses in each.

Then, have Khronos develop equivalent calls to the OpenCL library that are especially fast on AMD GPUs.

Finally, give the GPUGRID project enough money to do something that they cannot do with only Nvidia GPUs.

How many of these do you think you can persuade all of the right people to do?

These changes also make it possible to start a task under either CUDA or OpenCL, run part of the task and produce files that are the input for the other part. It can then run the other part under the other GPU language if a translation is available, or just send those files back if there is no translation.

So how come Folding at Home makes code that runs on everything?

Peter, the occasional ACEMD3 task comes out, but other than that its a 0 task project.
They are experimenting with Python for GPU, but that is early Beta still and those types of tasks are far and few between.

Status can be seen here: https://www.gpugrid.net/server_status.php

Peter, the occasional ACEMD3 task comes out, but other than that its a 0 task project.
They are experimenting with Python for GPU, but that is early Beta still and those types of tasks are far and few between.

Status can be seen here: https://www.gpugrid.net/server_status.php

Will Python GPU run on AMD?

Last time I looked at GPUGrid a year or two ago, they had loads of work. Where did it all go?

[snip]

So how come Folding at Home makes code that runs on everything?

Easy enough if that code was written in OpenCL rather than it CUDA.

https://en.wikipedia.org/wiki/List_of_Folding@home_cores

Will Python GPU run on AMD?

Why not?

Last time I looked at GPUGrid a year or two ago, they had loads of work. Where did it all go?

It's many months that project has "dry queues"

---