The "fftw-3.3.4" prefix of your wisdom file tells that the wisdom file was not created with the 3.3.6 version you just compiled. And then, the trick is with the right configuration of the fftw3 at compile time. You just compiled with no configuration at all. Run "configure --help" to see the options, of which one is to enable the NEON.
You have now somewhere on your disk a 3.3.6 version of your fftw that is not configured to fully use your hardware. I presume this is in /usr/local. And just he same way that you do not know if you use binaries of 3.3.4 or 3.3.6 when you just type in the name of the binary (you just ran into that), you do not know what version of a library the BRP app would then use when you have both on your disk. This depends on environment variables $PATH and $LD_LIBRARY_PATH and on how ldconfig is configured. There is "which" and "ldd" to check, but, if you can, please remove anything fftw-related from /usr/local again.
I want to praise you for your compiling from the source tree. It also means that you have all the build dependencies already available. If you do not mind too much, please perform the compilation once again, but this time with the configuration that the Debian maintainers have already prepared that adds the NEON flag when they see that it is ARM. You can leave your source tree of 3.3.6p2 as it is.
So first change into the source tree of fftw3. Then download the Debian build instructions from
and untar them right where you are in the source tree of fftw3 with
tar xJvf boinc-app-eah-brp_0.20170426+dfsg-2.debian.tar.xz
A folder named "debian" is now added that has all the description of the packages that are to be created. First, remove everything that you have compiled with
fakeroot ./debian/rules clean
and then create everything nicely from scratch with
fakeroot ./debian/rules binary
which should create a couple of .deb files in the directory above that have fftw and 3.3.6 in their filenames. You install them with "dpkg -i ... " which will also uninstall the previous 3.3.4 with which you created the wisdom file before.
Then create the wisdom file again. It should create a wisdom file starting with 3.3.6 and it should also take longer to create since it has more options how to perform the FFT. If it is taking no time again, then you have likely not removed the prior creates 3.3.6 binaries of fftw in /usr/local (or wherever) that are now found because ldconfig was triggered with the installation of the new fftw packages but the paths in /etc/ld.so.conf.d have given priorities to /usr/local/lib over /usr/lib.
The ARM-ready fftw3 version is already in Ubuntu https://packages.ubuntu.com/artful/libfftw3-3 but not yet backported. If you demonstrate me the energy to get through this all again as I described it above to get to the .deb files for your architecture and finally have the faster BRP search then I offer to volunteer to remote-train you to perform backports for everyone by uploading a Debian source package to an Ubuntu Personal Package Archive but I need to stay out of this myself, I am afraid.
The ARM-ready fftw3 version is already in Ubuntu https://packages.ubuntu.com/artful/libfftw3-3 but not yet backported. If you demonstrate me the energy to get through this all again as I described it above to get to the .deb files for your architecture and finally have the faster BRP search then I offer to volunteer to remote-train you to perform backports for everyone by uploading a Debian source package to an Ubuntu Personal Package Archive but I need to stay out of this myself, I am afraid.
Made one more attempt this morning but having issues with needed files/binaries not where they are expected. Also to add to the problems the blue led on the XU4 is flashing rapidly which indicates a kernel panic. This complicates things so I will hold off on this effort at the moment.
I suggest changing the default password as soon as you fire it up. I saw a tutorial about deleting the Pi user completely. Adding a firewall would also help (search iptables firewall).
I wonder if the Pi3 could run the O1Spot1Lo. If only they had an armhf app.
I have rearranged the Pi part of my farm. It now consists of 10 Pi3's crunching and one more providing support. I had to get more heatsinks from Enzotech and bolt some 40mm fans on to the top of the official Pi case. Currently closing in on 2 million credits for the Pi's.
I wonder if the Pi3 could run the O1Spot1Lo. If only they had an armhf app.
In general the PI3 could run O1Spot1Lo. Both the C2 and the Pi3 have a Cortes-A53 CPU.
I've just compiled the HierarchSearchGCT for ARM. And ported one inline-Assembly-Funktion (this is only necessary in terms of speed).
At the moment my C2 need's <1.4 days to complete a Task (x4). That should give a RAC of >2.800! I'm sure with use of a FFTW-wisdom it can be much faster. I guess a runtime of around 1day(RAC ~4000 ) should be possible.
But the PI3 havn't enought RAM to run 4 tasks in parrallel. I'm not shure if BOINC can be configured to run only 1 or 2 Tasks of O1Spot1Lo and the other BRP?
But the PI3 havn't enought RAM to run 4 tasks in parrallel. I'm not shure if BOINC can be configured to run only 1 or 2 Tasks of O1Spot1Lo and the other BRP?
Should be doable with an app_config.xml and <max_concurrent>X</max_concurrent>.
Stretch and Stretch Lite are now available for the Rpi from the foundation. A link to the Raspbian download page is here
They recommend you reinstall it but if you feel inclined you can also update your /etc/apt/sources.list and do a dist-upgrade. See the instructions on the Rpi download page for details. That also means you can all "upgrade" to the 7.6.33 BOINC client, just as they start testing 7.8
Stretch and Stretch Lite are now available for the Rpi from the foundation. A link to the Raspbian download page is here
They recommend you reinstall it but if you feel inclined you can also update your /etc/apt/sources.list and do a dist-upgrade. See the instructions on the Rpi download page for details. That also means you can all "upgrade" to the 7.6.33 BOINC client, just as they start testing 7.8
The BOINC 7.8.1 client has just arrived in Debian testing (https://packages.qa.debian.org/b/boinc.html, thanks, Gianfranco!) . While this is too late for the release that is already out, I am just finishing my first E@H units on a backport of 7.8.1 to that "Stretch" release. That laptop is a bit slower, bear with me. If everything is fine tonight, then I will immediately upload a BOINC 7.8.1 package to backports.debian.org. Instructions how to install from there will follow once the backport was accepted.
That said, I propose to just use 7.6.33 since that is just doing its job and to the best of my knowledge has no negative effect on the performance of the scientific app.
It seems that ssh has been disabled since Nov 2016, so you'll need to enable it or plug a screen and keyboard in. This is in response to bot's targeting the Pi userid.
I have reinstalled 3 so far. It looks like it will automatically resize the root partition on first boot. One less option to run through in raspi-config. It also gives a warning if you haven't changed the default password when you exit raspi-config.
Regarding BOINC 7.8.1 I haven't tried it on a Pi but did on a PC. The manager has a couple of issues which won't effect you if running headless. I believe Gianfranco already has the package going to backports at least for amd64.
The "fftw-3.3.4" prefix of
)
The "fftw-3.3.4" prefix of your wisdom file tells that the wisdom file was not created with the 3.3.6 version you just compiled. And then, the trick is with the right configuration of the fftw3 at compile time. You just compiled with no configuration at all. Run "configure --help" to see the options, of which one is to enable the NEON.
You have now somewhere on your disk a 3.3.6 version of your fftw that is not configured to fully use your hardware. I presume this is in /usr/local. And just he same way that you do not know if you use binaries of 3.3.4 or 3.3.6 when you just type in the name of the binary (you just ran into that), you do not know what version of a library the BRP app would then use when you have both on your disk. This depends on environment variables $PATH and $LD_LIBRARY_PATH and on how ldconfig is configured. There is "which" and "ldd" to check, but, if you can, please remove anything fftw-related from /usr/local again.
I want to praise you for your compiling from the source tree. It also means that you have all the build dependencies already available. If you do not mind too much, please perform the compilation once again, but this time with the configuration that the Debian maintainers have already prepared that adds the NEON flag when they see that it is ARM. You can leave your source tree of 3.3.6p2 as it is.
So first change into the source tree of fftw3. Then download the Debian build instructions from
http://cdn-fastly.deb.debian.org/debian/pool/main/b/boinc-app-eah-brp/boinc-app-eah-brp_0.20170426+dfsg-2.debian.tar.xz
and untar them right where you are in the source tree of fftw3 with
tar xJvf boinc-app-eah-brp_0.20170426+dfsg-2.debian.tar.xz
A folder named "debian" is now added that has all the description of the packages that are to be created. First, remove everything that you have compiled with
fakeroot ./debian/rules clean
and then create everything nicely from scratch with
fakeroot ./debian/rules binary
which should create a couple of .deb files in the directory above that have fftw and 3.3.6 in their filenames. You install them with "dpkg -i ... " which will also uninstall the previous 3.3.4 with which you created the wisdom file before.
Then create the wisdom file again. It should create a wisdom file starting with 3.3.6 and it should also take longer to create since it has more options how to perform the FFT. If it is taking no time again, then you have likely not removed the prior creates 3.3.6 binaries of fftw in /usr/local (or wherever) that are now found because ldconfig was triggered with the installation of the new fftw packages but the paths in /etc/ld.so.conf.d have given priorities to /usr/local/lib over /usr/lib.
The ARM-ready fftw3 version is already in Ubuntu https://packages.ubuntu.com/artful/libfftw3-3 but not yet backported. If you demonstrate me the energy to get through this all again as I described it above to get to the .deb files for your architecture and finally have the faster BRP search then I offer to volunteer to remote-train you to perform backports for everyone by uploading a Debian source package to an Ubuntu Personal Package Archive but I need to stay out of this myself, I am afraid.
Quote: The ARM-ready fftw3
)
Made one more attempt this morning but having issues with needed files/binaries not where they are expected. Also to add to the problems the blue led on the XU4 is flashing rapidly which indicates a kernel panic. This complicates things so I will hold off on this effort at the moment.
And news of a Pi specific
)
And news of a Pi specific Trojan...
guru3d link
I suggest changing the default password as soon as you fire it up. I saw a tutorial about deleting the Pi user completely. Adding a firewall would also help (search iptables firewall).
BOINC blog
Just got my first valid
)
Just got my first valid O1Spot1Lo on my Odroid-C2
https://einsteinathome.org/de/host/12538778/tasks
I wonder if the Pi3 could run
)
I wonder if the Pi3 could run the O1Spot1Lo. If only they had an armhf app.
I have rearranged the Pi part of my farm. It now consists of 10 Pi3's crunching and one more providing support. I had to get more heatsinks from Enzotech and bolt some 40mm fans on to the top of the official Pi case. Currently closing in on 2 million credits for the Pi's.
MarksRpiCluster
PorkyPies schrieb:I wonder if
)
In general the PI3 could run O1Spot1Lo. Both the C2 and the Pi3 have a Cortes-A53 CPU.
I've just compiled the HierarchSearchGCT for ARM. And ported one inline-Assembly-Funktion (this is only necessary in terms of speed).
At the moment my C2 need's <1.4 days to complete a Task (x4). That should give a RAC of >2.800! I'm sure with use of a FFTW-wisdom it can be much faster. I guess a runtime of around 1day(RAC ~4000
) should be possible.
But the PI3 havn't enought RAM to run 4 tasks in parrallel. I'm not shure if BOINC can be configured to run only 1 or 2 Tasks of O1Spot1Lo and the other BRP?
N30dG wrote:But the PI3
)
Should be doable with an app_config.xml and <max_concurrent>X</max_concurrent>.
Stretch and Stretch Lite are
)
Stretch and Stretch Lite are now available for the Rpi from the foundation. A link to the Raspbian download page is here
They recommend you reinstall it but if you feel inclined you can also update your /etc/apt/sources.list and do a dist-upgrade. See the instructions on the Rpi download page for details. That also means you can all "upgrade" to the 7.6.33 BOINC client, just as they start testing 7.8
BOINC blog
MarkJ wrote:Stretch and
)
The BOINC 7.8.1 client has just arrived in Debian testing (https://packages.qa.debian.org/b/boinc.html, thanks, Gianfranco!) . While this is too late for the release that is already out, I am just finishing my first E@H units on a backport of 7.8.1 to that "Stretch" release. That laptop is a bit slower, bear with me. If everything is fine tonight, then I will immediately upload a BOINC 7.8.1 package to backports.debian.org. Instructions how to install from there will follow once the backport was accepted.
That said, I propose to just use 7.6.33 since that is just doing its job and to the best of my knowledge has no negative effect on the performance of the scientific app.
It seems that ssh has been
)
It seems that ssh has been disabled since Nov 2016, so you'll need to enable it or plug a screen and keyboard in. This is in response to bot's targeting the Pi userid.
I have reinstalled 3 so far. It looks like it will automatically resize the root partition on first boot. One less option to run through in raspi-config. It also gives a warning if you haven't changed the default password when you exit raspi-config.
Regarding BOINC 7.8.1 I haven't tried it on a Pi but did on a PC. The manager has a couple of issues which won't effect you if running headless. I believe Gianfranco already has the package going to backports at least for amd64.
MarksRpiCluster