What are the "canon" servers?

[rafaug]

Checking through some FAH server stats, as my CPU slot is not able to connect to folding dot stanford dot edu now (and neither are online ping tools), I found that there appears to be some "inconsistency" on what servers are used by FAH, which seem to be hard-coded in places such as the forum header and the part of the client responsible for asking for WUs.

Some examples I noticed recently:

One older laptop I have folding part-time used to connect to folding.stanford..., and switched without notice to fahwebx.stanford...;

Intermittently, the GPU assignment server has been down for short periods of time;

The old FAH website was hosted at folding.stanford..., along with the old NaCl client and the current "simplified" FAH Online Control. For some months, the new FAH website has been foldingathome.stanford..., but the old one is still active and ranked first in Google Search (the new one doesn't even appear in the first page, here; shouldn't the new one replace the old one, so as to compensate spending/effort in the redesign, as well as provide better UX for new/prospective users?);

Some files, such as GPUs.txt, hard-linked in a much-referenced thread this forum, were at fah-web.stanford..., which seems to have been offline for a while now, precluding downloads needed for GPU configuration;

The server status page on the header has listed a lot of servers as DOWN for long, continuous periods - so, are those out of circulation permanently (and thus, should they be removed?), or have their maintainers not had time/reason to manually reset/configure them?

These "inconsistencies" sometimes prevent clients from downloading certain cores/WUs, accessing some features, and make it harder to figure out what address a wget command should be issued for downloading FAHClient through command-line (e.g., on Linux machines managed through SSH).

So, with all that being said, is there any plan to reduce those inconsistencies, or at least provide/maintain a list of what servers are actually "canon" and active for each purpose?

[bruce]

I don't believe these inconsistencies have prevented the clients from downloading.

The client uses a vert few addresses, including the Assignment Servers (AS) and the location of GPUs. txt. The AS is responsible for finding one of the active Work Servers (WS) which has WUs that can be processed by your system. Once an initial contact is made, your client is redirected -- provided any such WS can be found. If no WS can be found that has a WU that can be processed by your system, you'll get a message saying to assignment can be found. In the event that a new or updated FAHCore is needed to process your assignment, the client builds the URL from the characteristics of the WU and your system.

Other data such as web pages that are expected to be read by you, may be found elsewhere such as on fahweb and most of thse things are properly linked starting from the homepage folding.stanford.edu.

We do know that this forum needs to update the links found in the headers of this page but that wouldn't prevent your client from getting an assignment or prevent you from reading the web pages as long as you start at folding.stanford.edu.

If you're not getting an assignment, please post the applicable portions of the log and we can help you diagnose the problem.

[7im]

snip...

Some files, such as GPUs.txt, hard-linked in a much-referenced thread this forum, were at fah-web.stanford..., which seems to have been offline for a while now, precluding downloads needed for GPU configuration;

snip

Which much referenced thread?

I don't have any problem getting the GPUs.txt file. http://fah.stanford.edu/file-releases/public/GPUs.txt

Referenced in this thread. viewtopic.php?f=83&t=26208

But I agree the server status page needs cleaned up.

But with any other issues, you would need to provide more specific details for us to be able to help troubleshoot the problem. For example, my CPU client is running just fine. But that doesn't help you, as you might be running a different version, even a different operating system. Without those details, we cannot even begin to guess at what the issue might be. But since my CPU client is working, it's unlikely a server problem, more likely a configuration problem. Thanks.

[rafaug]

Thank you all for the responses. My folding is working fine (when the servers are not down, of course). I just had some intermittent connection problems with obtaining WUs, but they have already gone away on their own.

My concerns on the "inconsistency" subject are mostly about pages in "official" FAH sources that have not been updated to reflect all these server changes over the years, and do not have any warnings about that. Of course, most people can easily perform a search, and the resources on the forum seem to be fairly well updated (apart from the header).

However, the FAH Wiki seems to be the only place that has very specific technical information about certain files, such as their formatting, how their names are assigned (e.g. for config-[somedate].xml), and more advanced instructions, and it has a lot of deprecated material that is not marked as deprecated (e.g. bigadv setup instructions, separate SMP client, the entire version 7 being considered as "beta"; an example here: https://fah.stanford.edu/projects/FAHCl ... tUserGuide).

If one runs a search for GPUs.txt on the FAH Wiki, this page is the only result: https://fah.stanford.edu/projects/FAHCl ... tOfGPUsTxt. It links the location of the needed GPU list file as https://fah-web.stanford.edu/file-releases/public. If one attempts to click this link, it results in a restricted page that requires login, and thus does not reflect the behavior of the current "canon" address, which just returns a plain textfile. To give more examples, if a certain FAH Wiki topic about command-line installation told a user to do wget with an URL pointing to a too old version of FAH, or at a server that no longer exists, it might be hard for users to "guess" what the actual URL is. If someone attempts to configure their client based on old SMP instructions, or to obtain bigadv WUs, it would not work, which could undermine their trust in these instructions.

The main point from all that is that old/inactive servers/URLs are listed in several old guides not marked as deprecated, and in pages such as the server status page linked on the forum header. Some changes and redirections are transparent to the user, and that's not a problem at all in terms of usability and WU productivity. However, some hard-coded or deprecated addresses require manual intervention to fix and, sometimes, searches that involve sources that disagree with each other. This is what generates the "inconsistencies" I mentioned, and FAH Wiki is just the clearest example I have seen.

[bruce]

I didn't address the fahwiki in my previous answer.

You're correct about it being dreadfully out-of-date. Whenever the forum header gets updated, I wouldn't be surprised if fahwiki, as a whole, gets deprecated.

Like most wiki projects, the fahwiki was a donor-supported project started by a few volunteers and supported by a few more. A lot of good information was collected. Unfortunately, those folks seem to have vanished. If you'd like to take it on as your project and gather some folks to help you, many of us would be appreciative.

[7im]

That version 7 wiki was used during the development of the V7 client. It is mostly deprecated now, though still contains some good info. You should see the v6 FAH WIKI.

And even the GPUs.txt link is broken, you shouldn't need it. The installer downloads it automatically, assuming you have valid GPU drivers installed.

Always looking for volunteers to help keep the documentation up to date.

[davidcoton]

And even the GPUs.txt link is broken, you shouldn't need it. The installer downloads it automatically, assuming you have valid GPU drivers installed.

Unfortunately the standard 7.4.4 install on Linux can fail to download gpus.txt automatically and manual intervention is necessary.

[7im]

And even the GPUs.txt link is broken, you shouldn't need it. The installer downloads it automatically, assuming you have valid GPU drivers installed.

Unfortunately the standard 7.4.4 install on Linux can fail to download gpus.txt automatically and manual intervention is necessary.

Not if you install the GPU drivers first, and follow the install guide, it does work.

But if you go advanced mode, WGet the files, use other package installers than don't support the startup script in the .deb file, etc, you will have to manually add the file.

One helpful trick, even after going adv mode, add the setting <gpu v='true'/>. This can be accomplished for a single slot by right-clicking the slot for the context menu.