First of all, it's awesome that there's plenty of work again. I am happily crunching again on my favourite GPU project.

Now, I've noticed two things with the new WUs:

a) Interrupted WUs cannot be continued, I get an instant error. I guess this is nothing new, though.

b) My RTX 2080 can't seem to get maxed out, I'm lucky to make it above 80% (whereas a 1660 Ti and a 1060 3GB in the same system don't have that problem, although the other Turing also usually stays below 90%). I compared some tasks and it seems that it is outperformed by 25% by a 2070 in another host of mine running Linux. I have another 1060 3GB on Linux and it performs very closely to the one on Windows. For the record, SWAN_SYNC is enabled and a full thread reserved for each task.

Any way to fix? Any ideas, comments? Anyone else observe this on their rigs?

EDIT: Maybe move this to the GPU subforum, I dunno.

I run all Linux hosts and the most powerful card I have is a RTX2080.

But all my currently running tasks show over 99% cpu usage and at least 92% gpu usage as shown in nvidia-smi. I have an app_config setting cpu usage to 1 core to support the gpu tasks.

Swan sync is no longer used or even enabled for both Windows and Linux hosts running the acemd3 app. Not a factor.

The speed of the task in Linux is just, because in general, Linux is faster than Windows because of less overhead in the OS.

I know Linux is generally faster, however I don't remember the difference being that stark and core load was always at least around 90% (admittedly my experience is naturally limited to the old app). Also, as I said, the Pascal card seems more or less the same on Windows.

Right now the RTX is literally running at 70% core load. I tried doing two tasks in tandem, but that didn't contribute anything. Can't we do better? :)

a) Interrupted WUs cannot be continued, I get an instant error. I guess this is nothing new, though.

b) My RTX 2080 can't seem to get maxed out, I'm lucky to make it above 80% (whereas a 1660 Ti and a 1060 3GB in the same system don't have that problem, although the other Turing also usually stays below 90%).

For the record, SWAN_SYNC is enabled and a full thread reserved for each task.

It happens if you have different GPUs in the same system, and the task restarts on a different GPU than it was running before.
To avoid this you should suspend the queued GPUGrid tasks first, then the running GPUGrid tasks one by one, and make note which GPU became unused before you suspend the next running task. After restart first you should resume the task which was running on device 0, then the task was running on device 1 and so on, then the unprocessed tasks.

It's usually the result of an overcomitted CPU. Depending on the other (CPU+GPU) tasks running it is advised to reduce the number of simultaneous CPU tasks to the number of CPU cores (50% of CPUs in BOINC manager / Computing settings), or even less. High core count CPUs (AMD Threadripper, Intel i9-9900, AMD Ryzen 9 3950x) can use up their memory bandwidth when many CPU tasks are running simultaneously, even with 4 channel memory. This result in increased runtime of the CPU app, and reduced performance of the GPU app.

Reduced PCIe bandwidth can also be the cause of reduced GPUGrid performance. CPUs with 20 PCIe lanes can't provide PCIe 3.0 x16 for all GPUs in a multi-GPU setup.

The other factor is the atom count of the given simulation - we don't have any info on that with the new GPUGrid app - but I think the present batch has low atom count, and it can cause lower GPU utilization on high-end GPUs.
The third factor is the host OS: Linux tends to be faster (however the previous batch was just as fast on Windows). I see 89% GPU (RTX 2080Ti) usage under Windows 10, while 97-98% GPU (RTX 2080Ti) usage under Linux.

Hm okay then, now I got a WU that's running around 90% on the RTX.

I two have nearly identical systems: same CPU, almost identical motherboard, same GPU. The main hardware difference is RAM. One is Windows 8 and the other Linux, and the Linux box has the lesser quality RAM. GPU load under Linux is ~90% or higher, under Windows it's ~50-60% depending. I can get it marginally higher if I completely stop CPU work, but that's not a reasonable trade-off in my opinion. The Windows app just seems to be much less efficient, whatever the reason. This has been the case since the ACEMD3 release.
____________
Team USA forum | Team USA page
Join us and #crunchforcures. We are now also folding:join team ID 236370!

GPU load under Linux is ~90% or higher, under Windows it's ~50-60% depending.

GPU load under Linux is ~90% or higher, under Windows it's ~50-60% depending.

This is way too low. How did you get this readout?
In Windows task manager the main display for GPU usage don't show the right value. You should change one of the sub-displays to "CUDA" to get the right one.

I have PCI-E 2.0

a) Interrupted WUs cannot be continued, I get an instant error. I guess this is nothing new, though.

It happens if you have different GPUs in the same system, and the task restarts on a different GPU than it was running before.
To avoid this you should suspend the queued GPUGrid tasks first, then the running GPUGrid tasks one by one, and make note which GPU became unused before you suspend the next running task. After restart first you should resume the task which was running on device 0, then the task was running on device 1 and so on, then the unprocessed tasks.

Can I use it on multi-GPU systems?

In general yes, with one caveat: if you have DIFFERENT types of NVIDIA GPUs in the same PC, suspending a job in one and restarting it in the other will NOT be possible (errors on restart). Consider restricting the client to one GPU type only ("exclude_gpu", see here).