At the time I posted, those were the numbers for the N216 models.
Looking at Properties now, they show similar to what you say. :(

I have a very vague memory that something like this occurred earlier in the year when I was looking at some that I was running.

Which is another reason for saying that 3-4 Gigs per model is a good amount of ram to have these days. :)

Yes, these new Linux tasks are huge memory hogs.

---

Hi
I'm using Debian GNU/Linux 10 (buster).
Can you help me how to load the 32 libs needed to run CPDN ?

Regards
Christian

Hi
I'm using Debian GNU/Linux 10 (buster).
Can you help me how to load the 32 libs needed to run CPDN ?

Regards
Christian

Sure. These are my notes for my Buster installations. This worked for me:

Instructions for running 32 bit apps on Debian Stretch and Buster:

dpkg --add-architecture i386
dpkg --print-foreign-architectures
apt update
apt install zlib1g:i386 libncurses5:i386 libbz2-1.0:i386 libstdc++6:i386 -y

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

Hi
I'm using Debian GNU/Linux 10 (buster).
Can you help me how to load the 32 libs needed to run CPDN ?

Regards
Christian

Hi Christian,

try the instructions from this post in the thread.
https://www.cpdn.org/forum_thread.php?id=8008&postid=61468

THX a lot Dave
Christian

To try and keep all the information at the top of it's thread, the instructions have been placed into a new thread and this one re-named. Only moderators can add to the new thread however.

If you have instructions for a distro that isn't covered, please post them here and they will be added to the sticky.

Gentoo is one that springs to mind. I know there are crunchers out there using it but I am sure there are many others.

This is strange. Very, very strange. I just built a new Ryzen 3600 machine and installed Ubuntu 18.04.4 (actually it was 18.04.3, but it updates itself immediately).
I then attached to CPDN, but had not gotten around to installing the 32-bit libraries yet when the first N216 started running.

Now it has been running for 1 1/2 hours without a problem and is making good progress.
https://www.cpdn.org/results.php?hostid=1497978

So:

Ubuntu now includes 32-bit libraries by default.
HadAM4 now is 64-bit
It is taking a long time to crash

Take your pick.

This is strange. Very, very strange. I just built a new Ryzen 3600 machine and installed Ubuntu 18.04.4 (actually it was 18.04.3, but it updates itself immediately).
I then attached to CPDN, but had not gotten around to installing the 32-bit libraries yet when the first N216 started running.

Now it has been running for 1 1/2 hours without a problem and is making good progress.
https://www.cpdn.org/results.php?hostid=1497978

So:

Ubuntu now includes 32-bit libraries by default.
HadAM4 now is 64-bit
It is taking a long time to crash

Take your pick.

Well, if it's now 64-bit, the Applications page doesn't have any change for that app since June 2019 (8.52), and the requirements when doing an ldd on the 8.52 executables include 32bit libraries so that is not it, unless you are running a version of hadam4h not listed on the Applications page. Without 32 bit libraries, it should crash right away, but you can go into the climateprediction.net directory and do a sudo ldd on the hadam4 type executables to make sure all the requirements are satisfied. So maybe it's the automatic inclusion of 32bit libraries in Ubuntu 18.04.4? Seems strange to me. Maybe you accidentally installed 32bit Ubuntu? LOL ;-)

There's been some talk of statically linking the executables to libraries downloaded along with the app from cpdn, but nothing has been announced and I would think there would be a new version of hadam4 for that.

Maybe you accidentally installed 32bit Ubuntu? LOL ;-)

I have a checklist for my installations, and hadn't gotten to that part yet. But I do it so often, that it probably figured it out for itself.
It is an example of machine learning.

Ubuntu now includes 32-bit libraries by default.
HadAM4 now is 64-bit

Not on my 64-bit machine. All seem to be 32-bit.

$ file hadam4_8.09_i686-pc-linux-gnu hadam4_8.52_i686-pc-linux-gnu hadam4_um_8.09_i686-pc-linux-gnu hadam4_um_8.52_i686-pc-linux-gnu hadcm3s_8.36_i686-pc-linux-gnu hadcm3s_um_8.34_i686-pc-linux-gnu hadcm3s_um_8.36_i686-pc-linux-gnu

hadam4_8.09_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
hadam4_8.52_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
hadam4_um_8.09_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
hadam4_um_8.52_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
hadcm3s_8.36_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
hadcm3s_um_8.34_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
hadcm3s_um_8.36_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

---

Ubuntu now includes 32-bit libraries by default.
HadAM4 now is 64-bit
It is taking a long time to crash


Take your pick.

Batch statistics for #863 show 5% hard fails, the overwhelming majority within about six seconds due to missing 32bit libraries.

https://www.cpdn.org/result.php?resultid=21909648

In reality many are not hard fails as they now get 4 chances but they are shown as hard fails after 3.

Edit: At least one I found is running 18.04 and crashing everything because of that missing lib.

https://www.cpdn.org/show_host_detail.php?hostid=1495316

Instructions for Red Hat Enterprise Linux 7 do not work for Red Hat Enterprise Linux 8. I am not surprised. I have not found out where to find compatibility libraries.

$ sudo yum install compat-libstdc++-33.i686 compat-libstdc++-33.x86_64 zlib.i686 libstdc++.i686
[sudo] password for jeandavid8:
Updating Subscription Management repositories.
Repository 'amdgpu-pro-local' is missing name in configuration, using id.
amdgpu-pro-local 2.8 MB/s | 2.9 kB 00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 3.8 kB/s | 4.5 kB 00:01
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 3.5 kB/s | 4.0 kB 00:01
No match for argument: compat-libstdc++-33.i686
No match for argument: compat-libstdc++-33.x86_64
Error: Unable to find a match

---

Instructions for Red Hat Enterprise Linux 7 do not work for Red Hat Enterprise Linux 8. I am not surprised. I have not found out where to find compatibility libraries.

I don't suppose the latest Fedora libraries work? - Just an idea. (It is now over ten years since I switched to Debian based distributions so not based on anything other than guesswork.)

Instructions for Red Hat Enterprise Linux 7 do not work for Red Hat Enterprise Linux 8. I am not surprised. I have not found out where to find compatibility libraries.

$ sudo yum install compat-libstdc++-33.i686 compat-libstdc++-33.x86_64 zlib.i686 libstdc++.i686
[sudo] password for jeandavid8:
Updating Subscription Management repositories.
Repository 'amdgpu-pro-local' is missing name in configuration, using id.
amdgpu-pro-local 2.8 MB/s | 2.9 kB 00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 3.8 kB/s | 4.5 kB 00:01
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 3.5 kB/s | 4.0 kB 00:01
No match for argument: compat-libstdc++-33.i686
No match for argument: compat-libstdc++-33.x86_64
Error: Unable to find a match

Try

sudo yum -y install libstdc++.i686 libnsl.i686

also, zlib.i686 and/or zlib-devel.i686 for hadcm3s file upload creation

If anything else is missing, perhaps some other suggestions for 32 bit libraries could be found in
https://www.ibm.com/support/pages/how-configure-red-hat-enterprise-linux-8-run-rational-clearcase#arch-x86-cc32

Try

sudo yum -y install libstdc++.i686 libnsl.i686

also, zlib.i686

Sorry for the delay. My new machine, running Red Hat Enterprise Linux release 8.2 (Ootpa), crashed occasionally a few days after I got it; 32 Gig of RAM, 16-core processor (really 8 hyperthreaded ones Xeon chip) 512 GByte SSD main hard drive, but two SATA 7200 rpm spinning hard drives as well.

Had to do a swap-out of the mother board, some electronics, and the SSD to get the machine working. Then boinc would not work at all (systemd and SELinux issues). So finally, it seems to be running OK.

OK: I put those in today. They admit to being

libstdc++.so.6.0.25: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=da946bb8af65f6883ec078fa8176b4b200685d37, stripped

libnsl-2.28.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=b433921a36385b8887d2eb694a285eccb973c4d8, for GNU/Linux 3.2.0, not stripped

libz.so.1.2.11: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=35484a1d8413117ab4dc3fef83f225eae49d00ec, stripped

---

I have four instances of Linux Mint and one Zorin running in VM. After a few stumbles and falls, so far they are running fine. One question. Do Linux WU's run faster than Windows?

Do Linux WU's run faster than Windows?

As none of the tasks currently sent out by CPDN run on both Linux and Windows it is almost impossible to answer this question. From memory when all tasks were multiplatform I seem to remember that they would finish marginally faster on Windows machines than Linux ones all other things being equal but if you look at the BOINC forums where this has been discussed on and off over the years you will see it varies from project to project and while not relevant for CPDN it can also vary between graphic cards when one operating system has much better drivers than the other for a particular card.

There are a few other people around who will remember the days when all tasks were multiplatform who may have better memories than I do about the difference between operating systems then. (It was in my early days of using BOINC and I knew a lot less about all of the different variables involved than I do now!

---

Please do not private message myself or other moderators for help. This limits the number of people who are able to help and deprives others who may benefit from the answer.

Do Linux WU's run faster than Windows?

As none of the tasks currently sent out by CPDN run on both Linux and Windows it is almost impossible to answer this question. From memory when all tasks were multiplatform I seem to remember that they would finish marginally faster on Windows machines than Linux ones all other things being equal but if you look at the BOINC forums where this has been discussed on and off over the years you will see it varies from project to project and while not relevant for CPDN it can also vary between graphic cards when one operating system has much better drivers than the other for a particular card.

There are a few other people around who will remember the days when all tasks were multiplatform who may have better memories than I do about the difference between operating systems then. (It was in my early days of using BOINC and I knew a lot less about all of the different variables involved than I do now!

I would like to add that while a Windows C compiler can make Linux executables and vice versa neither can guarantee equal cross platform performance. So it's best to use Windows to make programs for Windows and to use Linux to make programs for Linux.

Do Linux WU's run faster than Windows?

I vaguely remember the Old Days when you could run either. I was on Windows 7 64-bit then.
I think the work units ran so long, and there was such variation, that no very good comparison could be made.
Which is another way of saying that there was not enough of a difference to matter.