Maybe the deadlines of WUs on RPI are too short
Moderators: Site Moderators, FAHC Science Team
Maybe the deadlines of WUs on RPI are too short
Thanks to the new 64 bit Bullseye RPI OS and FAH ARM client, I can dig some potentials of my RPI 3B.
However, the ETA of my first WU is about 6 days, and the deadline is only less than 5 days. I'm curious that how the server distributes WUs for different devices, since some tasks are impossible for some slow devices to meet the deadline. And, as a result, if such problem is not noticed by the owner of these devices, computer would keep consuming energy and their lifespan but contributed nothing. In my opinion, server should has some estimation on the computing power of the devices, and if they are not able to finish on time, then WUs should not be sent.
Anyway, since some efforts are taken to make it possible to fold on RPI, I think it would be nice that more devices are able to participate in folding.
Btw, would there be an update on FAHControl software? It can only be installed on old OS cause the dependency python-gtk2 or python-gnome2 are no longer supported on new OS. And without the GUI I even don't know how to remove a slot to abort the current WU...
However, the ETA of my first WU is about 6 days, and the deadline is only less than 5 days. I'm curious that how the server distributes WUs for different devices, since some tasks are impossible for some slow devices to meet the deadline. And, as a result, if such problem is not noticed by the owner of these devices, computer would keep consuming energy and their lifespan but contributed nothing. In my opinion, server should has some estimation on the computing power of the devices, and if they are not able to finish on time, then WUs should not be sent.
Anyway, since some efforts are taken to make it possible to fold on RPI, I think it would be nice that more devices are able to participate in folding.
Btw, would there be an update on FAHControl software? It can only be installed on old OS cause the dependency python-gtk2 or python-gnome2 are no longer supported on new OS. And without the GUI I even don't know how to remove a slot to abort the current WU...
Re: Maybe the deadlines of WUs on RPI are too short
The raspberry PI 3B are too weak to fold.
I believe the 4's are the minimum you need.
To control a linux machine I'd normally suggest setting up remote control and running the advanced control panel on a windows machine.
I believe the 4's are the minimum you need.
To control a linux machine I'd normally suggest setting up remote control and running the advanced control panel on a windows machine.
Re: Maybe the deadlines of WUs on RPI are too short
Thanks for your reply. Well my idea is just maybe it's better to not send weak devices ant WUs. And how to set up the remote control without FAHClient?
Re: Maybe the deadlines of WUs on RPI are too short
I've been here before so this is basically a copy/paste job.
Don't restart FAHClient from the command line, it doesn't like it, instead reboot the whole computer. This ensures the FAHClient runs under the correct user account with the appropriate permissions (it's not root).
Get the IP address of your linux machine
enter "ip a" into a terminal
this is the readout from my machine, you're looking for adapter "eth0", entry "inet". For me the value returned is 192.168.0.210
Edit your config.xml file
I have found linux installs to be a bit disjointed and can have two copies of the config.xml file, it's pot luck as to which one the install will use.
They are located at:-
1). /etc/fahclient/config.xml
2). /var/lib/fahclient/config.xml
this is a dump of my config.xml file, obviously the passkey and user values are fake but show the correct format for the values.
take your ipaddress 192.168.0.210
cut the last part so it reads 192.168.0
append the following ".0/24" to it so it reads 192.168.0.0/24, this is your subnet
open your config.xml file in an editor(vi/vim/ee/nano)
you're looking to add remote control to the client, you want the following entries
<!-- HTTP Server -->
<allow v='127.0.0.1'/>
<!-- Remote Command Server -->
<command-allow-no-pass v='127.0.0.1'/>
edit the values so they look something like this
<!-- HTTP Server -->
<allow v='127.0.0.1 192.168.0.0/24'/>
<!-- Remote Command Server -->
<command-allow-no-pass v='127.0.0.1 192.168.0.0/24'/>
reboot
Install the client onto your Windows machine
On your windows machine do an expert install of the FAHClient.
Do the following:- select Custom install (Advanced), select Start manually (Expert), untick Start Folding@Home.
There is no standalone advanced control package for Windows so we have to install the full client and disable anything which might automatically start it.
Add clients
Start the advanced control panel, Start -> Folding@home -> FAHControl
Add a client to the clients list, click the ADD button at the bottom left, a window pops up.
Name = the name you're using to refer to that particular client.
Address = for Windows you can just use the name of the machine, for linux you have to use the IP address you noted earlier (further setup is required to use a name on linux).
hopefully that should get you to a place where you can connect to your linux folding machine and then we can investigate any other issues your might have.
Don't restart FAHClient from the command line, it doesn't like it, instead reboot the whole computer. This ensures the FAHClient runs under the correct user account with the appropriate permissions (it's not root).
Get the IP address of your linux machine
enter "ip a" into a terminal
this is the readout from my machine, you're looking for adapter "eth0", entry "inet". For me the value returned is 192.168.0.210
Code: Select all
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:00:f9:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.210/24 brd 192.168.0.255 scope global dynamic eth0
valid_lft 6444sec preferred_lft 6444sec
inet6 fe80::215:5dff:fe00:f900/64 scope link
valid_lft forever preferred_lft forever
I have found linux installs to be a bit disjointed and can have two copies of the config.xml file, it's pot luck as to which one the install will use.
They are located at:-
1). /etc/fahclient/config.xml
2). /var/lib/fahclient/config.xml
this is a dump of my config.xml file, obviously the passkey and user values are fake but show the correct format for the values.
Code: Select all
<config>
<!-- Configuration -->
<config-rotate-max v='0'/>
<!-- HTTP Server -->
<allow v='127.0.0.1 192.168.0.0/24'/>
<!-- Logging -->
<log-rotate-max v='0'/>
<verbosity v='3'/>
<!-- Network -->
<proxy v=':8080'/>
<!-- Remote Command Server -->
<command-allow-no-pass v='127.0.0.1 192.168.0.0/24'/>
<!-- Slot Control -->
<pause-on-battery v='false'/>
<pause-on-start v='true'/>
<power v='full'/>
<!-- User Information -->
<passkey v='1234567890abcdef'/>
<user v='donorname'/>
<!-- Web Server -->
<web-enable v='false'/>
<!-- Folding Slots -->
<slot id='0' type='GPU'/>
<slot id='1' type='GPU'/>
</config>
cut the last part so it reads 192.168.0
append the following ".0/24" to it so it reads 192.168.0.0/24, this is your subnet
open your config.xml file in an editor(vi/vim/ee/nano)
you're looking to add remote control to the client, you want the following entries
<!-- HTTP Server -->
<allow v='127.0.0.1'/>
<!-- Remote Command Server -->
<command-allow-no-pass v='127.0.0.1'/>
edit the values so they look something like this
<!-- HTTP Server -->
<allow v='127.0.0.1 192.168.0.0/24'/>
<!-- Remote Command Server -->
<command-allow-no-pass v='127.0.0.1 192.168.0.0/24'/>
reboot
Install the client onto your Windows machine
On your windows machine do an expert install of the FAHClient.
Do the following:- select Custom install (Advanced), select Start manually (Expert), untick Start Folding@Home.
There is no standalone advanced control package for Windows so we have to install the full client and disable anything which might automatically start it.
Add clients
Start the advanced control panel, Start -> Folding@home -> FAHControl
Add a client to the clients list, click the ADD button at the bottom left, a window pops up.
Name = the name you're using to refer to that particular client.
Address = for Windows you can just use the name of the machine, for linux you have to use the IP address you noted earlier (further setup is required to use a name on linux).
hopefully that should get you to a place where you can connect to your linux folding machine and then we can investigate any other issues your might have.
Re: Maybe the deadlines of WUs on RPI are too short
Sorry, I didn't answer this part of the question sooner, I had just rolled over it. I'll answer to the best of my knowledge.
Graphics cards/GPU
FAH keep the GPU.txt database file updated for the very purpose of identifying the GPU in your system and assigning suitable work, or refusing to send it work if it is no longer suitable. New cards are added and old cards are disabled. There are some cards, regardless of age, are just not capable of meeting the current folding requirements so they are disabled. It's not a foolproof system and occasionally a GPU is assigned work it's not capable of processing.
If you want to open up and look at the file you can find it in one of the following locations:-
Linux - /var/lib/fahclient/GPU.txt
Windows (Client 7.6.21) - C:\ProgramData\FAHClient\GPU.txt
Windows (Client 7.6.13 and older) - C:\Users\<username>\AppsData\Roaming\FAHClient\GPU.txt
note:- ProgramData and AppData are hidden folders so you may need to tweak your folder view settings to see them.
Central processing units/CPU
The aforementioned GPU database does not exist for CPUs.
At present the work units assigned to any particular CPU slot is based upon the number of CPU threads/cores assigned to that slot. There is no system in place to identify the processor performance and/or capabilities of any given CPU slot. The complicating factor being that we can manually change the number of threads/cores we assign to any given CPU slot which can radically change the performance of that slot, this is not something we can do with a GPU slot.
I believe in 2020 there was a push to develop a system which benchmarked new folding slots to determine their performance and capabilities, so they could more closely be matched to suitable work units, but that was put on hold by world events.
FAH has very limited programming resources and they have been focussing them in other areas, like GPUs, the client, folding cores. Deciding when to retire a CPU from folding has been largely left to us, the Donors.
Re: Maybe the deadlines of WUs on RPI are too short
Thanks! That is what exactly I want to ask. Indeed I found FAH is not a common-user-friendly software...aetch wrote: ↑Mon Apr 18, 2022 5:43 pm Central processing units/CPU
The aforementioned GPU database does not exist for CPUs.
At present the work units assigned to any particular CPU slot is based upon the number of CPU threads/cores assigned to that slot. There is no system in place to identify the processor performance and/or capabilities of any given CPU slot. The complicating factor being that we can manually change the number of threads/cores we assign to any given CPU slot which can radically change the performance of that slot, this is not something we can do with a GPU slot.
I believe in 2020 there was a push to develop a system which benchmarked new folding slots to determine their performance and capabilities, so they could more closely be matched to suitable work units, but that was put on hold by world events.
FAH has very limited programming resources and they have been focussing them in other areas, like GPUs, the client, folding cores. Deciding when to retire a CPU from folding has been largely left to us, the Donors.
Since BOINC has a regular benchmark system, which can request a similar workload as use's setting in preference, I was just wondering wether FAH has one as well. (But actually, BOINC can still download some missions impossible to weak devices. )
CPU's performance per core varies largely depending on architecture, clock, etc. For ARM cpus on raspberry pi, they should have a larger performance difference than the variance of many x86 CPUs. As there is ARM FAH software, I guess the weakness of ARM cpus' weakness would be taken into consider by servers when they assign WUs?
Well yesterday I tried to turn the folding power of my RPI 3B to light (2 cores) and get a WU. And I turned folding power to medium (3 cores) after I got the WU, hoping to fold faster, but the CPU usages stayed at 50%. But good news is that even so this WU can be finished just before the expiration by estimation. Then my RPI can still contribute something.
Re: Maybe the deadlines of WUs on RPI are too short
A couple of things to note there:-Bowie Wu wrote: ↑Tue Apr 19, 2022 9:15 pmWell yesterday I tried to turn the folding power of my RPI 3B to light (2 cores) and get a WU. And I turned folding power to medium (3 cores) after I got the WU, hoping to fold faster, but the CPU usages stayed at 50%. But good news is that even so this WU can be finished just before the expiration by estimation. Then my RPI can still contribute something.
1). Thread/core count
Increasing the thread/core count of a slot does not take effect until the next work unit starts, the current work unit will run to completion with the lower thread/core count.
Lowering the thread/core count of a slot takes immediate effect.
2). Triggers
Normally a work unit is assigned to only one folder to process and return. It's only in certain circumstances duplicates are assigned to other/multiple folders. It's a lot like the baton in a relay race, it's handed to one person, they do their bit, then it's handed back so it can be passed to the next person.
Each work unit has two triggers - timeout and expiry, this is set at the project level by the scientist running the project.
Timeout - this is what the researchers deem to be a reasonable time in which to process and return the work you have been assigned, if you trigger this a second copy of your work unit is assigned to another folder. If you are constantly triggering this you are wasting your own resources and delaying every project that comes through you because it relies on someone else doing the work, you were originally assigned, to move the project forward.
Expiry - basically any hope of returning the results of your work unit have been lost, your work unit is dumped and any resources (power) you have expended on it have been wasted.
If you're beating the timeout you're good.
If you're constantly passing timeout then I would withdraw the slot.
Re: Maybe the deadlines of WUs on RPI are too short
Thanks for your information. Previously I thought my slow result might be used for something like verification. Then FAH on RPI is only for RPI4.aetch wrote: ↑Wed Apr 20, 2022 1:30 am 2). Triggers
Normally a work unit is assigned to only one folder to process and return. It's only in certain circumstances duplicates are assigned to other/multiple folders. It's a lot like the baton in a relay race, it's handed to one person, they do their bit, then it's handed back so it can be passed to the next person.
Each work unit has two triggers - timeout and expiry, this is set at the project level by the scientist running the project.
Timeout - this is what the researchers deem to be a reasonable time in which to process and return the work you have been assigned, if you trigger this a second copy of your work unit is assigned to another folder. If you are constantly triggering this you are wasting your own resources and delaying every project that comes through you because it relies on someone else doing the work, you were originally assigned, to move the project forward.
Expiry - basically any hope of returning the results of your work unit have been lost, your work unit is dumped and any resources (power) you have expended on it have been wasted.
If you're beating the timeout you're good.
If you're constantly passing timeout then I would withdraw the slot.
Re: Maybe the deadlines of WUs on RPI are too short
There is a way you can overclock the RPi3B, by a few hundreds of Mhz, making it about as fast as a 4B.
But it might not be very optimal.
Because, the 3B+ overclocked will use more power than a Pi4 for the same work done.
For doing this, you're recommended to get an active cooling solution, if possible a heat sink case with 2 fans, which you can run at 3.3V rather than at full blast at 5V.
But it might not be very optimal.
Because, the 3B+ overclocked will use more power than a Pi4 for the same work done.
For doing this, you're recommended to get an active cooling solution, if possible a heat sink case with 2 fans, which you can run at 3.3V rather than at full blast at 5V.
Re: Maybe the deadlines of WUs on RPI are too short
I guess a RPI 3 cannot reach the RPI 4 performance just by overlocking. Actually my RPI 3 is always running at 1350 MHz. (I slightly overclocked it from 1200 MHZ.) The cortex A72 on RPI 4 makes a big performance difference from cortex A53 on RPI 3. I found some benchmark on the internet saying RPI 4 has 3x~4x times performance than RPI 3 on Linpack. My RPI 3 tried to fold 3 WUs and it seems that for RPI 3 it needs more than 4x performance than itself to meet the timeout of a WU.
So, my conclusion is RPI 3 is not qualified for folding. Maybe the workload of WUs still need to be optimized. And RPI 4 can try.
Re: Maybe the deadlines of WUs on RPI are too short
I see. You are talking about the actual "3B", while I was talking about the more common "3B+" model, which runs stock at 1,4Ghz, and can be overclocked to beyond 1,5Ghz.Bowie Wu wrote: ↑Wed Apr 27, 2022 8:36 pmI guess a RPI 3 cannot reach the RPI 4 performance just by overlocking. Actually my RPI 3 is always running at 1350 MHz. (I slightly overclocked it from 1200 MHZ.) The cortex A72 on RPI 4 makes a big performance difference from cortex A53 on RPI 3. I found some benchmark on the internet saying RPI 4 has 3x~4x times performance than RPI 3 on Linpack. My RPI 3 tried to fold 3 WUs and it seems that for RPI 3 it needs more than 4x performance than itself to meet the timeout of a WU.
So, my conclusion is RPI 3 is not qualified for folding. Maybe the workload of WUs still need to be optimized. And RPI 4 can try.
Re: Maybe the deadlines of WUs on RPI are too short
However, even if a RPI 3B+ could be overclocked to 2 GHz, it cannot surpass RPI 4 @1.5 GHz in performance.MeeLee wrote: ↑Wed Apr 27, 2022 9:01 pmI see. You are talking about the actual "3B", while I was talking about the more common "3B+" model, which runs stock at 1,4Ghz, and can be overclocked to beyond 1,5Ghz.Bowie Wu wrote: ↑Wed Apr 27, 2022 8:36 pmI guess a RPI 3 cannot reach the RPI 4 performance just by overlocking. Actually my RPI 3 is always running at 1350 MHz. (I slightly overclocked it from 1200 MHZ.) The cortex A72 on RPI 4 makes a big performance difference from cortex A53 on RPI 3. I found some benchmark on the internet saying RPI 4 has 3x~4x times performance than RPI 3 on Linpack. My RPI 3 tried to fold 3 WUs and it seems that for RPI 3 it needs more than 4x performance than itself to meet the timeout of a WU.
So, my conclusion is RPI 3 is not qualified for folding. Maybe the workload of WUs still need to be optimized. And RPI 4 can try.
Re: Maybe the deadlines of WUs on RPI are too short
That is to be debated.Bowie Wu wrote: ↑Mon May 02, 2022 5:53 pmHowever, even if a RPI 3B+ could be overclocked to 2 GHz, it cannot surpass RPI 4 @1.5 GHz in performance.MeeLee wrote: ↑Wed Apr 27, 2022 9:01 pmI see. You are talking about the actual "3B", while I was talking about the more common "3B+" model, which runs stock at 1,4Ghz, and can be overclocked to beyond 1,5Ghz.Bowie Wu wrote: ↑Wed Apr 27, 2022 8:36 pm
I guess a RPI 3 cannot reach the RPI 4 performance just by overlocking. Actually my RPI 3 is always running at 1350 MHz. (I slightly overclocked it from 1200 MHZ.) The cortex A72 on RPI 4 makes a big performance difference from cortex A53 on RPI 3. I found some benchmark on the internet saying RPI 4 has 3x~4x times performance than RPI 3 on Linpack. My RPI 3 tried to fold 3 WUs and it seems that for RPI 3 it needs more than 4x performance than itself to meet the timeout of a WU.
So, my conclusion is RPI 3 is not qualified for folding. Maybe the workload of WUs still need to be optimized. And RPI 4 can try.
Especially with the 3B+ at 2Ghz the performance gap between the two should be close to zero.
No way of knowing until there are actual WUs out there for a Cortex A-53 CPU.