YSK: Don't attempt to mess around with the settings

[FoldingFodder]

I've been wanting to implement some basic features that the FAH client does not have. Eg. Scheduled running. Pause when certain applications are running. etc.

I was going to write my own program to implement the missing features and get it to talk to the FAHclient. Looking at the available arguments for the command line interface, i thought it would be possible. There is no other support/guidance on how to interface with the client.

So I attempted to communicate with the FAH client via the command line.

Doing so in a random directory, creates a new instance of the FAH client. Not desired. So i wondered if the working directory was the same as the FAH client if it would work as expected. It did not. It created a new instance of the FAH client again and it wrote over the config files for the original FAH instance. I also lost the WU my computer had been working on for about 24 hours and only needed a couple of hours to complete. I couldn't restore the original FAH configuration, so i had to do an uninstall and a reinstall; with the latest version of course.

So my advice is, unless you don't mind losing your WUs and having to reinstall the program. Don't mess around with the settings outside of the client - it looks like you should be able to based on the limited info given but it's clearly not designed like that.

[Rel25917]

You can pass settings to the client at startup with the command line. To make changes to a running client you need to use telnet to connect.

[bruce]

You can pass settings to the client at startup with the command line. To make changes to a running client you need to use telnet to connect.

Anything that can be managed from FAHControl can also be managed via the telnet interface. That means you can pause slots or whatever you want to alter.

FAHClient is expected to operate 24x7 as a UNIQUE background service. Do not attempt to start a second daemon.

I find that people tend to understand the background printer service so I generally tend to compare it to that service.

An program that can print can submit jobs to the printer service. Once the output file is generated, it's under the control of the service. Multiple jobs can be dispatched to multiple printers but there's only one printer daemon. The OS provides a GUI interface that allows you to hold jobs, release jobs, cancel jobs, etc.

I can't think of any good reason for you to attempt to start a second daemon. Send it a message telling it to do whatever you want it to do.

[FoldingFodder]

You can pass settings to the client at startup with the command line. To make changes to a running client you need to use telnet to connect.

Anything that can be managed from FAHControl can also be managed via the telnet interface. That means you can pause slots or whatever you want to alter.

In the very limited documentation there is no mention of this, therefore one assumes it's not officially supported.

FAHClient is expected to operate 24x7 as a UNIQUE background service. Do not attempt to start a second daemon.

I think you need to read my topic submission again. Not once did i mention the desire to start a second service.


I've read on the forum a number of times that it's expected a machine runs 24/7 processing WUs. I've read the FAH project struggles to retain active members after sudden booms of participation, i wonder if this is because many participants in these booms are offering computers they actually use and therefore cannot keep up with the tight deadlines of WUs because they actually need to use their equipment. There is no reason for a machine to be on 24/7 to contribute towards the FAH project - the WUs just need to be allocated more thoughtfully and/or the WU's deadlines be more accommodating. Or even, the required minimum spec of machines be more in line with the expectations of the FAH project.

[bruce]

The scientific value of any WU decays, the longer it is in flight (i.e.- not returned.) There's no such thing as a low priority project. As soon as a WU is returned, the next generation in the tragecory is generated and is ready to be assigned.

You are not required to run 24x7 but we do ask that you complete the assigned WU before taking your machine off-line. The FAHClient provides the FINISH function specifically to allow you to complete an assignment, return it, and NOT download a new assignment.

You did mention creating a new instance of the FAH client and I simply said don't do that. You need to communicate directly with the FAHClient daemon that's already running.

We expect that folding can continue while you're using your computer. CPU assignments are specifically designed to use all unused CPU resources. The are processed at a very low priority so that anything you want to do with your computer will interrupt it whenever necessary and then processing will resume while you're waiting to move the mouse or type the next key.

Contention for the GPU is another matter which we can address if that's your issue.

[slowbook]

I've read on the forum a number of times that it's expected a machine runs 24/7 processing WUs. I've read the FAH project struggles to retain active members after sudden booms of participation, i wonder if this is because many participants in these booms are offering computers they actually use and therefore cannot keep up with the tight deadlines of WUs because they actually need to use their equipment. There is no reason for a machine to be on 24/7 to contribute towards the FAH project - the WUs just need to be allocated more thoughtfully and/or the WU's deadlines be more accommodating. Or even, the required minimum spec of machines be more in line with the expectations of the FAH project.

Ran into your issue. I wanted to create shortcuts on my sister's computer so that the multiple users on that computer could start/stop/finish without needing to open up the webpage or advanced control. Didn't work initially. You need the send arguments:

Code: Select all

--send
      Send all finished work units, then exit.

  --send-command <string>
      Send a command to an already running client.

  --send-finish [string]
      Finish a slot or all slots on an already running client.

  --send-pause [string]
      Pause a slot or all slots on an already running client.

  --send-unpause [string]
      Unpause a slot or all slots on an already running client.

Those commands will target the existing daemon and won't create a new daemon. Now the other problem I ran into, especially if you aren't running as a true Windows service, is that on multi-user computers by default the working directories for folding are in the installer's %appdata% (at least on Windows). That's not going with multiple users; once I realized I had multiple instances or failed instances, I reinstalled, specified a non-profile directory, and then made sure all of the accounts could modify that directory. Worked for all of the users at that point.

It's not necessary to run all the time; I don't run my primary laptop overnight and I don't leave it on if I go out to work. You don't need to give all of your background resources to FAH; I only give it one thread. I don't even let the daemon start itself; I always do it manually. And ordinarily there's even more flexibility for slower computers. The main issue is that COVID-19 projects have drastically shortened timeout periods compared to other projects. This is why I stopped using my sister's computer; even running full time, it couldn't meet the timeout periods, and with the number of clients out there, someone else will snap up the work unit and turn it around before expiration.