I'm completing a whole work unit per thread per hour on skylake-avx512 with my optimized MilkyWay@Home binary (the normal application, not N-Body). If you use Linux, I can show you how this is done. There are a few tricks you'll need to know; if you're interested in compiling an optimized binary, I can save you the time and effort of figuring it out. Reply or PM if you would like help with this.

How about tackling the gpu separation binary for Linux. I had to drop MW on all my Linux machines because the gpu binary only errors out. I was told the only way to fix it was to run a newer BOINC.

---

Sorry to hear it's not working. I don't see a git clone available for the GPU app, so the only thing I can think of is compiling the current BOINC. I don't know what version of the BOINC libraries the GPU app is compiled against; maybe it's an incompatibility between that and the version you're using. It's worth a try IMO.

Yes, the problem arises on any BOINC version earlier than 7.6.3. Some helpful posts highlighted the known issue. I documented my problem in the New Linux system trashes all tasks thread.

I tried to compile BOINC for the 7.8.3 version but failed. Don't have the skill set or know what I am doing.

---

The current version is 7.11.0. If you would like assistance, tell me the commands you're using to attempt the build and paste the error output.

Hi, I'm currently running a locally compiled M@H in Ubuntu Mate on a Raspberry PI3. It's slow, completing tasks in the 210,000-238,000 second range. Any advise you can give me that will improve performance would be appreciated.

Regards,
DadX

That sounds about right for a Raspberry Pi, I wouldn't expect any better. How does it compare to the stock app (if there is one for ARM)? I can give you detailed instructions for the build if you like. Tell me what steps you followed to compile it and I'll see if anything looks wrong. Sorry for the delay in replying, I only check this once a day anymore because of the lack of activity.

The project does not supply an ARM executable, I used instructions posted a some years ago by Jake and a few others to make the executable. See the thread "Raspberry pi 3 and Milkyway@home".

I used the instructions almost exactly as documented. In almost all cases where apt-get couldn't retrieve something I moved on with the assumption that something else had superseded it or its just different in Ubuntu. The final product works so it seems to have been a valid assumption. I did have to rename the executable because what it created didn't match what they documented as the correct name.

During the build I was looking at the results of each step so I didn't redirect the results to a file. Someday soon I'll recompile it for a PI running stretch (or whatever the current "native" OS is at the time) and see if there is a difference.

Separately I might try moving the installation from the current SD card to a USB hard drive but I doubt that will make a significant difference.

Any advice you can offer would be appreciated.

It sounds like you've done everything right. Like I said, I wouldn't expect better performance than that from a Raspberry Pi, the CPU is very slow, I don't think it's worth investing any time or effort in using that device for this project. If you have an x86_64-based system, I can help you compile for your specific CPU, it involves CFLAGS and CXXFLAGS. Source files need to be edited to get it to build on x86_64, I can tell you exactly what needs to be changed, I guess you probably didn't have that issue with the ARM build. The flags probably don't matter for your build, it's a quite basic processor in comparison to a typical desktop one.