3.7 performance tuning
-
add this to your rc.local to remove random freezing of the pi (short pauses). I find the whole system is far more reliable.
Speed / Perf tuning
echo "deadline" > /sys/block/mmcblk0/queue/scheduler
echo "0" > /sys/block/mmcblk0/queue/rotational
echo "2048" > /sys/block/mmcblk0/queue/nr_requests
echo 3 > /proc/sys/vm/dirty_ratio
echo 200 > /proc/sys/vm/dirty_expire_centisecs
echo 640 > /sys/block/mmcblk0/queue/read_ahead_kbMy overclock (air, no heatsink) on a pi3 is stable using the following in /boot/config.txt
Note that i've overclocked the SD card - at your own risk. you need to get the sdtweak-overlay.dtbdtparam=audio=on
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=256
overscan_scale=1
dwc_otg.speed=1arm_freq=1300
over_voltage=5
gpu_freq=500sdram_freq=500
sdram_schmoo=0x02000020
over_voltage_sdram_p=6
over_voltage_sdram_i=4
over_voltage_sdram_c=4dtoverlay=sdtweak,overclock_50=100
I've also found the retropie xboxdrv painful compared to the linux xboxdrv. In the rc.local i put:
/usr/bin/xboxdrv --trigger-as-button --id 0 --led 2 --deadzone 4000 --silent &
sleep 1
/usr/bin/xboxdrv --trigger-as-button --id 1 --led 3 --deadzone 4000 --silent &
sleep 1
/usr/bin/xboxdrv --trigger-as-button --id 2 --led 4 --deadzone 4000 --silent &
sleep 1
/usr/bin/xboxdrv --trigger-as-button --id 3 --led 5 --deadzone 4000 --silent &and that only detects on boot but works seamlessly with super mario war, etc.
my controller configs for retroarch:
#XBOX 360 Config
input_enable_hotkey_btn = "9"
input_exit_emulator_btn = "8"
input_save_state_btn = "4"
input_load_state_btn = "5"
input_shader_next = "11"
input_shader_prev = "12"#Enable analog to dpad mapping by default, disabled in N64 & PSX
input_player1_analog_dpad_mode = "1"
input_player2_analog_dpad_mode = "1"
input_player3_analog_dpad_mode = "1"
input_player4_analog_dpad_mode = "1"
input_player5_analog_dpad_mode = "1"
input_player6_analog_dpad_mode = "1"
input_player7_analog_dpad_mode = "1"
input_player8_analog_dpad_mode = "1"#XBOX Controller #1
input_player1_joypad_index = "0"
input_player1_b_btn = "0"
input_player1_y_btn = "2"
input_player1_select_btn = "8"
input_player1_start_btn = "9"
input_player1_up_btn = "h0up"
input_player1_down_btn = "h0down"
input_player1_left_btn = "h0left"
input_player1_right_btn = "h0right"
input_player1_a_btn = "1"
input_player1_x_btn = "3"
input_player1_l_btn = "6"
input_player1_r_btn = "7"
input_player1_l2_btn = "4"
input_player1_r2_btn = "5"
input_player1_l3_btn = "11"
input_player1_r3_btn = "12"
input_player1_l_x_plus_axis = "+0"
input_player1_l_x_minus_axis = "-0"
input_player1_l_y_plus_axis = "+1"
input_player1_l_y_minus_axis = "-1"
input_player1_r_x_plus_axis = "+2"
input_player1_r_x_minus_axis = "-2"
input_player1_r_y_plus_axis = "+3"
input_player1_r_y_minus_axis = "-3"#my configs for n64 InputAutoConfig.ini
[Linux: Xbox Gamepad (userspace driver)]
plugged = True
plugin = 2
mouse = False
AnalogDeadzone = 4096,4096
AnalogPeak = 32768,32768
DPad R = "hat(0 Right)"
DPad L = "hat(0 Left)"
DPad D = "hat(0 Down)"
DPad U = "hat(0 Up)"
Start = "button(9)"
Z Trig = "button(6)"
B Button = "button(2)"
A Button = "button(0)"
C Button R = "axis(4+)"
C Button L = "axis(4-)"
C Button D = "axis(3+)"
C Button U = "axis(3-)"
R Trig = "button(7)"
L Trig = "button(4)"
Mempak switch = ""
Rumblepak switch = ""
X Axis = "axis(0-,0+)"
Y Axis = "axis(1-,1+)"Mame- advancedmame. Update the advmame-<version>.rc with the following, duplicate with p1 being p2 for additional controllers.
armedf/input_map[p1_up] joystick_button[0,7]
armedf/input_map[p1_down] joystick_digital[0,1,1,0]
armedf/input_map[p1_left] joystick_digital[0,1,0,1]
armedf/input_map[p1_right] joystick_digital[0,1,0,0]
armedf/input_map[p1_button1] joystick_button[0,0]
armedf/input_map[p1_button2] joystick_button[0,1]
armedf/input_map[p1_button3] joystick_button[0,3]
armedf/input_map[start1] joystick_button[0,9]
armedf/input_map[coin1] joystick_button[0,8]
input_map[p1_up] joystick_digital[0,1,1,1]
input_map[p1_down] joystick_digital[0,1,1,0]
input_map[p1_left] joystick_digital[0,1,0,1]
input_map[p1_right] joystick_digital[0,1,0,0]
input_map[p1_button1] joystick_button[0,0]
input_map[p1_button2] joystick_button[0,1]
input_map[p1_button3] joystick_button[0,2]
input_map[p1_button4] joystick_button[0,3]
input_map[p1_button5] joystick_button[0,6]
input_map[p1_button6] joystick_button[0,7]
input_map[p1_button7] joystick_button[0,4]
input_map[p1_button8] joystick_button[0,5]
input_map[start1] joystick_button[0,9]
input_map[coin1] joystick_button[0,8]Ohh and for random splashscreen i updated the /etc/init.d/asplashscreen to the following - see my reddit post.
https://www.reddit.com/r/RetroPie/comments/4h58mt/random_bootsplash_code/
Hope this helps people
-
@crudster Good Job, awesome!
-
they should add this into retropie 3.8 to make the system more stable
-
the performance part of this is a very aggressive overclock and there's no way it would be appropriate for most pi 3s. most will temperature throttle when doing multicore processing at stock clock speeds. it might just about work for some pi 3s if you only do emulator (single core) tasks, and have a very good PSU.
-
@dankcushions While the overclock makes some difference, the kernel tweaks made (in my opinion) a much larger difference in the overall performance reading/writing the SD card. I regressed my image (difference overclock etc) back to a PI2 using the kernel tweaks above and still found things more reliable and i omitted the SD overclock on the PI 2.
Certainly I'd love people to test and see what works for them and if everyone feels the same, then including the SD tuning params would make sense.
Read posts like this and you'll see the default kernel params are woefully lacking for SD cards.
-
@crudster said in 3.7 performance tuning:
Read posts like this and you'll see the default kernel params are woefully lacking for SD cards.
but what do you anticipate storage read/write speed has to do with emulation performance? apart from (maybe) the PPSSPP, everything is read into memory at game load. maybe by overclocking your SD card you can make games take 1 second rather than 2 seconds to load? :)
for me these overclocking/tweaking threads go too deep too soon, with no real benchmarks to show what tweaks do what, but rather modify everything at once, and then we get people saying their pi crashes, but who knows what's in their configuration...
-
@dankcushions I agree. I won't include any changes like this
-
@crudster can you explain what the first lines of code actually does? Referring to this.
echo "deadline" > /sys/block/mmcblk0/queue/scheduler echo "0" > /sys/block/mmcblk0/queue/rotational echo "2048" > /sys/block/mmcblk0/queue/nr_requests echo 3 > /proc/sys/vm/dirty_ratio echo 200 > /proc/sys/vm/dirty_expire_centisecs echo 640 > /sys/block/mmcblk0/queue/read_ahead_kb -
The whole purpose of these tuning was to remove the frequent annoying pauses the stock 3.7 retropie image was having on an RPI3. Overclocking did not resolve this. I'd be navigating menus and it would just freeze for a few seconds. Using my Linux skills i determined it to be a read/write bottleneck on the SD card (class 10, 128 Kingston - which is a very good SD card). It ended up NOT being the card, but rather the OS parameters.....
These are system commands that control the way that the system reads and writes the sd card. I don't guarantee they are perfect, but they WILL NOT harm your SD card at all. Overclocking the SD card / your PI however may cause problems.
The scheduler is the way that the system chooses when multiple processes want to read or write simultaneously. Different schedulers are better for different things.
The other commands are essentially telling the system to hold data in ram before writing it to disk. This has the benefit of making the system "feel" more responsive when lots of reading/writing occurs. If the SD card is 100% busy writing it allows the process to write to memory then it flushes it back to SD when things calm down.
Finally the read_ahead_kb is how far ahead of a read command the system will go and hold in ram just in case a process needs more. For example, in reading a large rom (say Playstation ISO), the original PSX only had so much ram, so when it needs to read a really large file it just reads a chunk, then gets rid of it and reads more as it progresses. Your computer is no different, however it has the luxury of much more memory. So i have it set at a very conservative 640Kb (just over .5 MB of memory), since this i've actually updated the 640 to 4096 (4MB of ram). You don't want it too big as a small read will cause it to actually read 640kb instead of say the 32kb it wanted. So sometimes you win, other times it is a waste.
-
They also may be detrimental to performance on some cards and for some IO patterns.
Some points
- Such a large read ahead could reduce random IO performance.
- Lowering /proc/sys/vm/dirty_ratio can trigger more data to be written at once - which could cause larger delays.
- /sys/block/mmcblk0/queue/rotational is already set to 0 by default.
- dwc_otg.speed=1 will lower usb/network performance
You might want to use sysctl to manage /proc/sys changes via /etc/sysctl.d/ (you can see the 98-rpi.conf in there which adjusts vm.swappiness already)
-
@BuZz Agree fully. As with anything on the internet, there is no warranty/guarantee. I am just sharing information like any other linux / open source project. Maybe it helps someone, maybe not and maybe someone learns something. I didn't make this post for anything other than to share my findings.
-
This is interesting, but I haven't updated binaries yet after 3.7 came out. I am still running 3.6. Is everyone seeing these "annoying pauses"? In other words, is there concern among the core developers about this?
-
@crudster Agree it's useful to share info - so long as people are aware what they are changing, and that it comes at their own risk in terms of potential sd card corruption, or system instability etc.
Regarding the pausing issue - Only on PPSSPP when data is being written out (most noticeable on slower card). Not in general use. One of my cards (Toshiba) is significantly slower at writing than another one (Sandisk), and takes a long time to do tasks that involve a lot of IO such as upgrading packages.
Note that RetroPie is not an OS. It is a set of code/tools/packages that run on top of Raspbian to allow easy setting up of an emulation environment (And Debian/Ubuntu). Our image has a few customisations in regards to the boot process, but I generally leave things as close possible to the Raspbian Lite image. It's basically just Raspbian with RetroPie installed on top.
-
@crudster said in 3.7 performance tuning:
@BuZz Agree fully. As with anything on the internet, there is no warranty/guarantee. I am just sharing information like any other linux / open source project. Maybe it helps someone, maybe not and maybe someone learns something. I didn't make this post for anything other than to share my findings.
thank you for sharing, I finally am able to enjoy playing space invaders:extreme on the ppsspp, before the tweaks it was an exercise in frustration due to the pauses. of course, it may be different for other setups and cards, but it definitely helped in my case. I all but gave up on the ppsspp till I tried your findings. thanks again.
-
just FYI: a fix has just been made to PPSSPP that means the pausing issue is gone! reinstall from source to get it. @BuZz - worth a rebuild of the binaries i think!
-
will do - after my bbq ;-) thanks for the heads up!
-
I have updated the PPSSPP binaries. (rpi2/3 only). has anyone tested the performance on a rpi1 ? It was little poor when I did, but perhaps I should make it available for rpi1/zero anyway - some stuff may be playable.
-
I cherry-picked the fix into our lr-ppsspp fork so if you re-install that from binary/source it should also run without the pauses (tested working here)
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.