Has anyone tested the SWAN_SYNC variable verses using an app_config file in the project folder to assign 1 CPU core per task?

I tried swan_sync a few years ago and it made no difference. I just tried it gain, setting both swan_sync and SWAN_SYNC since there is some confusion which to use, and it made no difference in either CPU usage or GPU usage.

When the SWAN_SYNC is in effect, the CPU time is near to the run time. If the CPU usage of the ACEMD app is lower than a full core (or thread), then the SWAN_SYNC is ignored for some environmental reasons.

I am pretty sure SWAN_SYNC was getting to ACEMD. It was in the environment for the acemd process according when I looked in /proc/1879/environ when 1879 was the PID for acemd..

My google foo is failing me but my memory, which is probably worse than my google foo, recalls that Linux ignores SWAN_SYNC and that Linux with or without the ignored SWAN_SYNC was as fast as Windows XP with SWAN_SYNC which was faster than windows XP without SWAN_SYNC which was faster than Windows <anything newer>.

But, don't trust my memory ... I don't.

Re: nanoprobe - see the links in Retvari's post.

Has anyone tested the SWAN_SYNC variable verses using an app_config file in the project folder to assign 1 CPU core per task?

Two completely different purposes.

SWAN_SYNC would make the ACEMD application use extra CPU cycles, whether or not a core was free - it would simply overcommit the CPU and cause a lot of thrashing if the CPU was filled with other tasks.

app_config (or simply reducing the number of cores BOINC is allowed to schedule) would make space available on the CPU, but do nothing at all to encourage ACEMD to use it.

If you normally run your CPUs full to the brim, you should probably use both.