Speed fix for Pi 5 8GB memory, about 20% faster

Hardware
1

RE: Raspberry pi 5 4GB is faster than the 8GB

:warning:First, disable overclocking :warning: to make sure you do not permanently damage your hardware.

TLDR: From a terminal shell run the following commands

root@zynthianv5://zynthian# sudo rpi-update
root@zynthianv5://zynthian# sudo rpi-eeprom-config -e

Add one of these lines to your eeprom config:

adding this line for pi5:
SDRAM_BANKLOW=1

or this line for pi4:
SDRAM_BANKLOW=3

Finally reboot for the settings to apply

root@zynthianv5://zynthian# sudo reboot

:chart_with_upwards_trend: Results:
I did some investigation before and after using the stream omp memory speed test.

root@zynthianv5://zynthian# wget https://www.cs.virginia.edu/stream/FTP/Code/stream.c
root@zynthianv5://zynthian# gcc -O -fopenmp stream.c -o stream_omp

Before the eeprom config:

root@zynthianv5://zynthian# ./stream_omp

-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:            5384.3     0.031705     0.029716     0.033737
Scale:           6341.1     0.026889     0.025232     0.028271
Add:             5433.2     0.045661     0.044173     0.049767
Triad:           6354.2     0.039838     0.037770     0.041719
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

After the rpi update, eeprom reconfig, and a full reboot…

root@zynthianv5://zynthian# ./stream_omp

-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:            7791.6     0.021560     0.020535     0.022463
Scale:           7777.6     0.021250     0.020572     0.022263
Add:             7365.6     0.034241     0.032584     0.036675
Triad:           7917.9     0.033591     0.030311     0.036343
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------
4 Likes
2

I would recommend disabling overclocking before doing this. I think I burnt out my UART from trying this, and others reported similar findings in the thread you linked.

2 Likes
3

@HER0 , Thanks for the tip. I never run overclocking so it’s not an issue for me but a good caveat for others that might.

4

Finally did this yesterday, pi5 8gb, no overclocking, left it on about 15 hours, so far so good. I was getting a few xruns with the latest version of my main snapshot and so far not a single one since I updated.

Might want to update the OP with the actual lines you add to the eeprom config, for people who find this but don’t click through to the original thread.

adding this line for pi5:
SDRAM_BANKLOW=1

or this line for pi4:
SDRAM_BANKLOW=3

2 Likes
5

Hi @smiths73v3, @LagoonCity and @HER0

Thanks for the efforts towards this Raspi 5 8Gb HW improvement. That is certainly useful, and apparently safe to do.

My only qualm is that the most significant performance bottleneck of the ingenious Pi5 thingy is arguably the limit in CPU power, under the pressure of an intense computational load. Don’t know if in a real-world scenario a higher RAM throughput rate to/from the CPU would actually result in a significantly faster operational speed, but I may be wrong, and this could be certainly measured in a one-to-one comparison set.

Regards :slightly_smiling_face:

6

Overclocking the Pi5 makes no sense at all, because due to clock timing mismatches it will induce additional wait states, which show up extremely under multi-threaded heavy load. The computational speed gain is then outweighed by these wait states and the multi-thread power (that is important for the Zynthian) even decays with overclocking. It has all been discussed before.
NUMA is the only thing that reliably works.
rpi-update will bump the kernel to a .y version, leading to a bouquet of incompatibility problems with the Zynthian software. I’ve tried it and reimaged the Last Stable soon.
You can upgrade the boot eeprom with raspi-config, which is a safe operation. All recent versions contain the NUMA feature by default.
Check the eeprom version with vcgencmd bootloader_version.

PS: To check the frequencies, put this on SSH in one line:
for src in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi ; do echo -e "$src:\t$(vcgencmd measure_clock $src)" ;done

3 Likes
7

In case you really need to overclock your Pi5, I’ve put together a script to be run via SSH. See below. This is an example output:

vcgencmd get_throttled (0x50000)
  under-voltage has occurred since last reboot
  throttling has occurred since last reboot
arm:    frequency(0)=3000032256
core:   frequency(0)=910014016
vcgencmd measure_volts:
     core volt=0.9535V
  sdram_c volt=0.6000V
  sdram_i volt=0.6000V
  sdram_p volt=1.1000V
vcgencmd neasure core current:
  VDD_CORE_A current(7)=4.90257000A
Temperature: temp=47.2'C

vcgencmd get_throttled shows if a power supply is too weak or too unstable to handle the extra power needed for overclocking. In this example, a slight brownout has occurred with starting the NVMe, the screen and with the higher current demand due to overclocking, which is normal in this one case using the official Pi5 power supply, which is obviously crawling on the gums already. Normally there should be 0x0 and no message at all, every time. The message is decoded into human readable text for debug information.
arm_frequency here shows massive CPU overclocking to 3GHz. You may safely disregard the least 5 digits, as the measurement is usually not that accurate, but this overall shows the jitter and spread in the clocks onboard, and it shows the frequency the arm CPU is throttled down to, if that is happening at the time of measurement.
core_frequency shows the clock of the video core, not the CPU as one might think. This should better not be overclocked in the Zynthian context at all, due to heat generation and power drain. A value can go to 1GHz safely, but really better leave that to DVFS governors.
core volt shows the neasured core voltage as a result of the over_voltage_delta setting in config.txt. The usually recommended setting of 50000 is way over the top.
The (for Pi5 still not properly documented) DVFS feature of hte bootloader caps the delta to +50000µV, which prevents the chip from popping up like corn, but this is no way safe, as the next value shows:
VDD_CORE_A current is the most important value of all when it comes to overclocking. This value shall never exceed 5.5A. That is what happens when delta is set unnecessarily high or the arm_freq setting in config.txt is too high for that particular chip. The higher delta, the higher current, the higher Temperature. The regulator has its own overcurrent and overtemperature safeguard, but that is rudimentary only and shall not be triggered continously. A tripping safeguard will result in arm frequency capping and unreliable operation due to brownout. It is not excluded that a race condition or a signal collision may happen, leading to a rapid current and temperature runaway. This is what looks like a “crash” or “halt”, but in reality is an electronic expression of “oh, sh*t”, famous last words!
It is always better to run the Pi5 with the smallest over_voltage_delta possible, or better even leave out the over_voltage_delta from config.txt in order to leave all decisions to the DVFS governors. In case you wat to set it and defeat DVFS partially, a value 0f 12000 or even 11000 can most of the times work very well. You see it is too low, if the Pi5 hangs easily, or if it has poor SD or Wi-Fi performace not connecting reliably.
If the Pi5 continoues to run and Wi-Fi and everything works, then the delta is high enough. Watch the current! If you ever see >5.5A when repeatedly calling the script on SSH during maximum computational load (play many instruments and notes until occasional XRUNs come), then delta is too high. If you then can not get reliable operation, you must lower the arm_freq value closer to 2400, which is the sweet spot anyway.

power_report.sh (1.1 KB)

PS: You may install apt install cpufrequtils and then add to /zynthian/config/zynthian_custom_config.sh the line cpufreq-set -r -g ondemand and reboot. If the file does not exist, find it below: Do not forget to chmod a+x it to make it executable after uploading it.
zynthian_custom_config.sh (39 Bytes)
This sets the cpu governor of all related CPUs to ondemand. You see it in the ever changing arm and core frequencies when calling the power report script. An overclock runs much more stable then. In this case, remove the over_voltage_delta from config.txt to allow DVFS to fully work.

2 Likes