I'm using both wisdom's depending on the System Memory. I could explain why this happens but that would be a long post
What I meant was a work unit would take almost the same amount of time regardless of which type of wisdom you use (the impatient or the exhaustive).
While you mentioned the FGRP, how much memory do they need when running? I was looking to replace my Pi cluster with Pi4’s and the 2GB model is cheaper, but is 2GB enough to run 4 work units at a time (assuming aarch64 operating system and app)?
I'm using both wisdom's depending on the System Memory. I could explain why this happens but that would be a long post
What I meant was a work unit would take almost the same amount of time regardless of which type of wisdom you use (the impatient or the exhaustive).
While you mentioned the FGRP, how much memory do they need when running? I was looking to replace my Pi cluster with Pi4’s and the 2GB model is cheaper, but is 2GB enough to run 4 work units at a time (assuming aarch64 operating system and app)?
I hope that the 2GB model is enough as I just built my cluster with 2GB Pi4s.
What I meant was a work unit would take almost the same amount of time regardless of which type of wisdom you use (the impatient or the exhaustive).
Sorry my fault. I've probaly did not express myself well. The timing's and RAM-requirements I've posted are indeed for a work-unit using different wisdom's.
On what kind of system did you do your measurements? I've discovered quite a huge performance difference for inplace-transformations on these small ARM-devices.
PorkyPies wrote:
While you mentioned the FGRP, how much memory do they need when running? I was looking to replace my Pi cluster with Pi4’s and the 2GB model is cheaper, but is 2GB enough to run 4 work units at a time (assuming aarch64 operating system and app)?
There is no chance to fit 4 concurrent WU's into 2GB. I was able to squeeze 4 into 3gb. But to get the full performance out of it, you really need 4GB. We could speed this up even more if we only had more Memory.
Bryant Stewart wrote:
I hope that the 2GB model is enough as I just built my cluster with 2GB Pi4s.
Sorry, but this is not the end of the world.
I could imagine to run a FGRP on the GPU(+1CPU-Core) and use the other cores for BRP, which could possibly fit into 2GB. I've had the BRP-search running on a Mali-GPU of a RK3399 in the past, so this should be possible.
There is no chance to fit 4 concurrent WU's into 2GB. I was able to squeeze 4 into 3gb. But to get the full performance out of it, you really need 4GB. We could speed this up even more if we only had more Memory.
Apparently there was an 8GB model on some spec sheet from the Raspberry Pi foundation which was quickly removed. I suspect they want to get aarch64 sorted out with the ability to run armhf (legacy) apps before we will see it. For running a small cluster the 4GB model would be the one to get at this time.
N30dG-ARM wrote:
Do we have openCL-support on the PI4?
There was some limited OpenCL for the Pi3 but don’t think it ever took off as its not a full implementation.
There is no chance to fit 4 concurrent WU's into 2GB. I was able to squeeze 4 into 3gb. But to get the full performance out of it, you really need 4GB. We could speed this up even more if we only had more Memory.
Apparently there was an 8GB model on some spec sheet from the Raspberry Pi foundation which was quickly removed. I suspect they want to get aarch64 sorted out with the ability to run armhf (legacy) apps before we will see it. For running a small cluster the 4GB model would be the one to get at this time.
N30dG-ARM wrote:
Do we have openCL-support on the PI4?
There was some limited OpenCL for the Pi3 but don’t think it ever took off as its not a full implementation.
There seems to be separate efforts to support OpenCL for the Pi4 but following their online procedures has not produced positive results, i.e., none would give a clean compile. Some procedures were OS dependent with respect to libraries supplied etc. Here are two such links:
I am running Raspberry Pi4 overclocked to 2,1GHz (56 degrees thermal - active cooling with passive 9USD cooler from Aliexpress and small 3,3V fan on top of it + 2USD) and it seems fine even with 2GB (I have 4GB version, but never beyond 1,5GB). I am using standard Raspbian 32bit - client is with NEON extension. Standard crunching time is around 6hours 30-50 minutes for 4 crunched WUs. Each core is running one WU with 100% utilization. See my HW in profile. It has 80 000 MIPS (Dhrystone) and 2 900 MIPS (Whetstone) per core.
I have a hdmi kvm switch to switch between towers. I have recently plugged in 2 Pis and they don't seem to play well with my kvm switch. Anyone??????
I came across an article about Piz not responding to hdmi interfaces. The advice given was to add the following line of code to the /boot/config.txt file. I tried adding this line to this file and now the Pi that would not "write" to the hdmi connected monitor on my kvm setup is just fine, i.e. seems to solve my problem with the kvm switch. It might also be worth adding this line to your config.txt file regardless.
I returned to this thread this morning seeking an answer to what I had done to solve my kvm problem, only to realize that while I said I had a good solution and that it worked I DID NOT post the solution. So here it is: In the file /boot/config.txt either add or uncomment the line: "hdmi_force_hotplug=1" . A mind is a terrible thing to waste.
I have recently moved my root filesystems on my pi 4s running ubuntu 19 to a 64 gig usb drive using the instructions found here: https://www.tomshardware.com/news/boot-raspberry-pi-from-usb,39782.html This procedure does work except for one step at the end which states to "paste the following text at the end of the first (and likely only) line of cmdline.txt".
root=/dev/sda1 rootfstype=ext4 rootwait
This had no effect whatsoever. It was as if the Pi/ubuntu 19 was not reading the cmdline.txt file. After spending a great deal of time on this here is the solution that works. On the Pi 4
cd /boot/firmware
cp nobtcmd.txt nobtcmd.txt_save
in the nobtcmd.txt file remove the entry “root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc” and replace with “root=/dev/sda1 rootfstype=ext4 rootwait” <—your external usb flash drive with root
be sure to save the file
reboot your system.
when up do a df and you should see: /dev/sda1 #### #### #### 28% /
notice /dev/sda1 mounted to mount point “/‘
I wrote some instructions in 2016 for how to move the root file system to an external device for Raspbian. See http://markjatboinc.blogspot.com/2016/10/moving-rpi-root-partition.html. They’re for Raspbian and not Ubuntu though so might not work for you. They still work apart from rsync is already installed these days.
N30dG-ARM wrote:I'm using
)
What I meant was a work unit would take almost the same amount of time regardless of which type of wisdom you use (the impatient or the exhaustive).
While you mentioned the FGRP, how much memory do they need when running? I was looking to replace my Pi cluster with Pi4’s and the 2GB model is cheaper, but is 2GB enough to run 4 work units at a time (assuming aarch64 operating system and app)?
MarksRpiCluster
PorkyPies wrote:N30dG-ARM
)
I hope that the 2GB model is enough as I just built my cluster with 2GB Pi4s.
PorkyPies wrote:What I meant
)
Sorry my fault. I've probaly did not express myself well. The timing's and RAM-requirements I've posted are indeed for a work-unit using different wisdom's.
On what kind of system did you do your measurements? I've discovered quite a huge performance difference for inplace-transformations on these small ARM-devices.
There is no chance to fit 4 concurrent WU's into 2GB. I was able to squeeze 4 into 3gb. But to get the full performance out of it, you really need 4GB. We could speed this up even more if we only had more Memory.
Sorry, but this is not the end of the world.
I could imagine to run a FGRP on the GPU(+1CPU-Core) and use the other cores for BRP, which could possibly fit into 2GB. I've had the BRP-search running on a Mali-GPU of a RK3399 in the past, so this should be possible.
Do we have openCL-support on the PI4?
N30dG-ARM wrote:There is no
)
Apparently there was an 8GB model on some spec sheet from the Raspberry Pi foundation which was quickly removed. I suspect they want to get aarch64 sorted out with the ability to run armhf (legacy) apps before we will see it. For running a small cluster the 4GB model would be the one to get at this time.
There was some limited OpenCL for the Pi3 but don’t think it ever took off as its not a full implementation.
MarksRpiCluster
PorkyPies wrote:N30dG-ARM
)
There seems to be separate efforts to support OpenCL for the Pi4 but following their online procedures has not produced positive results, i.e., none would give a clean compile. Some procedures were OS dependent with respect to libraries supplied etc. Here are two such links:
Interesting
)
Interesting article
http://raspberrypi.hosted.phplist.com/lists/lt.php?tid=KUVRAlpRUAECW04FBwYGTldbAgJPAQZQAh5WAFRRVVYCW1FXAQxKDARUVlVXAQ5OAltVU09XBlVTHlddBFMdBAMMWQIGUg4BVlACH1MFVlNVXVJST1VTAVceAQkDUR0EAghQTlIAAQBXAgFRVAQCUA
I didn't know there were two throttling temperatures on the pi4. This explains why I have been getting results at 8500 and 12500.
I am running Raspberry Pi4
)
I am running Raspberry Pi4 overclocked to 2,1GHz (56 degrees thermal - active cooling with passive 9USD cooler from Aliexpress and small 3,3V fan on top of it + 2USD) and it seems fine even with 2GB (I have 4GB version, but never beyond 1,5GB). I am using standard Raspbian 32bit - client is with NEON extension. Standard crunching time is around 6hours 30-50 minutes for 4 crunched WUs. Each core is running one WU with 100% utilization. See my HW in profile. It has 80 000 MIPS (Dhrystone) and 2 900 MIPS (Whetstone) per core.
robl wrote:robl wrote:I have
)
I returned to this thread this morning seeking an answer to what I had done to solve my kvm problem, only to realize that while I said I had a good solution and that it worked I DID NOT post the solution. So here it is: In the file /boot/config.txt either add or uncomment the line: "hdmi_force_hotplug=1" . A mind is a terrible thing to waste.
I have recently moved my root
)
I have recently moved my root filesystems on my pi 4s running ubuntu 19 to a 64 gig usb drive using the instructions found here: https://www.tomshardware.com/news/boot-raspberry-pi-from-usb,39782.html This procedure does work except for one step at the end which states to "paste the following text at the end of the first (and likely only) line of cmdline.txt".
root=/dev/sda1 rootfstype=ext4 rootwait
This had no effect whatsoever. It was as if the Pi/ubuntu 19 was not reading the cmdline.txt file. After spending a great deal of time on this here is the solution that works. On the Pi 4
/dev/sda1 / ext4 defaults,noatime 0 1
/etc/fstab should now look like:
#LABEL=writable / ext4 defaults 0 0
/dev/sda1 / ext4 defaults,noatime 0 1
LABEL=system-boot /boot/firmware vfat defaults 0 1
I wrote some instructions in
)
I wrote some instructions in 2016 for how to move the root file system to an external device for Raspbian. See http://markjatboinc.blogspot.com/2016/10/moving-rpi-root-partition.html. They’re for Raspbian and not Ubuntu though so might not work for you. They still work apart from rsync is already installed these days.
On another note I had to re-learn how to add the Debian repos to Raspbian while experimenting with the Pi4 and aarch64. See https://marksrpicluster.blogspot.com/2019/12/add-buster-backports-to-raspberry-pi.html. It took a bit of time to find the right signing keys.
MarksRpiCluster