| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Community
Forum: Hardware Chat Room
Thread: Raspberry Pi |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 53
|
|
| Author |
|
|
KerSamson
Master Cruncher Switzerland Joined: Jan 29, 2007 Post Count: 1684 Status: Offline Project Badges: 
|
Obviously second hand servers can be bought with a limited budget. Nonetheless the electricity power consumption of such servers is not few comparing to Raspberry Pi.
----------------------------------------You cannot simply compare the both without considering the operational costs. Cheers, Yves |
||
|
|
BobbyB
Veteran Cruncher Canada Joined: Apr 25, 2020 Post Count: 638 Status: Offline Project Badges:
|
Agreed and you have to look also at the total output of the small devices for the little watts. I retired an old Lenovo laptop because it produced no more than a Pi but used about 4x+ the power... and power is cheap where I am. If power is not cheap then it becomes a factor.
I made my case about powerful machines vs Pi's. My rig would require about 30 Pi's. (about 2x the cost). For 2x the cost I may have been able to go to the Ryzen 5950x instead of a 3900x. Maybe. If a few Pi's are the target then yes go with that but if you intend on building a little farm then consider PCs. To be fair your comment was about second hand servers vs consumption. Mine was about monster PCs vs Pi farms. |
||
|
|
mikey159c
Cruncher Joined: Aug 21, 2008 Post Count: 11 Status: Offline Project Badges: 
|
Another thing to think about though is using Pi's instead of a single pc for the same price is you can spread your resources across several different projects, or sub-projects at the same project, very easily. Yes one computer with 24 cores can be made to crunch 3 tasks for this projects, 6 tasks for that project etc but it's a pain to manage as projects run out of tasks.
|
||
|
|
KerSamson
Master Cruncher Switzerland Joined: Jan 29, 2007 Post Count: 1684 Status: Offline Project Badges:
|
I do not see any pain for managing a machine running several (WCG) projects simultaneously.
----------------------------------------On my side, I use the two levels: - WCG website for defining how many WUs shall be queued for each project. - app_config.xml on machine level for controlling the concurrent execution of various projects (in particular important regarding MIP1 and ARP1) on each machine. Cheers, Yves --- PS: Because not all machines stay at the same location, since two years, I hourly update (using crontab) the app_config.xml file automatically for my crunching PC using a remote file repository. When I decide to modify the balance between the projects, I only have to update the corresponding app_config.xml on the external repository and within an hour the machine will download the modified version. It is very convenient in particular because I am usually a frequent business traveller. |
||
|
|
BobbyB
Veteran Cruncher Canada Joined: Apr 25, 2020 Post Count: 638 Status: Offline Project Badges:
|
How so about MIP1 and ARP1?
Is it because ARP1 WUs are usually very long and sometimes MIP1 also? ....and how does that relate to controlling the concurrent execution of each machine as opposed to letting it all happen as it wants? I'm wondering if that is something (concurrent execution) I should be looking at. |
||
|
|
Acibant
Advanced Cruncher USA Joined: Apr 15, 2020 Post Count: 126 Status: Offline Project Badges: 
|
How so about MIP1 and ARP1? Is it because ARP1 WUs are usually very long and sometimes MIP1 also? ....and how does that relate to controlling the concurrent execution of each machine as opposed to letting it all happen as it wants? I'm wondering if that is something (concurrent execution) I should be looking at. KerSamson and Mike.Gibson have stated that limiting ARP to half your threads is apparently better for efficiency. See here for the example configuration. I would be curious as to exactly why but sam6861 gave some clear results showing it to be the case. sam6861 theorized it to be RAM bandwidth. At the end of that thread KerSamson postulated that it had to do with cache on the CPU. (As an aside, in the last post of the thread it was said that an upcoming Ryzen 5900X would be better with a single combined 64 MB cache. Unfortunately, that is not the case and the L3 is still two 32 MB chunks.)  |
||
|
|
BobbyB
Veteran Cruncher Canada Joined: Apr 25, 2020 Post Count: 638 Status: Offline Project Badges:
|
I'll tinker with that just to see how it works out with my Ryzen 3900x 2x16GB
|
||
|
|
KerSamson
Master Cruncher Switzerland Joined: Jan 29, 2007 Post Count: 1684 Status: Offline Project Badges:
|
Hi Acibant,
----------------------------------------very good summary of long and old discussions  Regarding MIP1, the memory represents a crucial challenge. Modern CPU's with a large Level 3 cache perform much better than older CPU without Level 3 cache or more recent CPU with a limited Level 3 cache size. After MIP1 launch, about 4 years ago, we were several contributors noticing that MIP1 caused a lot of "page fault". The only way to mitigate this issue - if you cannot change the CPU - is to limit the number of concurrent MIP1 WUs. ARP1 is a little bit less clear. However, several contributors notice that limiting the number of concurrent APR1 WUs to "number of thread / 2" or better "(number of thread / 2) - 1" have a positive impact on the execution time /WU. It is the reasons why managing a machine more accurately using app_config.xml is helpful and valuable. Such an approach is not mandatory, it is only nice for improving the performance. Cheers, Yves |
||
|
|
alanb1951
Veteran Cruncher Joined: Jan 20, 2006 Post Count: 1317 Status: Offline Project Badges: 
|
Further to all the stuff above about L3 cache and throughput, note that current Raspberry Pi machines do not have any L3 cache, so anything that misses in L2 cache goes straight to main memory.
This makes multiple OPN1 tasks run much slower than a single task would, and would render some of the larger tasks so memory-bound as to be effectively non-viable. The Pi coped really well during MCM1 Beta testing - it ran jobs far faster than OPN1 despite OPN1 being quicker than MCM1 on machines with reasonable L3 cache, This was because MCM1 accesses L3 cache a lot less than OPN1... I keep hoping that as they try to steer folks away from CPU-based OPN1 they re-visit MCM1 for ARM, and look to see if they can do SCC1 for ARM if SCC1 ever restarts (as that also has a reasonably low L3 cache access rate). At some point they'll presumably do Apple ARM builds... Cheers - Al. P.S. No, I do not want to run Android to be able to use the Pi. Can someone post typical run times for WCG projects on Android on ARM without L3 cache?... |
||
|
|
Acibant
Advanced Cruncher USA Joined: Apr 15, 2020 Post Count: 126 Status: Offline Project Badges:
|
P.S. No, I do not want to run Android to be able to use the Pi. Can someone post typical run times for WCG projects on Android on ARM without L3 cache?... I've backordered some Odroid N2+ 4GB units along with preloaded Android eMMCs. You can load BOINC from F-Droid without going through the trouble of installing Google Play services.They each have a quad-core ARM Cortex A73 CPU cluster and a dual-core Cortex A53 cluster and no L3 cache. I will run them at the overclocked 2.4 GHz that is possible in a normal household environment without a fan. Here's the nice thing: if you go by their benchmarks it is looking like they are around twice as fast as the Raspberry Pi 4. |
||
|
|
|