The main concern with GPUGrid is GPU utilization. SWAN_SYNC is a way to mitigate this with windows but definitely not solve it. From what I've found, using linux under the 9.14 application you will see 90%+ on high end GPUs with an appropriately fast cpu. On windows it is hard to match this, even with these techniques. It almost doesn't matter that SWAN_SYNC isn't on linux because the utilization is so high.

My experience with (or without) Swan_Sync in Windows is the following:
when I newly installed BOINC on one of my PCs recently and ran GPUGRID, I was wondering why in the Windows Task Manager, a CPU utilization by acemd.exe of only a few percent was shown.
I had forgotten the Swan_Sync setting.
After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

That would be a show-stopper for me: I use my CPUs for other purposes. And I grumble at developers who wrote OpenCL apps for NVidia cards, for the same reason.

Not saying that either of us is right or wrong: it's just that different users have different priorities. It might be nice to have a definitive FAQ on Swan_Sync (if there isn't one already), but it should be left up to each user to apply it or not as they choose.

Yup, Swan_Sync on Windows was also something I tried, verified worked, then immediately undid. I like my CPUs keeping as busy as possible doing other projects, rather than "spin-waiting" on GPU kernels to make them only slightly faster.

can we exspect short run tasks to come in the near future?

---

After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

That would be a show-stopper for me: I use my CPUs for other purposes.

Well, on all my PCs (all having a different number of CPU cores) with which I do GPU crunching, I dedicate 1 CPU core to 1 GPU. All other CPU cores are free for other activities.

After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

That would be a show-stopper for me: I use my CPUs for other purposes.

Well, on all my PCs (all having a different number of CPU cores) with which I do GPU crunching, I dedicate 1 CPU core to 1 GPU. All other CPU cores are free for other activities.

Yes. And we're saying that you end up "spending" some CPU cycles, in order to get GPU gains... whereas we are on the opposite end of the spectrum, wanting to use as little CPU as possible to keep the GPU going, so that the CPU (even the unused cycles from the GPU jobs) can be utilized.

The main concern with GPUGrid is GPU utilization.

The main concern of GPUGrid depends on the user's mind, not on GPUGrid.

SWAN_SYNC is a way to mitigate this with windows but definitely not solve it.

GPU utilization without SWAN_SYNC is improved over newer CUDA drivers, but it depends on many other factors like the WDDM (which can't be turned off, that makes SWAN_SYNC less effective on modern Windows OSes) or the workunit itself (some workunits could gain up to 15% performance boost in the past by applying SWAN_SYNC even on Linux, so I assume that it's possible that some future workunits will be similar)

From what I've found, using linux under the 9.14 application you will see 90%+ on high end GPUs with an appropriately fast cpu. On windows it is hard to match this, even with these techniques.

Wrong: I have 96% GPU utilization on Windows XP x64, i7-4770k, GTX 980Ti, PABLO_P01106_0_IDP workunit, 1 CPU task;
98% GPU utilization on Windows XP x64, i3-4360, GTX 980Ti, PABLO_all_data_goal_KIX_CMYB-0 workunit, no CPU tasks

It almost doesn't matter that SWAN_SYNC isn't on linux because the utilization is so high.

It's almost true, because the present workunits do not use that much CPU-GPU interaction. Since we can't turn on SWAN_SYNC under Linux, we can't measure the performance gain, but there could be some, even with the present workunits. The main reason for me to still use Windows XP for crunching is that I want to optimize all resources of my PCs to make the GPUGrid app run as fast as it could, so the lack of SWAN_SYNC under Linux is a show-stopper for me.

I haven't seen much difference(in tasks's execution speed) between using SWAN_SYNC and increasing priority(High:13) of process acemd-918-80.exe.
This approach eliminates the impact of any other programs on the GPU tasks.
IMG_01
I suggest to test the option of changing the priority.
That will free up additional processor core(if you specify CPU < 1.0 for GPU tasks) and would make the system more responsive(on my feeling).
To Automate the increase of priority of GPUGRID tasks use Process Hacker.
Using the shortcut menu we increasing the priority and save configuration.
IMG_02
Since Process Hacker must be running when new task started , it is best to run Process Hacker at system startup(in minimized state).
IMG_03

Sorry to interrupt, I just want to say that I have made a small (10 euros) donation. When I am sure that everything goes well I will make another.

I would like to encourage everyone to do at least a smallest one. You won't even notice this 10 euros, but en masse it could make a big difference for the team.

It's good to see more forum participation from project admins/scientists. Even a "We'll take a look at xx issue" comment here and there gives end users the confidence to keep donating processor cycles.

I still find it odd that a setting like swan_sync needs to be used at all. Other GPU apps do not need it. BOINC or FAH. Typically CPU apps get the Idle priority and GPU apps get Below Normal (1 step higher than idle) which will give CPU priority to GPU apps when both are running. I don't recall what it is set at and I'm not next to one of my PCs.

As long as the exes are different names I separate the GPU exe to it's own CPU core/thread affinity using Process Lasso. That is usually enough in Windows. Linux works well enough to not really need a program like Process Lasso. I would think if it has a higher priority and/or an open thread it would be like a virtual swan_sync setting.

Now that Matt has left GPUGRID, I hope that the team and the new person see the situation differently, and that the crunchers who still use Windows XP for good reason will get a crunching software beyond April 2018.

If we manage to make the switch to Acemd3 it will be based on OpenMM so it will only depend on where OpenMM can run on.

do any of the experts here know whether OpenMM can be run on WindowsXP ?
I was searching for this kind of information, but did not find anything.

I still find it odd that a setting like swan_sync needs to be used at all.

swan_sync isn't needed at all - I run GPUGrid under Windows without using it. But it is available for use, for those members who wish to arrange their processing priority that way.

I also use Process Lasso - there's one particular application, from one other BOINC project, which gains something like a six-fold increase in productivity from being run at real time priority, without having any ill-effects on the general use of the computer (Both GPUGrid and that other application are running on this computer as I type).

So I have nothing against using productivity tweaks where available: but they are choices, rather than requirements.

I still find it odd that a setting like swan_sync needs to be used at all.

It doesn't need to be used. This is merely an option put in the hands of the user, to use it if they want to optimize their system to maximize the performance of GPUGrid (at the expense of a CPU task).

Other GPU apps do not need it. BOINC or FAH.

High GPU usage readings of other GPU apps are usually misleading. You should compare the power consumption of your GPU while running different GPU apps to get a more realistic measurement of the amount of operations done per second. Other GPU apps have lower power consumption while showing higher GPU utilization than GPUGrid.

I think I read somewhere that the utilisation figures for NVidia GPUs are taken from the first shader multiplex (or render output unit, which seems to be the latest terminology): the rest of the card isn't measured or reported.

I hope that the team and the new person see the situation differently, and that the crunchers who still use Windows XP for good reason will get a crunching software beyond April 2018.

Absolutely it does NOT make any sense to crunch with XP in 2017.
2018.....why not 2020 with XP?

do any of the experts here know whether OpenMM can be run on WindowsXP ?
I was searching for this kind of information, but did not find anything.

From OpenMM site:

OpenMM is optimized for the latest generation of compute hardware, including AMD (via OpenCL) and NVIDIA (via CUDA) GPUs. We also heavily optimize for CPUs using intrinsics

Latest hw has very bad support for XP.
Maybe it runs, but with very poor performances

Sounds interesting, I hope you can do it Stefan. I read briefly on OpenMM's site, it suggests a support for AMD, so maybe you will begin support for that? Not that I have any AMD cards myself, but it could open up for a larger userbase, which could give a shorter turnaround time for workunits in the end. A plus for your research I take it.

It's a long story :-(
And today there are a lot of tools to help the opencl development from Cuda
For example: http://gpuopen.com/whats-new-hip-hcc-rocm-1-6/
But if team has no developers....

You cannot install a pascal GPU into an XP machine, and there is no way to hack it like with the 980ti. For the future is 14nm and below, I don't see a point in running these 28nm GPUs for any longer than they have to.

I still find it odd that a setting like swan_sync needs to be used at all.

swan_sync isn't needed at all - I run GPUGrid under Windows without using it. But it is available for use, for those members who wish to arrange their processing priority that way.

I also use Process Lasso - there's one particular application, from one other BOINC project, which gains something like a six-fold increase in productivity from being run at real time priority, without having any ill-effects on the general use of the computer (Both GPUGrid and that other application are running on this computer as I type).

So I have nothing against using productivity tweaks where available: but they are choices, rather than requirements.

Fine I'll word it differently. It shouldn't be needed to fully utilize a GPU. As I mentioned, other projects take what is needed before CPU apps. GPUGrid should be no different.