3.7 performance tuning
-
@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.