Distributed Computing on Raspberry Pi

michalrz said:
Did some more checks, including writing to NFS. Turned out more demanding than writing to microSD, but do note the transfer speed difference.
Click to expand...
Fantastic data! Thanks for testing all of this. I've got 15 Pi 4s (various size ram) wired into the same UPS now and at full load are running 68w, but I'm also powering 2 120mm fans off the pis, so my UPS is in the right ballpark. I can adjust any settings you find to be beneficial and see how it affects power on my pi cluster.

As for specific comments on the network copy, for 100MB it looks like its slighly more power efficient to use network storage instead of local sd card since you'll be copying less than half the amount of time. You were also copying at 1gbit it looks like? I wonder if it might be better to stay at 1gb all the time instead of 100mbit, or to setup transfer window times. I probably need to see how much network use a pi uses while processing a WU instead of just reporting one.
 
Endgame said:
As for specific comments on the network copy, for 100MB it looks like its slighly more power efficient to use network storage instead of local sd card since you'll be copying less than half the amount of time. You were also copying at 1gbit it looks like? I wonder if it might be better to stay at 1gb all the time instead of 100mbit, or to setup transfer window times. I probably need to see how much network use a pi uses while processing a WU instead of just reporting one.
Click to expand...
Yeah, didn't think about that. Yes, these are "baseline" numbers, so 1gbps. That 50 megabytes/s is simply the rate at which my old backup server writes (2TB spinner drive).
Ya know, I wouldn't yet rule out WiFI. If you look at the 1st section, there's "Idling, boot to console, wifi, but no ethernet @ 0.38A 1.39W".
So, the wireless is being quite efficient when it doesn't do anything except maintain a SSH session.
I guess I should and will re-do both write tests, but this time I'll use WiFi.

Oh and the last thing you mentioned would definitely rock, but I imagine it'd be hard to implement a switch switch with detecting what's required.

Edit: added a result for writing from /dev/zero to a NFS share over WiFi. Power usage is very nice, but the transfer speed is absolutely pathetic.
 
Last edited:
michalrz said:
Yeah, didn't think about that. Yes, these are "baseline" numbers, so 1gbps. That 50 megabytes/s is simply the rate at which my old backup server writes (2TB spinner drive).
Ya know, I wouldn't yet rule out WiFI. If you look at the 1st section, there's "Idling, boot to console, wifi, but no ethernet @ 0.38A 1.39W".
So, the wireless is being quite efficient when it doesn't do anything except maintain a SSH session.
I guess I should and will re-do both write tests, but this time I'll use WiFi.

Oh and the last thing you mentioned would definitely rock, but I imagine it'd be hard to implement a switch switch with detecting what's required.

Edit: added a result for writing from /dev/zero to a NFS share over WiFi. Power usage is very nice, but the transfer speed is absolutely pathetic.
Click to expand...
I've seen the same thing with wifi to NFS - terrible performance, and It gets worse the more Pis you add too. I've got 19 at the house, and if I even put 10 of them on the wifi in addition to the phones, tablets, and laptop, wifi starts to get really flaky. Where wifi would be appealing, assuming it local storage wasn't a deal breaker would be to set an upload window (easy to do in a boinc config file) and then have each pi only connected to wifi 1 hour / day, and have it turn off wifi the rest of the day. I believe that requries a reboot, though, which is also annoying to work around.
 
I wrote a quick perl script to augment a script I already had to read network traffic. I set it up to write to /tmp as a background process and killed my ssh session to the host, and let it run for 30 minutes.

The pi was running WCG OP and did not complete any tasks during the time window. average sent network traffic was right around 1.2KB / minute (~20bytes / sec), a little less for received. I suspect that checkpointing and some lite OS traffic is causing the network traffic. I will see if I can change the checkpoint interval and see if it has any effect.
 
Last edited:
michalrz said:
2.5 Commenting out dtoverlay=vc4-fkms-v3d in /boot/config.txt
0.50A 2.50W (Yes, worse. Outliers will be revisited later on)
Click to expand...
I re-enabled dtoverlay=vc4-fkms-v3d across my 15 Pi 4s, and saw no difference one way or another. Unfortunately, my UPS only reads in whole watts, so I may have very well dropped .6W and am just not be able to see the difference.
 
Endgame said:
I re-enabled dtoverlay=vc4-fkms-v3d across my 15 Pi 4s, and saw no difference one way or another. Unfortunately, my UPS only reads in whole watts, so I may have very well dropped .6W and am just not be able to see the difference.
Click to expand...
Yes, this is such a small value that it may very well be just a fluke. It'd be in the order of 0.005A... I'll go back to those oddities once I'm done with the bread and butter stuff. I'd like to finish the tweaks, apply the good ones, and then overclock the device up to the level of the default/original power consumption. It will sort of give a really nice picture of how much was actually gained.
However, I was surprised to see that uhubctl seems to power down the USB ports (both 2 and 3), but there's no change in power. The author of this tool mentioned in some thread that building it from scratch should actually power them down. There is however a ready-made version in the repo.
So, basically, how do we shut USB down is what I'm asking :p ? Do you happen to know?
 
michalrz said:
Yes, this is such a small value that it may very well be just a fluke. It'd be in the order of 0.005A... I'll go back to those oddities once I'm done with the bread and butter stuff. I'd like to finish the tweaks, apply the good ones, and then overclock the device up to the level of the default/original power consumption. It will sort of give a really nice picture of how much was actually gained.
However, I was surprised to see that uhubctl seems to power down the USB ports (both 2 and 3), but there's no change in power. The author of this tool mentioned in some thread that building it from scratch should actually power them down. There is however a ready-made version in the repo.
So, basically, how do we shut USB down is what I'm asking :p ? Do you happen to know?
Click to expand...
I had a discussion in several threads on the raspberry pi forums regarding this. I don't have time to reread the threads, but I think this one would be most interesting to you:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=257144

Basically, the USB is wired differently for the pi 4 than the pi3, so disabling it doesn't have the same effect.

Edit from that thread, maybe try:
echo 1 >/sys/bus/pci/devices/0000\:01\:00.0/remove

Sounds like that didn't have any effect either...

Edit to add this thread, which is where I picked up some of the tweaks to reduce the footprint of raspbian lite:

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=281330&p=1735157#p1735157
 
Last edited:
Well, we're down 170mA (~0.85W, without losing computation performance) in total so far, which is pretty respectable :)
Any other tweaks we need to check? Or can I start the voltage&clocks part?
 
michalrz said:
Well, we're down 170mA (~0.85W, without losing computation performance) in total so far, which is pretty respectable :)
Any other tweaks we need to check? Or can I start the voltage&clocks part?
Click to expand...
I’ve got nothing else tweak wise. There may be other things, but I don’t know what they are
 
Endgame said:
I’ve got nothing else tweak wise. There may be other things, but I don’t know what they are
Click to expand...
I'll browse for some more after I get some idea about volts and clocks :)
Lsusb shows no other system hardware on the USB bus, and I know which chip is the controller, so... :D
 
for cpu volts, as mentioned earlier in the thread, you can use over volt -2 and still get 1525mhz out of every pi I’ve tried (15/15). Most pis will start locking up at 1535, though I’ve got one that will do 1560.

I’ve read changing gpu clock / voltage can have system wise effects, but a bunch of those notes are for the pi3. Might want to make sure you can benchmark to be safe.
 
michalrz said:
Well, we're down 170mA (~0.85W, without losing computation performance) in total so far, which is pretty respectable :)
Any other tweaks we need to check? Or can I start the voltage&clocks part?
Click to expand...
One thing worth checking, but would probably be annoying, is testing without a sd card. This would likely require network booting the pi to keep variables as small as possible, and getting network boot to work isn’t something you knock out in an hour. However, if it’s in your plan at some point, if love to see if it makes any difference.
 
Endgame said:
One thing worth checking, but would probably be annoying, is testing without a sd card. This would likely require network booting the pi to keep variables as small as possible, and getting network boot to work isn’t something you knock out in an hour. However, if it’s in your plan at some point, if love to see if it makes any difference.
Click to expand...
To tell you the truth, I've gotten a bit intimidated by the whole energy management scheme of the Pi4.
Even the h.265 block has its own independent setting...

For now, I only tried overvolt=-2 in config.txt, which yielded a 0.01A drop. Oddly enough, overvolt=-3 gives the same voltage (0.8350V) as -2, so I don't know what's up with that. I'll see how low I can go. And indeed, looking at this article: https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md kind of implies that some changes might manifest in a weird way.

As for the SD card... I never used PXE, but sounds like it could be more trouble than its worth, because you still need something else to act as the boot server? Follow-up question - where does the data go in this case? Is stuff saved in RAM (like with log2ram) and synced to a remote share somewhere periodically? Or is it using the boot server as storage?
 
michalrz said:
To tell you the truth, I've gotten a bit intimidated by the whole energy management scheme of the Pi4.
Even the h.265 block has its own independent setting...
Click to expand...
There are also settings that work on different versions of pis and some have no effect on the pi 4. I think you are at the same point that I got bogged down, and asking for help on the Raspberry Pi forums didn’t yield much for me. I think getting a pi engineer to reply is the best way to make more progress, I just don’t know how to get one to reply.

what might be best is to just create a list of things you think might help that we haven’t already tried. I can try to run some down with you. Might also be time to email / contact a few other sources from some pi enthusiast sites and see if we can make more progress.
michalrz said:
For now, I only tried overvolt=-2 in config.txt, which yielded a 0.01A drop. Oddly enough, overvolt=-3 gives the same voltage (0.8350V) as -2, so I don't know what's up with that. I'll see how low I can go. And indeed, looking at this article: https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md kind of implies that some changes might manifest in a weird way.
Click to expand...
Over volt -2 seems to be as low as it goes on the 4. I tried extensively to go lower, and that was it. I may have left a few comments in this thread to that effect.
michalrz said:
As for the SD card... I never used PXE, but sounds like it could be more trouble than its worth, because you still need something else to act as the boot server? Follow-up question - where does the data go in this case? Is stuff saved in RAM (like with log2ram) and synced to a remote share somewhere periodically? Or is it using the boot server as storage?
Click to expand...
Yes, you need a boot server to answer the PXE request, assign it an IP, and serve up the OS files. You also have to modify the boot loader in the pi to do it, and configure a few other things. Storage for the pi would be handled by iscsi across the network, but since most of the OS is loaded in Ram, there isn’t a ton of network overhead.

The pros of network boot would be lower cost per pi, and potentially lower power usage.

All that said, I have not found a great guide on setting up the whole PXE infrastructure that actually works, and I just don’t have time to dedicate to working on it uninterrupted.
 
Endgame said:
There are also settings that work on different versions of pis and some have no effect on the pi 4. I think you are at the same point that I got bogged down, and asking for help on the Raspberry Pi forums didn’t yield much for me. I think getting a pi engineer to reply is the best way to make more progress, I just don’t know how to get one to reply.

what might be best is to just create a list of things you think might help that we haven’t already tried. I can try to run some down with you. Might also be time to email / contact a few other sources from some pi enthusiast sites and see if we can make more progress.
Click to expand...
Well, I had some time today! So, I tried adding these 4 settings:
h264_freq_min and h264_freq
isp_freq_min and isp_freq
v3d_freq_min and v3d_freq
hevc_freq_min and hevc_freq
And heeded Raspberry's advice on leaving core_freq alone

Initially, the result was - no change.

BUT! Next, I activated dynamic voltage frequency scaling by adding dvfs=1 (default is NO scaling apparently? weird?)
That alone consistently shaved 0.01A on idle.
BUT BUT! When dvfs is 1, and you set one of the above freq values, the power goes back up by that 0.01A. It however DOESN'T go back up when you set the freq_min values.

Weird, right? Have you tried this dvfs thing?
 
michalrz said:
Well, I had some time today! So, I tried adding these 4 settings:
h264_freq_min and h264_freq
isp_freq_min and isp_freq
v3d_freq_min and v3d_freq
hevc_freq_min and hevc_freq
And heeded Raspberry's advice on leaving core_freq alone

Initially, the result was - no change.

BUT! Next, I activated dynamic voltage frequency scaling by adding dvfs=1 (default is NO scaling apparently? weird?)
That alone consistently shaved 0.01A on idle.
BUT BUT! When dvfs is 1, and you set one of the above freq values, the power goes back up by that 0.01A. It however DOESN'T go back up when you set the freq_min values.

Weird, right? Have you tried this dvfs thing?
Click to expand...
I haven’t. Do you see the power drop with tvservice off?
 
Endgame said:
I haven’t. Do you see the power drop with tvservice off?
Click to expand...
Yes, it's included in the list of tweaks in my big post. 0.02A IIRC.
I add stuff there as I go.
I applied all the 'good' tweaks just now, seeing some pretty crazy power savings, to the tune of 0.72W less consumption (during WCG Einstein!)
I'll leave the PI to fold for a few days, to make sure none of the tweaks caused the performance to drop (I have baseline numbers).
 
michalrz said:
Yes, it's included in the list of tweaks in my big post. 0.02A IIRC.
I add stuff there as I go.
I applied all the 'good' tweaks just now, seeing some pretty crazy power savings, to the tune of 0.72W less consumption (during WCG Einstein!)
I'll leave the PI to fold for a few days, to make sure none of the tweaks caused the performance to drop (I have baseline numbers).
Click to expand...
Very nice. This is what I see on my newest 4 gb pi 4 for frequency:


arm: frequency(48)=1525341824
core: frequency(1)=500000992
H264: frequency(0)=0
isp: frequency(45)=0
v3d: frequency(46)=500000992
uart: frequency(22)=48001464
pwm: frequency(25)=0
pixel: frequency(29)=75001464
vec: frequency(10)=0
hdmi: frequency(0)=0
dpi: frequency(4)=0

If I can find a way to turn off or downlocak v3d, pixel, and uart, we might be able to save even more power. More posting soon...
 
uart can be removed by adding this to /boot/config.txt:

enable_uart=0

It seems to have no effect - clock speed is still appx 48mhz.

The following does work, though I don't know if there is any effect on power utilization:

dvfs=1
v3d_freq=360
v3d_freq_min=250

edit:

min frequency seems to be 250. I tried setting it to 50 and it still came up as 250.
 
Last edited:
Endgame said:
uart can be removed by adding this to /boot/config.txt:

enable_uart=0

It seems to have no effect - clock speed is still appx 48mhz.

The following does work, though I don't know if there is any effect on power utilization:

dvfs=1
v3d_freq=360
v3d_freq_min=250

edit:

min frequency seems to be 250. I tried setting it to 50 and it still came up as 250.
Click to expand...
I tried 200, but was missing a way to see it 'stuck' (it did not yield a clear difference in power).
Could you hand me that command/script you use to dump all the frequencies in one go like that?
 
michalrz said:
I tried 200, but was missing a way to see it 'stuck' (it did not yield a clear difference in power).
Could you hand me that command/script you use to dump all the frequencies in one go like that?
Click to expand...
I wrote a little bash script. It will run every 30 seconds and output to stdout:


#!/bin/bash
maxtemp=0
while true; do
date
vcgencmd measure_temp
vcgencmd measure_volts core
vcgencmd get_throttled
echo -n "arm: "; vcgencmd measure_clock arm
echo -n "core: "; vcgencmd measure_clock core
echo -n "H264: "; vcgencmd measure_clock H264
echo -n "isp: "; vcgencmd measure_clock isp
echo -n "v3d: "; vcgencmd measure_clock v3d
echo -n "uart: "; vcgencmd measure_clock uart
echo -n "pwm: "; vcgencmd measure_clock pwm
echo -n "pixel: "; vcgencmd measure_clock pixel
echo -n "vec: "; vcgencmd measure_clock vec
echo -n "hdmi: "; vcgencmd measure_clock hdmi
echo -n "dpi: "; vcgencmd measure_clock dpi
temp=`/opt/vc/bin/vcgencmd measure_temp | awk -F "=" '{print $2}' | awk -F "'" '{print int ( $1 )}'`
if [ $temp -gt $maxtemp ]; then
maxtemp=$temp
fi
echo "Max temp: $maxtemp"
echo
sleep 30
done
 
michalrz said:
Well, we're down 170mA (~0.85W, without losing computation performance) in total so far, which is pretty respectable :)
Any other tweaks we need to check? Or can I start the voltage&clocks part?
Click to expand...
I’ve had several suggestions to try removing the USB driver to see if it reduces usb power. Apparently it worked for the pi3 to reduce power, and there have been mixed reports on the 4. The command is:

echo 1 >/sys/bus/pci/devices/0000\:01\:00.0/remove

I don’t have great hope of this making a difference, but it should be easy to test if you’ve got a moment.

Edit: across 15 pis all at full load, my power usage went up 1W with this tweak, so I'm going to guess it makes things worse.
 
Last edited:
Endgame said:
uart can be removed by adding this to /boot/config.txt:

enable_uart=0

It seems to have no effect - clock speed is still appx 48mhz.

The following does work, though I don't know if there is any effect on power utilization:

dvfs=1
v3d_freq=360
v3d_freq_min=250

edit:

min frequency seems to be 250. I tried setting it to 50 and it still came up as 250.
Click to expand...
Applying the above dvfs value while lowering v3d_freq to my full stack of pis shaved off 1w, give or take .9w (UPS only reads in whole numbers, as stated before).
 
Endgame said:
Applying the above dvfs value while lowering v3d_freq to my full stack of pis shaved off 1w, give or take .9w (UPS only reads in whole numbers, as stated before).
Click to expand...
Ha!
I'll try that tomorrow if I have the time. I need to plug the PI to my measuring setup.
Also:
Code: 
pi@littlepigboy:~ $ sudo echo 1> /sys/bus/pci/devices/0000\:01\:00.0/remove
-bash: /sys/bus/pci/devices/0000:01:00.0/remove: Permission denied
pi@littlepigboy:~ $ sudo su
root@littlepigboy:/home/pi# whoami
root
root@littlepigboy:/home/pi# echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
root@littlepigboy:/home/pi# uhubctl
No compatible smart hubs detected!

Curious to see if it finally killed that pesky USB controller, lol.

Edit: also temps... they are NICE.
 
Last edited:
michalrz said:
Ha!
I'll try that tomorrow if I have the time. I need to plug the PI to my measuring setup.
Also:
Code: 
pi@littlepigboy:~ $ sudo echo 1> /sys/bus/pci/devices/0000\:01\:00.0/remove
-bash: /sys/bus/pci/devices/0000:01:00.0/remove: Permission denied
pi@littlepigboy:~ $ sudo su
root@littlepigboy:/home/pi# whoami
root
root@littlepigboy:/home/pi# echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
root@littlepigboy:/home/pi# uhubctl
No compatible smart hubs detected!

Curious to see if it finally killed that pesky USB controller, lol.

Edit: also temps... they are NICE.
Click to expand...
One poster on the pi forums implied that removing the driver also removed the power management and the usb hub defaults to power on (unlike the pi 3 where removing the driver defaults the hub to power off).

difficult to say who is right.
 
Endgame said:
One poster on the pi forums implied that removing the driver also removed the power management and the usb hub defaults to power on (unlike the pi 3 where removing the driver defaults the hub to power off).

difficult to say who is right.
Click to expand...
Nada.
The echo 1> (...)remove yields nothing.
Lowering both sets of frequencies (freq and freq_min) left me with these clocks:
Code: 
arm: frequency(48)=600117184
core: frequency(1)=199995120
H264: frequency(0)=0
isp: frequency(45)=0
v3d: frequency(46)=199995120
uart: frequency(22)=48001464
pwm: frequency(25)=0
pixel: frequency(29)=75001464
vec: frequency(10)=0
hdmi: frequency(0)=0
dpi: frequency(4)=0
(IDLE)
Code: 
arm: frequency(48)=1500345728
core: frequency(1)=500000992
H264: frequency(0)=0
isp: frequency(45)=0
v3d: frequency(46)=200008304
uart: frequency(22)=48001464
pwm: frequency(25)=0
pixel: frequency(29)=75001464
vec: frequency(10)=0
hdmi: frequency(0)=0
dpi: frequency(4)=0
(Einstein@home)
No (observable) reduction in power consumption.
 

Attachments

  • WP_20210604_10_33_01_Pro.jpg
    WP_20210604_10_33_01_Pro.jpg
    224.7 KB · Views: 0
I think I found some more weirdness with over_voltage and dvfs - they don't do much on idle, but they do on full tilt. Will update.
 
michalrz said:
I think I found some more weirdness with over_voltage and dvfs - they don't do much on idle, but they do on full tilt. Will update.
Click to expand...
I'm not terribly surprised that you don't see much on idle. The Pi already powers down when idle, so it might even hit the lowest over_voltage state possible. However, when the clock goes up, the negative over_voltage will limit the max voltage drawn.

I see you're trying over_voltage=-4. Does that work for you? What I've seen is that volt=0.8350V is the lowest it will go, which is set by over_voltage=-2.
 
Endgame said:
I'm not terribly surprised that you don't see much on idle. The Pi already powers down when idle, so it might even hit the lowest over_voltage state possible. However, when the clock goes up, the negative over_voltage will limit the max voltage drawn.

I see you're trying over_voltage=-4. Does that work for you? What I've seen is that volt=0.8350V is the lowest it will go, which is set by over_voltage=-2.
Click to expand...
Well, the weirdness I saw was that dvfs doesn't really makes a difference when loading with einstein@home. Both with over_voltage set and uncommented.
It's actually the over_voltage statement that dropped the power consumption by 0.02A.
The difference between over_voltage=-2 and -4 is basically within the margin of error, heck, -2 "seems" to give a better result more consistently.

So, for now I'll just add the over_voltage @load number to my list, but the truth is that I need to re-check volts/frequencies related settings with a more consistent load, like a cpu benchmark. Right now I have sysbench handy, so I'll look for a nice routine for it that'll make the Pi suffer.

I mean, what I don't like with using Einstein right now is that the 0.78/0.80A number is an average (60 second intervals). Also I'm disregarding peaks, and these actually reach 1A and change with a 5W pull.

Oh, and remembered - I'll try to force a throttled state, as this value can apparently be altered from 60 deg to less. Would be cool to put it into a throttled state on the fly when it's idling.
 
Last edited:
michalrz said:
Well, the weirdness I saw was that dvfs doesn't really makes a difference when loading with einstein@home. Both with over_voltage set and uncommented.
It's actually the over_voltage statement that dropped the power consumption by 0.02A.
The difference between over_voltage=-2 and -4 is basically within the margin of error, heck, -2 "seems" to give a better result more consistently.
Click to expand...
Note that you can read the core voltage directly from the shell script I provided above. The command is:

vcgencmd measure_volts core

It's how I know where negative over_voltage stopped changing things, as it doesn't go below 0.8350V.
michalrz said:
So, for now I'll just add the over_voltage @load number to my list, but the truth is that I need to re-check volts/frequencies related settings with a more consistent load, like a cpu benchmark. Right now I have sysbench handy, so I'll look for a nice routine for it that'll make the Pi suffer.

I mean, what I don't like with using Einstein right now is that the 0.78/0.80A number is an average (60 second intervals). Also I'm disregarding peaks, and these actually reach 1A and change with a 5W pull.
Click to expand...
At least Einstein is more consistent than Rosetta, which is what is running when I'm measuring power. Switching to sysbench or cpu burn (or both) would definitely be more consistent and better for getting reliable numbers..
michalrz said:
Oh, and remembered - I'll try to force a throttled state, as this value can apparently be altered from 60 deg to less. Would be cool to put it into a throttled state on the fly when it's idling.
Click to expand...
What is an idle pi? I'm not sure I understand the concept :D

Quick edit.
I was just referred here for another question:
https://elinux.org/The_Undocumented_Pi#Clocks

Looks like some real reading could be done there, but I'm not sure if anything interesting would get turned up. I might try to read through it later, but if anyone else reading along, let us know if you find something interesting.
 
Endgame said:
Note that you can read the core voltage directly from the shell script I provided above. The command is:

vcgencmd measure_volts core

It's how I know where negative over_voltage stopped changing things, as it doesn't go below 0.8350V.

At least Einstein is more consistent than Rosetta, which is what is running when I'm measuring power. Switching to sysbench or cpu burn (or both) would definitely be more consistent and better for getting reliable numbers..

What is an idle pi? I'm not sure I understand the concept :D

Quick edit.
I was just referred here for another question:
https://elinux.org/The_Undocumented_Pi#Clocks

Looks like some real reading could be done there, but I'm not sure if anything interesting would get turned up. I might try to read through it later, but if anyone else reading along, let us know if you find something interesting.
Click to expand...
Oh your script is getting plenty of use! I use it to quickly check for throttling or frequency anomalies.
My reasoning for lowering the over_voltage setting was mostly to make sure something else isn't being affected, and that -2 is indeed the best we've got at this time.
Haha, yeah, no reason to idle that thing. I have setup a LAMP stack on mine along with folding, it's already collecting a minute-by-minute database of my experimental solar array's production. It's a great addition for various little microcontrollers like the ESP32 that would otherwise need a microSD slot and sqlite running on them.
That clocks wiki is way beyond my skills... I'll stick to sysbench though, we'll see if it shows something new.
 
michalrz said:
Oh your script is getting plenty of use! I use it to quickly check for throttling or frequency anomalies.
My reasoning for lowering the over_voltage setting was mostly to make sure something else isn't being affected, and that -2 is indeed the best we've got at this time.
Haha, yeah, no reason to idle that thing. I have setup a LAMP stack on mine along with folding, it's already collecting a minute-by-minute database of my experimental solar array's production. It's a great addition for various little microcontrollers like the ESP32 that would otherwise need a microSD slot and sqlite running on them.
That clocks wiki is way beyond my skills... I'll stick to sysbench though, we'll see if it shows something new.
Click to expand...
I read through the whole clocks wiki - nothing there power wise I haven’t already implemented or tried.

the next biggest area of improvement would likely be power efficiency on the power supply. These cell phone chargers seem to be 80% or less efficient. Need to find a 90+ Titanium rated pi power supply :D
 
JSHamlet234 said:
The GPU in my Pi 4 overclocks like crazy if I pump in the voltage. I had the GPU core at over 900MHz with something like 1.05 or 1.1v - can't remember. It was overvoltage level 10-ish. The only problem is that the same voltage feeds the CPU cores and it overheats the VRM in seconds if I try to run something CPU intensive. I was trying to get Quake 3 Arena running the way I like it. That might asking too much.
Click to expand...
Just skimming the results thread and realized I never replied to this.
You likely need a decent heat sink, or good airflow if your pushing the OC. I like the FLIRC heatsink cases if you’re only pushing the CPU, but since they only have contact with the CPU they probably wouldn’t be great for things that push the whole system. Villaros has some interesting heatsink cases that might work better.
 
Well, looks like I'll be ending the experiment for now.
I've relegated the PI to a LAMP server role for my DIY IoT stuff, and I ordered two HDD docking stations - will be retiring my C2D file server in favor of just placing the drives in said stations and using the Pi for Samba.
Obviously it'll be crunching Einstein@home as well :D

I do have microcontrollers and one more INA219 sensor, so I can get back to this whenever I get my hands on another Pi. I'm kind of thinking of getting a few CM4s come Autumn.

However I can do some quick test tomorrow before the stuff arrives, so lemme know if there's something pressing.
 
Last edited:
michalrz said:
Well, looks like I'll be ending the experiment for now.
I've relegated the PI to a LAMP server role for my DIY IoT stuff, and I ordered two HDD docking stations - will be retiring my C2D file server in favor of just placing the drives in said stations and using the Pi for Samba.
Obviously it'll be crunching Einstein@home as well :D

I do have microcontrollers and one more INA219 sensor, so I can get back to this whenever I get my hands on another Pi. I'm kind of thinking of getting a few CM4s come Autumn.

However I can do some quick test tomorrow before the stuff arrives, so lemme know if there's something pressing.
Click to expand...
I think there is only 2 tests left to be done.

1) Confirm that:
2.5 Commenting out dtoverlay=vc4-fkms-v3d in /boot/config.txt
Is indeed worse during load conditions

2) Test if just
echo 1 | sudo tee /sys/bus/pci/devices/0000\:01\:00.0/remove
has any effect on power (don't bother with uhubctl). Even if it doesn't change power I think it slightly reduces memory footprint (which should be confirmed on an idle pi using free, instead of an in use pi like I just tried).
 
Endgame said:
I think there is only 2 tests left to be done.

1) Confirm that:
2.5 Commenting out dtoverlay=vc4-fkms-v3d in /boot/config.txt
Is indeed worse during load conditions

2) Test if just
echo 1 | sudo tee /sys/bus/pci/devices/0000\:01\:00.0/remove
has any effect on power (don't bother with uhubctl). Even if it doesn't change power I think it slightly reduces memory footprint (which should be confirmed on an idle pi using free, instead of an in use pi like I just tried).
Click to expand...
Will do and will report back :)
 
I'm having a bit of an embarrassing problem.
I can't do the thing because I misplaced my little OLED screen that I need for this. Ironically enough it disappeared after a tidying up session.
I'm not disassembling the rest of the setup though, so once I find it I'll do it.
 
Okay, I took to catching the numbers via a serial connection. Up-side is a few extra digits after the comma.
The results are in!
1. "echo 1 | sudo tee /sys/bus/pci/devices/0000\:01\:00.0/remove" - does nothing to power.
2. Commenting out vc4-fkms-v3d
14:25:36.674 -> avg bus V: 4.97
14:25:36.674 -> avg current mA: 959.26
14:25:36.674 -> avg power mW: 4765.73
14:25:36.674 -> avg load V: 5.06
Leaving it as is:
14:28:37.360 -> avg bus V: 4.97
14:28:37.360 -> avg current mA: 920.89
14:28:37.360 -> avg power mW: 4576.60
14:28:37.360 -> avg load V: 5.07

This is a 60 second average while loaded with 4 einstein@home tasks.

Same thing with idle numbers.
So, yes, it is indeed an anomaly but I'm 100% the result is correct.
I went back and forth a bunch of times.
Maybe it's a bug in the system, inverted logic somewhere or a driver/HW thing. But it is how it is.
 
You must log in or register to reply here.
Back
Top