Could someone do that on the RPI3 and post the output, please? I borrowed my PI3 to a workmate and I need this output.
As I suspected, NEON isn't enabled on ARMv8-Devices. I've made a patch for that. At the moment it's compiling... should take some time.
There is another problem with fftw-versions < 3.3.5. The configure breakes with: need compiler that supports -mfpu=neon. There is no mfpu option on ARMv8 anymore. We could trick that by applying NEON_CFLAGS=-D__ARM_NEON__
It's a little bit dirty but I don't want to make a patch for a problem that is already solved in newer Versions.
steffen_moeller wrote:
The N30dG app was not yet tried.
No need for that. My App only works with ARMv8-devices ;)
There is another problem with fftw-versions < 3.3.5. The configure breakes with: need compiler that supports -mfpu=neon. There is no mfpu option on ARMv8 anymore. We could trick that by applying NEON_CFLAGS=-D__ARM_NEON__
It's a little bit dirty but I don't want to make a patch for a problem that is already solved in newer Versions.
I just sent fftw3 3.3.5 to backports.debian.org. Please send me your patch and I add this to the same and like to a new version 3.3.6 that is already out on the upstream servers - from what is in the changelog, version 3.3.6 it will not speed up anything but just compile better on platforms other than Linux I had tried to compile fftw3 3.3.5 on armhf myself but failed with an error "read NUL" that I somehow suspect to originate from my SD card.
So, just as a reference, with Debian Jessie factory setup, i.e. fftw3 3.3.4 and a minute-long wisdomf file generation, the Banana Pi R1 needs around 60000 seconds: https://einsteinathome.org/host/12523840/tasks
I should now check if this is more energy efficient than my laptop. I doubt it. So, just for the sports of it, let us see where we can get with 3.3.5 hopefully arriving in Jessie-backports any moment and with some extra scrutiny on the configuration.
Anyone with fancy MIPS machines around? PowerPC? You all can now use the Debian packages, too. Being active in the local Free Wifi movement ("Freifunk"), I am certainly tempted to go for an OpenWRT port of BOINC - anyone else out there?
Hello, I was just curious and checked the number of installations that the Debian package for BRP is reported to have. There is a voluntary reporting via the "popularity-contest" package with results showing up on https://qa.debian.org/popcon.php?package=boinc-app-eah-brp . We are at 4 (four), which, well, because of the doubling of the rate means an effective 8 . I also checked the stats for the BOINC client, which are mostly invariant since a while https://qa.debian.org/popcon.php?package=boinc . But that is only for Debian. Ubuntu and other derivatices have their own counters. Ubuntu's client is 45000 times reported as installed (http://popcon.ubuntu.com/universe/by_inst). The EAH BRP package has not arrived in those stats, yet.
The next thing more me to do as I see it is to separate the wisdom generation script from the installation of the BRP client, so this becomes a package on its own. That and after some more installations, we can eventually also start collecting wisdom files to be shared in the community.
On the matter of VHDL coding of FPGAs for FFTs : Xilinx has IP available to configure their hardware for FFT. Several main points of interest :
- only does up to 2^16
- with 32 bit floats for the data inputs you can only get up to 25 bit fixed point phase factors. That's not terrible, but ....
- there are a number of unfavourable aspects related to algorithm choices and effectively : ".... the noise is more prominent in the lower frequency bins." This is NotGoodEnough™ for E@H.
- you have to bloody well buy it.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I purchased an Odroid XU4 for reasons other then crunching but because of the need to use usb 3.0, the placement of the usb 3.0 ports and the ethernet port I cannot use it for this other purpose. I therefore decided to use it as a cruncher but have not been able to get any WUs to crunch successfully. I read through this thread but I am not sure were we are with respect to SBCs. Do we currently support the Droid XU4? I noted that someone had not had much success with a Droid XU3. I am using Pi3s and DroidC2s without issues using n30dg's code.
./boinc-app-eah-brp/debian/extra/create_wisdomf_eah_brp.sh I: Computing wisdom file for BRP4 and FGRP projects. This will take several hours if not days.
I: Generating wisdom for (2^22)*3 sample projects (BRP) W: Not recognising platform 'armv7l' as sufficiently capable for 2^26 bit projects fftw-wisdom: system-wisdom import failed PLANNING PROBLEM: rof12582912 I: Wisdom file was computed successfully. Do sudo mkdir -p /etc/fftw sudo mv '/tmp/wisdomf' /etc/fftw/wisdomf
sudo mkdir /etc/fftw
sudo mv /tmp/wisdomf /etc/fftw/
6. restart boinc-client:
sudo systemctl restart boinc-client
7. Be happy with your new fast cruncher
8. Tell me if that worked for you, and I tell you how to get it even faster .
Now you should restart boinc-client and try it. At this moment you run without a wisdom-file, so don't expect that it run too fast at this point.
The script is currently under development. The output is maybe a little bit confusing ;).
Quote:
finished in seconds with the following issues:
./boinc-app-eah-brp/debian/extra/create_wisdomf_eah_brp.sh I: Computing wisdom file for BRP4 and FGRP projects. This will take several hours if not days.
I: Generating wisdom for (2^22)*3 sample projects (BRP) W: Not recognising platform 'armv7l' as sufficiently capable for 2^26 bit projects fftw-wisdom:
This is normal behavior. The script generates a wisdom for the FGRP (2^26) too. But there is no need for that wisdom on arm-devices. So the script skips the generation of that.
That is okay, there is no system-wisdom at that point.
The problem with the short runtime of the wisdom-generation is caused by a bug in the current libfftw3 debian/ubuntu-package on ARM-devices. fftw can not access the performance-timer on ARM-devices. So it can't make the necessary measurements to generate a wisdom. Instead it only guesses the right settings and put that into the wisdomfile. Thats why it only takes seconds to compute.
We fixed that. But the fixed version(3.3.6p2-1) is only available under debian sid/unstable or ubuntu artful/devel at the moment.
I guess you are running ubuntu xenial on your odroid?
There are several ways to get the new Version of the fftw3-package. This is only one way and not the best way to do it.
edit your sources.list and add the following lines to it:
steffen_moeller
)
Could someone do that on the RPI3 and post the output, please? I borrowed my PI3 to a workmate and I need this output.
As I suspected, NEON isn't enabled on ARMv8-Devices. I've made a patch for that. At the moment it's compiling... should take some time.
There is another problem with fftw-versions < 3.3.5. The configure breakes with: need compiler that supports -mfpu=neon. There is no mfpu option on ARMv8 anymore. We could trick that by applying NEON_CFLAGS=-D__ARM_NEON__
It's a little bit dirty but I don't want to make a patch for a problem that is already solved in newer Versions.
No need for that. My App only works with ARMv8-devices ;)
N30dG
)
This is from my RPi3 running Raspbian:
It's the same as the first quote in your post.
N30dG wrote:There is another
)
I just sent fftw3 3.3.5 to backports.debian.org. Please send me your patch and I add this to the same and like to a new version 3.3.6 that is already out on the upstream servers - from what is in the changelog, version 3.3.6 it will not speed up anything but just compile better on platforms other than Linux
I had tried to compile fftw3 3.3.5 on armhf myself but failed with an error "read NUL" that I somehow suspect to originate from my SD card.
So, just as a reference, with
)
So, just as a reference, with Debian Jessie factory setup, i.e. fftw3 3.3.4 and a minute-long wisdomf file generation, the Banana Pi R1 needs around 60000 seconds: https://einsteinathome.org/host/12523840/tasks
I should now check if this is more energy efficient than my laptop. I doubt it. So, just for the sports of it, let us see where we can get with 3.3.5 hopefully arriving in Jessie-backports any moment and with some extra scrutiny on the configuration.
Anyone with fancy MIPS machines around? PowerPC? You all can now use the Debian packages, too. Being active in the local Free Wifi movement ("Freifunk"), I am certainly tempted to go for an OpenWRT port of BOINC - anyone else out there?
Hello, I was just curious and
)
Hello, I was just curious and checked the number of installations that the Debian package for BRP is reported to have. There is a voluntary reporting via the "popularity-contest" package with results showing up on https://qa.debian.org/popcon.php?package=boinc-app-eah-brp . We are at 4 (four), which, well, because of the doubling of the rate means an effective 8
. I also checked the stats for the BOINC client, which are mostly invariant since a while https://qa.debian.org/popcon.php?package=boinc . But that is only for Debian. Ubuntu and other derivatices have their own counters. Ubuntu's client is 45000 times reported as installed (http://popcon.ubuntu.com/universe/by_inst). The EAH BRP package has not arrived in those stats, yet.
The next thing more me to do as I see it is to separate the wisdom generation script from the installation of the BRP client, so this becomes a package on its own. That and after some more installations, we can eventually also start collecting wisdom files to be shared in the community.
On the matter of VHDL coding
)
On the matter of VHDL coding of FPGAs for FFTs : Xilinx has IP available to configure their hardware for FFT. Several main points of interest :
- only does up to 2^16
- with 32 bit floats for the data inputs you can only get up to 25 bit fixed point phase factors. That's not terrible, but ....
- there are a number of unfavourable aspects related to algorithm choices and effectively : ".... the noise is more prominent in the lower frequency bins." This is NotGoodEnough™ for E@H.
- you have to bloody well buy it.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I purchased an Odroid XU4 for
)
I purchased an Odroid XU4 for reasons other then crunching but because of the need to use usb 3.0, the placement of the usb 3.0 ports and the ethernet port I cannot use it for this other purpose. I therefore decided to use it as a cruncher but have not been able to get any WUs to crunch successfully. I read through this thread but I am not sure were we are with respect to SBCs. Do we currently support the Droid XU4? I noted that someone had not had much success with a Droid XU3. I am using Pi3s and DroidC2s without issues using n30dg's code.
You could build the BRP-App
)
You could build the BRP-App from our github-repositroy at your own. It's not that hard.
1. install git-buildpackage & build-dependencies
sudo apt-get update
sudo apt-get install git-buildpackage debhelper libboinc-app-dev libxml2-dev libiberty-dev libgsl-dev binutils-dev libfftw3-dev pkg-config
2. clone from our repositroy:
gbp clone https://github.com/VolunteerComputingHelp/boinc-app-eah-brp.git --pristine-tar
3. build the app:
cd boinc-app-eah-brp/
gbp buildpackage -uc -us
4. install the app:
cd ..
sudo dpkg -i boinc-app-eah-brp_0.20170426+dfsg-3_arm64.deb
5. generate a wisdom
./boinc-app-eah-brp/debian/extra/create_wisdomf_eah_brp.sh
(wait until finished, some hours)
sudo mkdir /etc/fftw
sudo mv /tmp/wisdomf /etc/fftw/
6. restart boinc-client:
sudo systemctl restart boinc-client
7. Be happy with your new fast cruncher
8. Tell me if that worked for you, and I tell you how to get it even faster
.
Quote:Quote:ran into a couple
)
in my "list of computers" the XU4 shows as:
ARM ARMv7 Processor rev 3 (v7l) (8 processors)
Zitat:Zitat: 4. install the
)
Sorry, my mistake, the armhf is the right package for your device :) So you should install that.
sudo dpkg -i boinc-app-eah-brp_0.20170426+dfsg-3_armhf.deb
Now you should restart boinc-client and try it. At this moment you run without a wisdom-file, so don't expect that it run too fast at this point.
The script is currently under development. The output is maybe a little bit confusing ;).
This is normal behavior. The script generates a wisdom for the FGRP (2^26) too. But there is no need for that wisdom on arm-devices. So the script skips the generation of that.
That is okay, there is no system-wisdom at that point.
The problem with the short runtime of the wisdom-generation is caused by a bug in the current libfftw3 debian/ubuntu-package on ARM-devices. fftw can not access the performance-timer on ARM-devices. So it can't make the necessary measurements to generate a wisdom. Instead it only guesses the right settings and put that into the wisdomfile. Thats why it only takes seconds to compute.
We fixed that. But the fixed version(3.3.6p2-1) is only available under debian sid/unstable or ubuntu artful/devel at the moment.
I guess you are running ubuntu xenial on your odroid?
There are several ways to get the new Version of the fftw3-package. This is only one way and not the best way to do it.
edit your sources.list and add the following lines to it:
sudo nano /etc/apt/sources.list
deb http://ports.ubuntu.com/ubuntu-ports/ devel main restricted deb-src http://ports.ubuntu.com/ubuntu-ports/ devel main restricted
do a update, NO UPGRADE!!!
sudo apt-get update
check the installation-candidate
apt-cache policy libfftw3-dev
You should find this in the output: Candidate: 3.3.6p2-1
Install it:
sudo apt-get install libfftw3
Remove both lines from soures.list
do apt-get update again