Hello everyone!
So... I did some tests concerning task runtime some time ago, because I noticed that people running on Linux were crunching several times faster that people on Windows in some instances.
Some other users are also aware of this and wrote about it here: https://universeathome.pl/universe/forum_thread.php?id=526
Here are the results and my current optimized setup:

Host:
- CPU: AMD Ryzen 7 1700 @ 3.6 GHz
- OS: Windows 10 1909
- Memory: 32 GB DDR4 @ 3200 MHz Cl14

Task series: Universe BHspin v2 0.19 (universe_bh2_190723_310_... and universe_bh2_190723_311_...)

Because the task runtime varies quite a bit over the task series, I will give "typical" runtimes here, in hours:minutes (hh:mm) with a variation timespan where about 95% of the tasks would finish:

Test 1: BOINC on host (Windows 10 1909):
typical: 02:15 variation: 01:40 - 02:30 best case: 01:40 worst case: 04:10

Test 2: Linux Mint on Oracle VirtualBox (short test):
typical: ?? some finished after 01:00, most after 03:55, no in-between, worst case: 04:00

Test 3: Ubuntu 20.04 on Oracle VirtualBox (short test):
typical: 00:55 variation: 00:40 - 01:15 worst case: 01:40

Test 4: Ubuntu 20.04 on Microsoft Hyper-V, included in Windows 10 Pro:
typical: 00:55 variation: 00:40 - 01:15 best case: 00:30 worst case: 01:40

Test 5: Old Intel Core i5 750@3.2GHz, 8GB DDR3 @ 1600MHz, Host OS: Win10 2004, VM: Ubuntu 20.04 on Hyper-V:
typical: 01:20 variation: 00:55 - 01:40

To summarize:
- On Windows 10, run BOINC on Ubuntu 20.04 in a Hyper-V virtual machine!
- Not garanteed but should do the same: Run BOINC on Ubuntu in general!

Notes:
- I did not test Ubuntu running as host OS, but it should give similar results.
- BOINC was seached and installed with the integrated "Ubuntu Software" app manager
- Hyper-V can be enabled on every Windows 10 Pro with a few clicks, but may cause a few percent overall performance hit (Google "Type 1 Hypervisor")
- You may have to enable hardware virtualization (Intel VT / AMD-V), Task-Manager shows "Virtualization: enabled" in the CPU tab
- Hyper-V behaves much more nicely than VirtualBox on Windows 10:
--> With VirtualBox the host begins to lag excessively if you use 80% or more available CPU-threads for the VM to the point of unresponsiveness of even the mouse pointer.
--> Hyper-V is not noticable even when using the host for everything else, except in certain gaming situations, where fps drops can occur.
--> I have assigned 14 of 16 CPU threads to Hyper-V, with Folding@Home using one of the 2 remaining threads during the day, without noticable slowdowns.
- Linux Mint left a bad taste...sorry
- If you want to change the Ubuntu screen resolution when booting in Hyper-V, you have to do this: https://metinsaylan.com/8991/how-to-change-screen-resolution-on-ubuntu-18-04-in-hyper-v/
- The Ryzen 7 1700 machine running 24/7 hovers around 460,000 points per day
- The Core i5 750 machine running daily from 08:00 till 18:00 with 3 of 4 threads assigned to Hyper-V hovers around 33,000 ppd
- With those 2 machines alone, I'm at rank 25 by RAC here...

When I see Xeons and other high-end hardware taking 6,000 - 15,000 seconds for a task, instead of 2,000 - 3,000 I'm getting a bit sad thinking about the wasted ressources.
I hope this helps.

See my latest post on the previous thread you mentioned.

---

A proud member of the OFA (Old Farts Association)

When I switched over to Ubuntu (16.04) several years ago, it was mainly because of Universe.
I thought it was the only practical way to do it.

It seems Ubuntu 20.04 specifically is needed to get the big performance increase, see https://universeathome.pl/universe/forum_thread.php?id=526&postid=4446 (Post 4446 from Keith Myers).
I also had a quick look into your task runtimes, which are around 5500 - 6500 sec at the moment on your Ryzen 2700, in comparison to around 2300 sec on my Ryzen 1700.
So upgrading to Ubuntu 20.04 should at least double your BHspin task speed.

@Jim1348, those times are equivalent to what I was getting on my Threadripper 2920X when I was still on Ubuntu 18.04.05 with the HWE kernel 5.4.0-42 like you are. Even though the kernels are exactly the same, the Ubuntu 20.04.1 install cut the times in half.
Don't know the reason, only guessing might be the difference in the GNOME versions.

---

A proud member of the OFA (Old Farts Association)

So upgrading to Ubuntu 20.04 should at least double your BHspin task speed.

Thanks to both you and Keith. I usually find the newer Ubuntu versions to add problems the old ones didn't have, so avoid upgrading.
But this will be worth it. I always have a machine on Universe.

Tom M., Ian&Steve C., George and Freewill, all team members, saw the same exact improvement moving off Ubuntu 18 to 20.

---

A proud member of the OFA (Old Farts Association)

On my Ryzen 2700, BHspin v2 went from 1 hour 45 minutes on Ubuntu 18.04 to 57 minutes on Ubuntu 20.04.
I didn't think gains like that were possible. I wonder about my other projects?

The upgrade process has the usual pains. Be prepared for a siege if you have an Nvidia card. The login does not work. I have seen it all before. They just mix up the solutions differently so you have to spend time undoing the ones that don't work to use the ones that do work. Lots of luck.

If you do a little prep work before rebooting, you can avoid all the issues. Install the 3rd party drivers during the installation. That installs the Nvidia drivers.
To prevent any login issues, before rebooting for the first time after the install finishes and it asks you if you would like to reboot, stop and edit the /etc/grub file and remove the 'quiet splash' from the kernel command line. And sudo grub-update the grub.cfg file. Then go ahead and reboot and you won't have any issues.

---

A proud member of the OFA (Old Farts Association)

If you do a little prep work before rebooting, you can avoid all the issues.

Yes, that will probably fix it. I ended up editing that file after the fact, after trying a few other things, a bit of the hard way. I will get it better on my other machines. I am more annoyed that Ubuntu has not figured it out. Thanks for your help.

On my Ryzen 2700, BHspin v2 went from 1 hour 45 minutes on Ubuntu 18.04 to 57 minutes on Ubuntu 20.04.
I didn't think gains like that were possible. I wonder about my other projects?

The upgrade process has the usual pains. Be prepared for a siege if you have an Nvidia card. The login does not work. I have seen it all before. They just mix up the solutions differently so you have to spend time undoing the ones that don't work to use the ones that do work. Lots of luck.

I know I'm very late in replying.
It was a pain here too. Now my nvidia cards are bundled into a Windows machine running folding at home exclusively so I do not have to deal with that.
I need to figure out how to run Linux and Windows on the same machine. Dual booting has always made me leery - especially with uefi, and this is my main machine, where I spend a fair bit of time on Windows, especially while working. I may try it on my laptop - Thinkpad x1 extreme - although that has an Nvidia GPU so could pose issues.
I may give this Hyper-v a try on this 1800x, though.

I may give this Hyper-v a try on this 1800x, though.

That is what I would do, if I needed another Linux machine. But I have several Ubuntu 20.04 machines now, so I need to keep one on Windows.
By the way, I just installed Ubuntu 20.04.2 onto a new Ryzen 3600 build with no particular problems. I loaded it in from a flash drive.
So they have fixed the issues with not detecting Nvidia cards. At least I had no problem with a GTX 750 Ti.

In fact, they have drivers for AMD cards, but they are only useful for desktop work. Their OpenCl drivers, which you need for crunching, don't work with Ubuntu 20.04.2, though they did with 20.04.1.
It is always two steps forward, one step back with Linux, unless it is the other way around.

Good luck.

I was always leery of dual-booting too. Seems both Windows and Linux don't know how to NOT step on each others boot sectors and ruin everything.
That is why my standard method to install Linux is to add another hard drive or SSD and use that for the sole installation of Linux.
That way both Windows and Linux have their own drives and you simply choose which one to boot from the BIOS Boot Override menus during POST.

---

A proud member of the OFA (Old Farts Association)

I may give this Hyper-v a try on this 1800x, though.

That's my recommendation.
There are some tweaks i did:
I set the virtual RAM size to fixed, since boinc thought there wasn't enough, because it didn't handle dynamic ram size.
Manually creating the vhdx volume with 30 GB size so Ubuntu doesn't run out of disk space in the future.
Setting some special grub boot parameters in Ubuntu to set the screen resolution, else it is smaller and unchangable.

I've been running Rosetta and Universe inside Hyper-V while also Folding in Windows (when I'm away), worked perfectly!
Only when gaming I sometimes need to hit the Hyper-V pause button to get more fps.

I've finally gotten around to doing this myself, and I can confirm the speed improvement. I installed the Ubuntu 20 flavour of WSL2, and then installed boinc with sudo apt install boinc. I have also installed VcXsrv, but getting that to work with WSL2 requires jumping through a few hoops, and there's no need for boinc purposes; from the command line interface you can either use boinccmd, or you can install and use boinctui. However, if you do run VcXsrv, you can run the boincmgr GUI and everything integrates very nicely into Windows; there's no need to have a Linux desktop on top of the Windows desktop, and if you follow the steps below, no need to have open terminal windows cluttering your workspace.

Now to get boinc running you can just type boinc& into the WSL terminal followed by your chosen boinc manager, but if you close the terminal window, boinc will terminate (very possibly ungracefully). However, the underlying Linux machine continues to run, so if you want to close the terminal window but leave boinc running, type instead nohup boinc &. Similarly you can use nohup to run boincmgr without it being tied to a terminal window. I don't know if the WSL boinc client closes gracefully when the Windows PC closes down, but you can do so manually by typing boinccmd --quit into the WSL terminal.

The Linux functionality I've described is of course well known and documented, but the part that was new to me is how WSL functions, namely as a Linux machine running continuously in the background with the WSL user interface simply a terminal on to that.

Are there any other projects that benefit in the same way from this speed improvement?

I've found that einstein@home is about 4.5 times faster on ubuntu than win10. (That's for a gpu task, I'm not sure if they have cpu only tasks)

I'm not sure if they have cpu only tasks)

Sure they do. For both Gamma Ray and Gravity Wave. Check the Applications page.
https://einsteinathome.org/apps.php

---

A proud member of the OFA (Old Farts Association)

I've found that einstein@home is about 4.5 times faster on ubuntu than win10. (That's for a gpu task, I'm not sure if they have cpu only tasks)

people don't usually report this kind of speed difference between Windows/Linux on Einstein. some of the fastest systems on the project still run Windows. That just wouldnt be the case if Linux was more than 4x faster.

What GPU do you have and which GPU tasks/application were you running? very slow processing time like this usually means something is overcommited, either CPU or GPU memory.

I did run one Einstein task, and there didn't seem to be much difference in speed compared with running directly under Windows. Moreover, if I can't run GPU tasks in WSL2, overall less work will get done unless I run Einstein both natively and in WSL2. But thanks for the suggestion.

It turns out it's not a great idea to run boinc in your home directory, because boinc makes that the home directory for its data. Since boinc creates the directory ~/.BOINC, running it there seems as good a place as any. I've not been able to get boinc to run as a service in WSL2, but I have changed how I run it. To avoid an ever expanding nohup.out file, I now use nohup boinc &>/dev/null &.

However, a somewhat bigger problem than nohup.out is the file ~/.BOINC/stderrgui.txt. This is generated by boincmgr. Despite boincmgr appearing to work just fine, it keeps adding the following line to stderrgui.txt:

(boincmgr:923): Gtk-CRITICAL **: 23:29:23.739: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

After several hours of running boincmgr, stderrgui.txt filled almost all the available space on my SSD, and then the file started being supplemented with disk error reports. The PC rapidly became too slow to be usable and I resorted to an IEC 60320 C13 shutdown. The file had in fact grown to a whopping 32GB (no, that's not a typo). Obviously I deleted it, but to recover my real disk space I compacted the virtual disk using the instructions here:

https://stephenreescarter.net/how-to-shrink-a-wsl2-virtual-disk/

So for the moment at least, I'll stick to boinctui. If switching from boincmgr to boinctui, note that it's necessary to shut down boinc completely and delete the content of gui_rpc_auth.cfg (it's a password, so make a copy of it, just in case you need it again).

To avoid an ever expanding nohup.out file, I now use nohup boinc &>/dev/null &.
[...]Despite boincmgr appearing to work just fine, it keeps adding the following line to stderrgui.txt

In Linux there are two outputs: standard output (#1, stdout) and standard error (#2, stderr)
https://en.wikipedia.org/wiki/Standard_streams


What you achieved is a redirection of the standard output to /dev/null, but the standard error is not, which keeps getting written to the default nohup error log.
To fix this you can use this instead:

foo >/dev/null 2>&1             # produces no output

http://mywiki.wooledge.org/BashFAQ/055
https://en.wikipedia.org/wiki/Redirection_(computing)

But is it possible for you to use something like tmux or screen to keep a terminal of the process accessible when needed, while it keeps running in the background?
I use tmux exessively on my rapsberries:
"tmux" to start and connect if it isnt already running and "tmux attach" to connect to an already running session. It has tabs and panes for showing and switching between different terminals, it's the best!
Inside tmux, Ctrl + b activates the hotkeys, then with "d" to disconnect, "c" to create a new tab/terminal, "x" to close a tab and the number keys to switch between them.

To control it externally, e.g. for an autostart script, here is a snippet from mine:

path1=$(dirname "$(readlink -f "$0")")
s="python3 '${path1}/"

tmux kill-session -t tm_logger
tmux new-session -d -s tm_logger "${s}SmartMeter Logger 1.3.1.py'"
tmux split-window -v -t tm_logger "${s}SolarWR Logger 1.4.py'"
tmux split-window -h -t tm_logger "${s}SolarWR_Logfile_Downloader.py'"
tmux new-window -t tm_logger "${s}subprocess_timer.py'"
tmux new-window -t tm_logger "${s}gpio_switch_test.py'"
tmux new-window -t tm_logger "${s}gpio_switch_gasalarm.py'"

tmux new-session -d -s tm_db "cd '/home/pi/data/History/';java -jar database.jar" #openjre