Same thing happened to me, the 8.0.2 upgrade vanished all my e@h tasks - which I believe were only GPU tasks at the time - and then downloaded new ones. The World Community Grid tasks didn't have this problem, but those were CPU only tasks.
Seems to be running well since then. Thanks for your Mac efforts, I love being able to run native BRPS GPU, BRPS CPU and GRPS5 CPU tasks on my little Mac Studio!
Hey George, Keith, Richard, BM, Oliver, and Gary - thank you for looking into this! I did go through my project and compute preferences and got them aligned and set up for multiple. I also downloaded/installed the new version of BOINC. I checked out my cc_config also. I quit the old version of BOINC after completing my current executing tasks so I wouldn’t lose any partial completed task, then started up the new BOINC. It kept my fgrp5 tasks, and flushed the brp4a tasks, then started downloading new brp4a tasks. The new tasks executed 2 at a time (I have my utilization set to 0.50)!
So over the next few days I’ll play with preferences to see what works best with my 2 Macs. Thanks again for all your support!
I spoke too soon, it looks like I've got 212 invalids for Binary Radio Pulsar Search (Arecibo,GBT,A) v2.08 arm64-apple-darwin
I don't know if this is related to Boinc 8.0.2 or not
Looking at my stats, it seems like I’ve had about 200 units that were validated, with no errors or invalids yet. I’m using two M1 Macs with the latest macOS.
A quick peek at a few results shows that my M1 CPU BRPS tasks are marked invalid against opencl BRPS tasks that validate against each other.
The same here with my M3. 427 out of 776 BPRS (Arecibo,GBT,A) results currently marked invalid against (apple_gpu-opencl) results that agree with each other. No apparent problems when validating against other results from the same app, nor so far with BRPS (Arecibo,GBT,long) tasks or with results from my Intel machine.
Hey I had quite a few (15% - 20%) invalid BRP4A tasks on my m1 mini until I updated macOS (on 6/1) to the latest version, which runs the Darwin 23.5.0 kernel. My previous kernel was 23.4.0. I have had only one invalid result after running more than 1000 after the update.
After looking at quite a few public profiles in the community, most macs seem to run the most recent kernel and had very few invalid tasks. Macs than run prior kernels had lots more invalid BRP4A tasks. So it seems to me that mac gpus agree better with one another when they're running the same kernel. I don't know if this is unique with the 23.5.0 kernel, or with mac updates in general.
I created a thread in Crunchers Corner about it, with some observations: https://einsteinathome.org/content/brp4a-and-invalid-results
I am so excited, about reading, that Metal GPUs will going to be supported (or are already supported right now)!!! Great, great, great! Thank you so much! How was it going with Metal Code? Is it easy or complicated, compared to CUDA or OpenCL? I do have only basic knowledge about this. At my Mac Studio M1 max and Mac mini M2 pro GPU is running fine with this App and two work units, within Sonoma 14.5.
Our Metal App is still in early development stage and we don't have much time to work on it right now. It can only be used for our least demanding App, as neither the software (Metal) nor the hardware supports fp64 (double precision). Its use for us at E@H is limited, so priority for development is not very high.
Other than that CUDA and OpenCL are rather similar, these are based on the same concepts. Metal, however, is rather different. I think it's a nice experiment, but not worth to write and maintain a completely different code path just for the few Apple Silicon machines that we have on E@H.
Same thing happened to me,
)
Same thing happened to me, the 8.0.2 upgrade vanished all my e@h tasks - which I believe were only GPU tasks at the time - and then downloaded new ones. The World Community Grid tasks didn't have this problem, but those were CPU only tasks.
Seems to be running well since then. Thanks for your Mac efforts, I love being able to run native BRPS GPU, BRPS CPU and GRPS5 CPU tasks on my little Mac Studio!
Hey George, Keith, Richard,
)
Hey George, Keith, Richard, BM, Oliver, and Gary - thank you for looking into this! I did go through my project and compute preferences and got them aligned and set up for multiple. I also downloaded/installed the new version of BOINC. I checked out my cc_config also. I quit the old version of BOINC after completing my current executing tasks so I wouldn’t lose any partial completed task, then started up the new BOINC. It kept my fgrp5 tasks, and flushed the brp4a tasks, then started downloading new brp4a tasks. The new tasks executed 2 at a time (I have my utilization set to 0.50)!
So over the next few days I’ll play with preferences to see what works best with my 2 Macs. Thanks again for all your support!
Wood wrote: Seems to be
)
I spoke too soon, it looks like I've got 212 invalids for Binary Radio Pulsar Search (Arecibo,GBT,A) v2.08 arm64-apple-darwin
I don't know if this is related to Boinc 8.0.2 or not
Wood wrote: Wood
)
Looking at my stats, it seems like I’ve had about 200 units that were validated, with no errors or invalids yet. I’m using two M1 Macs with the latest macOS.
Quote:Quote: I spoke too
)
A quick peek at a few results shows that my M1 CPU BRPS tasks are marked invalid against opencl BRPS tasks that validate against each other.
Wood wrote:A quick peek at
)
The same here with my M3. 427 out of 776 BPRS (Arecibo,GBT,A) results currently marked invalid against (apple_gpu-opencl) results that agree with each other. No apparent problems when validating against other results from the same app, nor so far with BRPS (Arecibo,GBT,long) tasks or with results from my Intel machine.
NG
Hey I had quite a few (15% -
)
Hey I had quite a few (15% - 20%) invalid BRP4A tasks on my m1 mini until I updated macOS (on 6/1) to the latest version, which runs the Darwin 23.5.0 kernel. My previous kernel was 23.4.0. I have had only one invalid result after running more than 1000 after the update.
After looking at quite a few public profiles in the community, most macs seem to run the most recent kernel and had very few invalid tasks. Macs than run prior kernels had lots more invalid BRP4A tasks. So it seems to me that mac gpus agree better with one another when they're running the same kernel. I don't know if this is unique with the 23.5.0 kernel, or with mac updates in general.
I created a thread in Crunchers Corner about it, with some observations: https://einsteinathome.org/content/brp4a-and-invalid-results
Thanks, this observation
)
Thanks, this observation seems quite helpful!
BM
I am so excited, about
)
I am so excited, about reading, that Metal GPUs will going to be supported (or are already supported right now)!!! Great, great, great! Thank you so much! How was it going with Metal Code? Is it easy or complicated, compared to CUDA or OpenCL? I do have only basic knowledge about this. At my Mac Studio M1 max and Mac mini M2 pro GPU is running fine with this App and two work units, within Sonoma 14.5.
Our Metal App is still in
)
Our Metal App is still in early development stage and we don't have much time to work on it right now. It can only be used for our least demanding App, as neither the software (Metal) nor the hardware supports fp64 (double precision). Its use for us at E@H is limited, so priority for development is not very high.
Other than that CUDA and OpenCL are rather similar, these are based on the same concepts. Metal, however, is rather different. I think it's a nice experiment, but not worth to write and maintain a completely different code path just for the few Apple Silicon machines that we have on E@H.
BM