How to fold on NetBSD

[Hopfgeist]

My Unix system of choice has been NetBSD for a long time, for a variety of reasons, both technical and historical.

NetBSD has a capable Linux emulation layer, and with the right libraries installed, can run the Folding at Home client with some restrictions.

To follow these instructions you should have a basic grasp of:
- how to build and install a custom kernel or how to load kernel modules
- how to install packages from pkgsrc
- how to unpack archives into a file system from the command line
- how execute commands from the command line, and redirect output

I use "$" to represent a shell prompt for an unprivileged user,
I use "#" to represent a shell prompt for the superuser (root).


What works:
- downloading the folding core
- CPU-folding (scheduled to maximum "nice"-ness, as it should be), full SMP support: I personally run it on a machine with 24 CPU threads.
- downloading and uploading work units

So the basic functionality is there. Finished work units are counted and are displayed in the statistics, properly attributed to your user and team ID (provided you have a passkey).

What doesn't work:
- GPU folding (having no supported GPU I cannot definitively say that, but it seems unlikely.)
- Remote control of the client (neither via http nor using the proprietary protocol). This is likely caused by an incomplete or incorrect mapping of a Linux syscall to the equivalent NetBSD syscall.

EDIT: The long-standing problem in NetBSD preventing this from working has now been fixed in the main source tree. As soon as the fix is rolled out for NetBSD releases, it should be possible to control FAHClient on NetBSD with FAHControl running anywhere.


How to install:

- Kernel with Linux emulation
You need a kernel with Linux emulation enabled. On NetBSD-9, which is the current stable release, either build a custom kernel with Linux emulation enabled explicitly or add the appropriate kernel modules to /etc/modules.conf and add "modules=YES" to /etc/rc.conf to have them loaded before entering multi-user operation.

- Install Linux libraries and tools
The easiest way to do this is to install all the SuSE-13 libraries from the meta-pkg. I rarely install binary packages using pkg_add, so I will describe my preferred way for installing them from pkgsrc directly. This will probably have to be done with superuser-privileges:

Code: Select all

# cd /usr/pkgsrc/meta-pkgs/suse131/
# make update

This will populate the /emul/linux filesystem, so make sure there is enough room under that path if you only have a small root (/) partition.
It will install much more (around 1 GB) than is required to run the FAH client, so you may choose to install only select packages from /usr/pkgsrc/emulators/suse131_*, but I cannot tell you exactly which ones are required.


- Install the FAH client
Download the normal Linux client, I found that downloading and unpacking the .deb package was the most straightforward. The client itself is exactly the same for all versions.

create a directory and unpack the client using "ar", which will extract ".deb" packages into its components, which is one data.tar.xz and one control.tar.xz archive:

Code: Select all

$ mkdir fah-install
$ cd fah-install
$ ar x fahclient_7.6.13_amd64.deb

All these steps can be done as a normal user. For the next step you may want to install it directly into /emul/linux , which requires superuser privileges. It may run if you install it into a local directory, but then it may not find the corewrapper, unless you also set appropriate paths. So in my example I will install it globally:

Code: Select all

# cd /emul/linux
# tar zxpf <path to data.tar.xz>

- Test the client to see if it runs.

Next make sure that you are familiar with the FAHClient command-line switches, since using a graphical frontend to control the client is not working on NetBSD. To check that the client works and to see what the options are, try running it (as a normal user!) with the help option:

Code: Select all

$ /emul/linux/usr/bin/FAHClient --help

I have written a small wrapper-script to call the FAHClient with the appropriate parameters (working directory, username, passkey, team-id, smp configuration, etc.). If you don't know how to do that, folding on NetBSD is probably not for you

Please correct me if I got something wrong, or ask if anything is unclear.

Cheers, and happy NetBSD-folding,
HG

[MeeLee]

Buy a GT 730. They're ridiculously slow, but you can usually find them for $25 on ebay.
If you can make the Nvidia drivers, and OpenCL drivers work on that, it's guaranteed that it'll work on bigger GPUs, as GT/GTX 700 series use the same drivers as the RTX GPUs.

[Hopfgeist]

Addendum:

There was a long-standing bug in the parameter mapping for some system calls in the Linux-Emulation layer in NetBSD. Some of those have now been fixed, most notably setting the socket receive timeout. The fix has been commited to the main source tree, but has not (yet) been backported to the main release versions (8.x, 9.1). If you know how to patch kernel files, a short stopgap-fix is available attached to the corresponding bug report:

Code: Select all

--- sys/compat/linux/common/linux_socket.c.orig 2020-11-03 17:27:47.055555944 +0100
+++ sys/compat/linux/common/linux_socket.c      2020-11-03 18:28:20.184244766 +0100
@@ -884,6 +884,10 @@
                return SO_SNDLOWAT;
        case LINUX_SO_RCVLOWAT:
                return SO_RCVLOWAT;
+       case LINUX_SO_RCVTIMEO:
+               return SO_RCVTIMEO;
+       case LINUX_SO_SNDTIMEO:
+               return SO_SNDTIMEO;
        case LINUX_SO_KEEPALIVE:
                return SO_KEEPALIVE;
        case LINUX_SO_OOBINLINE:

This now makes the Linux client fully functional on NetBSD, including remote control via FAHControl.


Some more backstory: up to and including Client 7.6.13, the socket "receive timeout" option was only set for the remote control interface. Starting with Client Version 7.6.20, the same option was also set for the sockets used for downloading and uploading work units, making 7.6.20+ completely unusable on NetBSD. That's when I finally decided that NetBSD needed to be fixed, so I dug around in the appropriate kernel source files, found the problem, and here we are.

You are welcome.

Cheers,
HG.

[PantherX]

That's wonderful! Thanks for helping out the community

[Neil-B]

Some more backstory: up to and including Client 7.6.13, the socket "receive timeout" option was only set for the remote control interface. Starting with Client Version 7.6.20, the same option was also set for the sockets used for downloading and uploading work units, making 7.6.20+ completely unusable on NetBSD. That's when I finally decided that NetBSD needed to be fixed, so I dug around in the appropriate kernel source files, found the problem, and here we are.

Now there is something in this that make me wonder if some of the more recent connection style issues people have been having with win/linux installations of current client link to this ... the short response errors or dropping out uploads/downloads where previously there have been no issues might possibly be linked to this I wonder?

I guess this change may have been to try and resolve the issue with connections hanging that has been around for a bit - maybe unintended consequence is that if set a bit aggressively it is just nerfing slow/spotty connections?

[Hopfgeist]

Now there is something in this that make me wonder if some of the more recent connection style issues people have been having with win/linux installations of current client link to this ... the short response errors or dropping out uploads/downloads where previously there have been no issues might possibly be linked to this I wonder?

I guess this change may have been to try and resolve the issue with connections hanging that has been around for a bit - maybe unintended consequence is that if set a bit aggressively it is just nerfing slow/spotty connections?

Possible. I think it complained that it was trying to set receive timeout to 30 seconds at socket level.

Code: Select all

07:14:56:WARNING:WU00:FS00:Failed to get ID from 'assign1.foldingathome.org:80': Could not set receive timeout to 30: Invalid argument

This was the error message I was receiving, prior to the NetBSD kernel fix, which can indeed be cutting it too close for congested/slow server connections.

Cheers,
HG