[Question] FAHClient automated (and testing) install

[MichaIng]

Hey there,

we worked on the DietPi Debian based distro to include Folding@Home with our software offer.

DietPi aims to offer automated and well pre-configured software, so that the necessary manual config steps for end users are minimal. In this case we pre-configure the official .deb package via debconf-set-selections to e.g. add a default (anonymous) user name, our DietPi team and implement the service in a way, that by default the web UI can be accessed remotely, as most of our users use DietPi for headless servers.

---

All of this is working just fine now. I was just wondering, as during our test installs and the need to enable autostart currently (#1193) on every test install a work unit is received and started to process, which we of course for testing only never finish. I guess the work unit is then reserved for this particular client, thus an unnecessary delay for this research occurs? Is it somehow possible to sign out for a work unit, so another client can directly start working on it? Or is this done automatically when uninstalling the client (guess this would be hard to achieve)?

Not sure if this is a real issue on your/the researchers side, if there are anyway always more opened WUs than clients to work on. But in case it would make sense e.g. to not automatically start with a WU on first start, but leave it to the user to receive the first WU. And second to allow signing out a WU, if for some reasons one can't finish the job. Even better if this could be done automatically, when the client is uninstalled.

€: Just read a bid through the FAQ and found that you chose the deadline/expiration times accordingly to assure research progress. However I guess as unfinished WU always create a certain delay, it should be kept as low as possible and I still think a way to opt out manually from a WU would be beneficial.

---

Next is the default user. We currently use "DietPi" for this. Of course users will mostly directly change this. But as one could create a passkey for this user name and thus break access for all others, it would make sense to create a passkey our end (and preconfigure it) for this default user. But I am not sure if this somehow breaks your intentions with passkeys. I found otherwise default to be "Anonymous" (at least on Windows desktop installs?). Would this be the better choice and is it unallowed to receive a passkey for this user?

[bb30994]

Simulations run by FAH fall decidedly in the "heavy" category -- which is probably why developemnt of an ARM version is pretty much non-existent. FAH has three classes of WorkUnit assignments. 1a) Standard CPU assignments for hardware with SSE2 or above and preferably with SMP threads, 2) GPU assignments to be processed by high-end GPUs with I/O support from a CPU. Then there's 1b) which is a subset of the CPU assignments which are relatively short duration and run in the Chrome browser using NaCl.

Group 1a tend to run for days at a time (depending, of course on hardware capabilities).

Every WU has a deadline and when a WU is not completed by the deadline, it is discarded. If you will not complete a WU by it's deadline, please don't start it, since as you say, the WU is checked out exclusively to you and that would delay the science until the WU expires. (Actually there are two types of deadlines, but I won't go into that.)

If you do download a WU for test purposes and decide its not going to finish, you can use "FAHClient --dump" to un-check it out.

[MichaIng]

which is probably why developemnt of an ARM version is pretty much non-existent

Jep, read some other articles about ARM (RPi) vs x86 computing performance. Does not make much sense, obviously. Although also ARM SBCs become faster and they are used increasingly. As they usually run 24/7, mid- to longterm it can make sense to at least add ARMv8/arm64 support or the properly upcoming ARM version 😉.

FAHClient --dump

Ah nice, I will add this to our uninstall code.

Not sure if it's possible to add such commands to .deb and/or .rpm package (pre-)uninstall steps, or if this is already the case, but it would help to reduce research delays if users for some reason decide to remove the client while usually a work unit is currently assigned.

[bb30994]

The FAH EULA prohibits donors from obtaining FAH software from unauthorized sources and I'm afraid you'd fall into that category. The .deb and .rpm provide all the necessary steps to begin folding. You MAY begin folding as Anonymous for Team 0 or you may choose your own name and team. That option is built into the code provided by FAH. I do recommend that each person make those changes for themselves and add a passkey, but that not essential. It doesn't change the science you complete, only the accounting of the points you can earn.

FAHClient should start automatically after a brief pause.

The FAHClient service is just that, a service that is expected to run continuously doing nothing but managing subordinate threads. If you wish to stop processing, you can suspend the worker threads (FAHCore_xx) by using FAHControl (if you have a GUI) or by telnet commands to the service. These two options are recommended for advanced Donors. For beginners, WebControl is much simpler that FAHControl,

If you do suspend processing, FAHClient will remain idle until you choose to resume processing or you reboot. Even automatic resuming after a reboot can be inhibited if that's your intent.

[MichaIng]

@bb30994

The FAH EULA prohibits donors from obtaining FAH software from unauthorized sources and I'm afraid you'd fall into that category.

We do not offer FAH from a different source, but use the official .deb package: https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-software#L3886-L3911

We just provide a GUI to allow users choose FAH and have an automated install without interactive steps needed, so you can as well install images on multiple machines non-interactively and have FAH installed and running on all of them automatically.

If you wish to stop processing, you can suspend the worker threads

As said, I was just caring about started but not finished WUs. Preventing autostart of work units and allowing to check out from a work unit (FAHClient --dump) just allows to reduce those, when devs or end users test or try out FAH.

[ProDigit]

ARM Currently doesn't make sense, but that doesn't mean they never will.
They are extremely power efficient. The moment ARM will start implementing 32 core CPUs, FAH should start to take notice!

[ronlaws86]

Can I resurrect this one in 2020? :) Big ARM Based server farms run ARM core counts in the 64+ range, Pi4 is a Cortex A72 and can turn out Work units on BOINC at the same rate as FAH does on my laptop, turnaround typically 1 day or less. it's worth re-visiting this with current hardware no?
This thread is worth pointing out for running OpenCL 1.2 against the VideoCore IV (Pi3) - https://github.com/doe300/VC4CL

Pi4 is the next gen VideoCore which has more compute power.

It's also worth pointing out that while one pi alone is the target of many scoffs for its meek power, we're talking about a distributed workload across the globe here, it adds up.

[MichaIng]

@ronlaws86
The initial issue wasn't about ARM support btw, so I suggest to open a new one or better contribute to a related discussion in the forums, e.g. https://foldingforum.org/viewtopic.php?p=320319#p320319