Do you even need a 5V fan ? I bought a Noctua fan at a yard sale for 1€ and it works perfectly on 5V and is absolutely silent.
Well it would not be enough if you add a filter, but it works perfectly like this to keep my Pi 2 cool.
This is my ghetto setup running under my desk:
I used 5V because the Pi provides 5V. I had used very small 5V fans but they had a short life/high failure rate so the larger ones seem to work better. I am not familiar with Noctua fans (specs) so I cannot really comment. But your setup seems to work.
Milestones Yesterday
Raspberry Pi passed 2,000,000
Closing in on Pi
@Bikeman,
The mods that were done for the aarch64 Linux app. Are they able to be applied to the ARM v7 app? It might give us a bit of a speed boost. See this thread
Maybe I can answer that:
For ARMv7 it's hard to apply these mods because you have to ensure backwards compatibility to older devices. Optimizing means often "bring the Programm closer to the Hardware". But that's not easy for ARMv7 because you don't know what have. e.g: Neon is only optional for ARMv7 and can be 128bit-wide or only 64bit-wide. Even the implementation of NEON can vary, some vendors implement NEON as a VFP-extention(share Pipline with the Core), some as a coprocessor(own Pipline).
For ARMv8 things are much clearer. e.g: ARMv8 have always a 128bit wide NEON and it have always his own Pipline.
And there are some other restrictions like the RAM-usage, the AARCH64-App needs much more, this maybe a Problem on older devices with less RAM.
You can always optimize a Programm but this maybe comes at the costs to support only a few devices instead of all. ARMv7 is a really wide term.
The current ARMv7-App does a really good job. *ThumbsUp*
But:
All of these is not true for the RPI3, wich is a ARMv8 only restricted to 32bit. And I'm currently working on a Version for it ;)
Greetings
edit: I've forgot to say that the Speed-improvements from the AARCH64-App comes simplymainly from using a other(better) Architecture, so even without these Problems the speedincrease isn't that big on ARMv7.
We will be looking at the contributed code and try to bring as many improvements to the ARMv7 code branch as possible.
The hardware of the Pi3 and the Odroid C2 are quite similar IIRC, both should use ARM Cortex A53 cores. So I'm not quite sure how fast we could make this for a version compiled for the RPi3 even when running on a 32 bit OS. Unfortunately it's difficult to tell the RPI3 and the RPI2 apart from a BOINC point of view, when run under a 32 bit OS, the RPI3 reports its CPU as "ARMv7", and the CPU features also don't include anything directly informing you it is actually a ARMv8. The RPI3's CPU has the CRC32 feature tho, which the RPI2's lacks, but that would be a bit of a hack.
For Intel, we never saw a big difference in performance between code compiled for 64 bit or 32 bit, even tho Intel CPUs have more CPU registers visible when run in 64 bit mode. I'm not sure how different ARM CortexA53 cores behave when run in 64bit mode compared to 32bit mode.
It's possible that moving to a newer FFTW version (the one used in the "ARMv8 OdroidC2 optimized" version) alone will give the RPI a boost. We'll see.
I am out of my league here but I noticed that on the Odroid C-2, dmesg reports the following:
[ 0.027953] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 7 counters available
where as the Pi3 reports:
0.230874] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
Would any of this help sort out "which Pi do you have?".
[EDIT] I just came across PMU Driver logic which seems to be responsible for the dmesg output noted above. This seems to be enabled on both Ubuntu operating systems that I am running on Droids and Pi3s.
For Intel, we never saw a big difference in performance between code compiled for 64 bit or 32 bit, even tho Intel CPUs have more CPU registers visible when run in 64 bit mode. I'm not sure how different ARM CortexA53 cores behave when run in 64bit mode compared to 32bit mode.
The difference seem's to be huge. I was totally wrong with these:
Quote:
All of these is not true for the RPI3, wich is a ARMv8 only restricted to 32bit.
ARMv8-A in 32bit-mode(AArch32) is more like(and its designed to be) a "ARMv7-compatibility-mode."
e.g. in AArch32-mode you have only 32x64bit NEON-Registers(can be viewed as 16x128bit-Registers). in AArch64-mode you have 32x128bit Registers. And it's not only the number of registers, this is also true for most of the instructions. There are less Instructions and they work more like on a ARMv7, even the syntax differs.(With AArch64 they have changed the ASM-syntax)
I've made a few test and it doesn't seem's to be done with a simple recompile of the AArch64-version. Performance increase is poor.
FFTW seem's to ignore the wisdom from the C2, so I have to make a new -.-.
The modifyed resampling seem's to slow things down(lack of NEON-registers).
The only improvement, that I can determine comes from switch FFTW to out-of-place.
And I don't know if this is a good idea for the PI3, needs almost all the RAM of the PI3... for 24/7 crunchers with a minimal Linux it's okay, but for other devices maybe not. (performance increase is ~5ksec, without a wisdom).
Sadly, it seem's that all thinks have to be done from the scratch.
You can take a look a my PI3 to see the progress: https://einsteinathome.org/host/12349552
But for the next 5Day's there are no changes because the PI3 is computing a wisdom and I don't touch him to not affect results. But the 3 other cores are crunching ;)
RE: Do you even need a 5V
)
I used 5V because the Pi provides 5V. I had used very small 5V fans but they had a short life/high failure rate so the larger ones seem to work better. I am not familiar with Noctua fans (specs) so I cannot really comment. But your setup seems to work.
Milestones
)
Milestones Yesterday
Raspberry Pi passed 2,000,000
Project Rank: 1790
Grats all!
RE: Milestones
)
Closing in on Pi
@Bikeman,
The mods that were done for the aarch64 Linux app. Are they able to be applied to the ARM v7 app? It might give us a bit of a speed boost. See this thread
MarksRpiCluster
Maybe I can answer that: For
)
Maybe I can answer that:
For ARMv7 it's hard to apply these mods because you have to ensure backwards compatibility to older devices. Optimizing means often "bring the Programm closer to the Hardware". But that's not easy for ARMv7 because you don't know what have. e.g: Neon is only optional for ARMv7 and can be 128bit-wide or only 64bit-wide. Even the implementation of NEON can vary, some vendors implement NEON as a VFP-extention(share Pipline with the Core), some as a coprocessor(own Pipline).
For ARMv8 things are much clearer. e.g: ARMv8 have always a 128bit wide NEON and it have always his own Pipline.
And there are some other restrictions like the RAM-usage, the AARCH64-App needs much more, this maybe a Problem on older devices with less RAM.
You can always optimize a Programm but this maybe comes at the costs to support only a few devices instead of all. ARMv7 is a really wide term.
The current ARMv7-App does a really good job. *ThumbsUp*
But:
All of these is not true for the RPI3, wich is a ARMv8 only restricted to 32bit. And I'm currently working on a Version for it ;)
Greetings
edit: I've forgot to say that the Speed-improvements from the AARCH64-App comes
simplymainly from using a other(better) Architecture, so even without these Problems the speedincrease isn't that big on ARMv7.We will be looking at the
)
We will be looking at the contributed code and try to bring as many improvements to the ARMv7 code branch as possible.
The hardware of the Pi3 and the Odroid C2 are quite similar IIRC, both should use ARM Cortex A53 cores. So I'm not quite sure how fast we could make this for a version compiled for the RPi3 even when running on a 32 bit OS. Unfortunately it's difficult to tell the RPI3 and the RPI2 apart from a BOINC point of view, when run under a 32 bit OS, the RPI3 reports its CPU as "ARMv7", and the CPU features also don't include anything directly informing you it is actually a ARMv8. The RPI3's CPU has the CRC32 feature tho, which the RPI2's lacks, but that would be a bit of a hack.
For Intel, we never saw a big difference in performance between code compiled for 64 bit or 32 bit, even tho Intel CPUs have more CPU registers visible when run in 64 bit mode. I'm not sure how different ARM CortexA53 cores behave when run in 64bit mode compared to 32bit mode.
It's possible that moving to a newer FFTW version (the one used in the "ARMv8 OdroidC2 optimized" version) alone will give the RPI a boost. We'll see.
I am out of my league here
)
I am out of my league here but I noticed that on the Odroid C-2, dmesg reports the following:
[ 0.027953] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 7 counters available
where as the Pi3 reports:
0.230874] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
Would any of this help sort out "which Pi do you have?".
[EDIT] I just came across PMU Driver logic which seems to be responsible for the dmesg output noted above. This seems to be enabled on both Ubuntu operating systems that I am running on Droids and Pi3s.
RE: It's possible that
)
Let us know if you need any testers for any of this.
My Pi Clusters will cross 1,000,000 before the week is out!
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: For Intel, we never
)
The difference seem's to be huge. I was totally wrong with these:
ARMv8-A in 32bit-mode(AArch32) is more like(and its designed to be) a "ARMv7-compatibility-mode."
e.g. in AArch32-mode you have only 32x64bit NEON-Registers(can be viewed as 16x128bit-Registers). in AArch64-mode you have 32x128bit Registers. And it's not only the number of registers, this is also true for most of the instructions. There are less Instructions and they work more like on a ARMv7, even the syntax differs.(With AArch64 they have changed the ASM-syntax)
I've made a few test and it doesn't seem's to be done with a simple recompile of the AArch64-version. Performance increase is poor.
FFTW seem's to ignore the wisdom from the C2, so I have to make a new -.-.
The modifyed resampling seem's to slow things down(lack of NEON-registers).
The only improvement, that I can determine comes from switch FFTW to out-of-place.
And I don't know if this is a good idea for the PI3, needs almost all the RAM of the PI3... for 24/7 crunchers with a minimal Linux it's okay, but for other devices maybe not. (performance increase is ~5ksec, without a wisdom).
Sadly, it seem's that all thinks have to be done from the scratch.
You can take a look a my PI3 to see the progress:
https://einsteinathome.org/host/12349552
But for the next 5Day's there are no changes because the PI3 is computing a wisdom and I don't touch him to not affect results. But the 3 other cores are crunching ;)
Big milestone for me today -
)
Big milestone for me today - my Pi clusters passed 1,000,000 credits and my RAC is over 8,000!
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
has anyone seen a pi powered
)
has anyone seen a pi powered using POE. I am certain that power at the Pi end would have to be "managed"?