Slowness due to game amount?

[qohelet]

I am playing right now the SNES rom "The Adventures Of Hourai High (English Translation)" on my RP2 and have so far used mostly the default-settings. Until now I have never really noticed any significant lagging of music or gameplay (an exception was in "Super Metroid" when I was using power bombs and destroyed some walls during movement and rising lava... But this action might even cause slowness on an original SNES, also it gave everything a cool dramatic effect).

I'm planning a long stay abroad and put a huge amount of old games on my RetroPie two nights ago and wanted to play TAOHH again. Even though this game is not using any significant graphics or effects I recognized some strange slow-downs in sound and gameplay (for any one who knows the game: It happened in the sewers in the stolen-question-quest).

After reading through some forums I changed the power cable. I was using an original Samsung-Charger (for the galaxy) and changed to an old Nokia-Charger. Sometimes I'm using a Huawei-Charger. (Whatever is easiest to find). The Nokia-Charger dropped the s lownesses significantly, yet I wonder if there is a chance the slowness was not induced by the charger but by the amount of games (I have them on the SD-Card, not an an external drive; using a "SanDisk Ultra Android microSDHC 32GB, Class 10").

Now there are only 2-3Gb left free on the card.

Thank you

[dankcushions]

If the slowness was caused by game amount, how would the power supply upgrade have sped it up? :)

I think game amount is only likely to slow down emulationstation load time. if you wanted you could find out how much memory you have left using the 'top' command on an SSH terminal whilst the game is running.

[qohelet]

As stated in the beginning so far I never had issues before and switched between the three power cables - the last session of TAOHH was the first time I had this slowness.

I'm not so much worried about the free space, more whether the indexing of the games consumes permanent processing power or only during the specific load of certain parts.

[zerojay]

No, nothing like that is going on. Try a different SNES emulator and see if you have the same speed issues.

[qohelet]

@zerojay - ok, that's all I wanted to know. I couldn't find any related posts on the internet so far. Is it actually true games should rather be loaded from external drives rather than the micro-sd-card used by the system...?

[zerojay]

It should not matter where they are loaded from as SNES games are small enough to all load fully into RAM anyways.

You know, I am kind of noticing that lr-SNES9x-Next does appear to be running sluggishly even with just Super Mario All-Stars struggling to hit 60fps in-game now. That's pretty odd. Also noticing that when I'm in emulationstation, the game lists render at only 45-50fps with the pixel theme (system lists stay at 60fps without issue). Selecting a game appears to have a far choppier zoom-in as well, where it is really noticed. This is with a pi 2 overclocked to 1067mhz, so this should not be happening. Hmm. Maybe general performance issues here? I did not have these problems under wheezy. And this is with a brand new install with Jessie on a brand new SD card.

[qohelet]

What is the relation between where they are located and if they fit into the RAM? If it wouldn't do so I might think it would be even better to have it on the local disc rather than a USB-Device?

What is actually the default emulator? As said, I haven't done much configuration but since yesterday I think of using the snes9x-rpi. Today I'll have the framerate activated and test with different cables. So far the listing of the games never caused any problems at all. As most linux-based systems don't index their file system constantly I wondered how it worked so smooth.

Which OS do you actually use? The RetroPie SD-card image itself?

[zerojay]

There's something wrong here. SNES is pegging 100% usage on every SNES game making it unplayable with lr-snes9x-next. Attempting to use lr-pocketsnes results in no input functioning at all aside from Retroarch hotkeys. This is with the Retropie SD card image.

[qohelet]

What do you mean by

SNES is pegging 100% usage on every SNES game

You mean CPU or RAM? And how do you display that?

[zerojay]

CPU. Retroarch's Display Framerate option under Video.

Others are noticing this issue as well: https://www.reddit.com/r/RetroPie/comments/44vxrb/some_snes_games_are_somewhat_slower/

The audio during Super Metroid's intro is juttery too and a very telling sign that something's not right.

Running cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq to see what speed the CPU is set to and it appears that the overclocking isn't taking. My 1067mhz overclock is actually running at 600mhz, which makes sense given the performance issues here.

[zerojay]

I think I have a fix. The scaling govenor is set to "powersave" by default which is causing the overclock to be ignored.

[zerojay]

To fix it temporarily when running games, go to RetroPie -> Retropie-config --> Setup / Configuration -> Configure the runcommand -> CPU Configuration -> Force ondemand.

You could also fix this for everything in the meantime by adding the following to /etc/rc.local: echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo ondemand > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo ondemand > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

I believe the real fix here is recompiling the Jessie kernel so that ondemand is the default scaling governor.

(And do not get tempted to set "force performance" unless you want your Pi to run at full overclock at ALL TIMES which will mean a lot more heat, etc...)

[qohelet]

Can you display CPU/RAM usage too somehow too?

[zerojay]

Log in through SSH and use the standard Linux tools such as top and ps.

[zerojay]

Jessie is apparently set up so that it should boot to ondemand by default and if you hold down the shift key during boot, it should use powersave, meant to save you if you have bad overclock settings to ignore. This is apparently not working for everyone and appears that others on Jessie are having the same issues such as the Pi Zero, where the kernel is booting to powersave by default.

Actually, it seems like even setting the governor in rc.local isn't taking but the runcommand setting is still working.

[dankcushions]

So this is a jessie issue rather than a retropie one? If, is there a issue for it logged against the raspian github? Had a search and couldn't find one.

[zerojay]

I believe it is but can't say for sure as I don't know if there's a custom kernel in use or what. I'll let Jools chime in with his opinion on it, but I believe it's an issue caused by a change upstream.

Potentially relevant post: https://www.raspberrypi.org/forums/viewtopic.php?t=129725&p=867259

With the governor set to ondemand for all CPUs manually, the menus in emulationstation are back to running 60fps, the zooming is smooth again, etc...

This thread may also explain why my attempts to set the governor in rc.local do not appear to be working: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=133976&p=899595&hilit=powersave#p899595

EDIT: Actually, I hadn't realized I had added the commands for setting the governor after the "exit 0" line. Add them in before it and it'll take on boot everytime without issue.

[joolswills]

Can't reproduce

I tested the v3.5 image (4.1.13-v7+) - ondemand is the governor once booted -

I did apt-get update; apt-get upgrade and it installed 4.17 which also was set to ondemand

[joolswills]

I'm not sure everyone is talking about the same thing here - there is no confirmation that the OP has an issue with the governor is there ? Could even be a PSU issue if he is using phone chargers

[zerojay]

I'm using a clean 3.5 image with 4.1.13-v7+ with a new sd card and it's defaulting to powersave for me. I'll try to update and see what it gives me.

[joolswills]

on which rpi ?

[joolswills]

Also what is the output of grep raspi-config /var/log/syslog

[joolswills]

and the output of sudo journalctl (via pastebin or so)

[qohelet]

I tried it again. It just seems to depend on the emulator. I really wanted to try the Snes9x but pressing start kills the game (This guy seems to have the same issue: https://www.reddit.com/r/RetroPie/comments/3g7ipq/snes9x_start_button_kills_emulation_and_gba/).

So I kept on trying. lr-armsnes or lr-catsfc worked for me with a decent speed and no issues in colour and sound. The PiSNES had strange sound-issues and wrong colours.

Weird...

[qohelet]

I tried it again. It just seems to depend on the emulator. I really wanted to try the Snes9x but pressing start kills the game (This guy seems to have the same issue: https://www.reddit.com/r/RetroPie/comments/3g7ipq/snes9x_start_button_kills_emulation_and_gba/).

So I kept on trying. lr-armsnes or lr-catsfc worked for me with a decent speed and no issues in colour and sound. The PiSNES had strange sound-issues and wrong colours.

Weird...

[joolswills]

@zerojay I am still interested in the output of the command I mentioned to work out why your system doesn't switch to ondemand. The referenced raspberry pi forum ticket looks to be a problem with the users install.

[joolswills]

@qohelet are you talking about the standalone snes9x emulator (not the libretro core) - that has hardcoded joystick input, so it's possible on your controller the mapping is wrong. I wouldn't use it and stick with one of the libretro cores.

[qohelet]

@joolswills Yeah, exactly! I would actually prefer to use the snes9x-rpi. According to the description it seems to me the snes9x is actually the snes9x-rpi in my RetroPie, but I can't say for sure.

[joolswills]

Why ? It has hardcoded controls, and not as good compatibility as some other emulators.

snes9x is snes9x-rpi - you can see that from retropie-setup

[qohelet]

It's just plain interest. And their GitHub-Page impressed me and I'd like to try. Yet I'm wondering how I can actually access the emulators during the game? Start+X opens the RetroArch-Menu.

[joolswills]

not sure I understand the question sorry.

[qohelet]

Well, with some emus you can create savegames or savestates, use some hex-codes, and so on (See: https://github.com/chep/snes9x-rpi/blob/master/readme.txt ).

But how is it actually possible to access the menu of the emu itself? I know how to access RetroArch from a SNES game but not the the emulator

[joolswills]

I don't think it has a built in menu. check the rpi readme.

[zerojay]

As this bug doesn't really make much sense to keep open anymore, I suggest it be closed.

I'll open a separate bug regarding the cpu governor if needed once I do more poking and prodding to find out what's going on.

[qohelet]

@zerojay - I assume you're right. For me the CPU-governor is fine, I have by default everywhere "ondemand". Yet it would be cool to access the emu-menus somehow

[zerojay]

There are no "emu-menus" to access. The emulator is command-line based.

[tribunal88]

I did an install of RetroPie 3.7 onto a Pi3 in just the last few weeks and had this same issue, but only with lr-snse9x-next. Either way, adding the code to the rc.local fixed it for me as well. Anyone know exactly what's going on here?

[joolswills]

Have you changed anything? - governor should be ondemand by default and is on my system. check /var/log/syslog and output of dmesg

[tribunal88]

Firstly, I followed the directions for converting the image to work with NOOBs, found here.

Beyond that I only made 3 changes to the system which would fall outside the RetroPie GUI. 1) Configured it to use a static IP address. 2) Mount a roms directory from the NAS over top of the local one with an entry in /etc/fstab. 3) Changed the cpu governor for each core to "ondemand" per the instructions above.

[joolswills]

Maybe changing it to work with noobs affected it - the logs might tell you more. It isn't a retropie-setup issue though, and I am unable to reproduce it with our prebuilt image.

[joolswills]

Also what was the governor set to before you changed it to ondemand ? conservative or ?

[tribunal88]

I couldn't say for sure, but my guess is it was on "powersave" as was the case with zerojay. If I get a chance to test later I can set the governors to "conservative" and "ondemand" to see which (or both) reproduce what I was experiencing before.

[joolswills]

Sorry I meant powersave - but setting it to those wont help - I'm trying to find out why your system is starting in the wrong mode and which it is set to. The syslog will help + the output of dmesg perhaps (you can put them on pastebin or similar and I'll take a look)

[joolswills]

by default, the system should start in powersave, but switch to ondemand via a init script - this is unrelated to RetroPie but is done by Raspbian (I can't remember if this happens initially, or this is configured after overclocking via raspi-config). I assume something is wrong in your setup so it is staying in powersave mode.

[tribunal88]

Could be. I booted the Pi into Openelec last night after testing the RetroPie fix. Out of curiosity I checked it this morning and, still running Openelec, all the processors were in "ondemand" mode, though they had a current frequency of "600000". That would lend support to it being Raspien-related since Openelec appears to be setting it appropriately.

I'll try to get you the outputs you're wanting. Do you know which init script handles switching the governor? I can take a look at that as well.

[joolswills]

/etc/init.d/raspi-config

[tribunal88]

Firstly, there is nothing in /var/log/dmesg. I did check the syslog and there are a bunch of entries for "Nov 21" at the top, which I'm guessing must be artifacts from initial setup because I didn't install this until end of April. Sure enough the date jumps from "Nov 21" to "Apr 27". However, the only times I see "Checking if shift key is held down: No. Switching to ondemand scaling governor." are from the "Nov 21" section (7 occurrences to be precise). After that no occurrence of "Checking if shift key" are present in the syslog, so my guess is that script is not being run. Could be something got messed up in the systemd config, however one other thing I noticed in the script is that it's only messing around with cpu0, leaving cpu1, cpu2, and cpu3 alone. Shouldn't it be trying to bump all 4 cores?

[joolswills]

dmesg is a command that outputs some information. dmesg >/home/pi/dmesg.log

/var/log/syslog is a logfile

dates might be wrong in the log as there is no RTC on the rpi3 (time is wrong until it has grabbed it from the internet)

regarding messing around with cpu0/1/2/3 - that is correct. on the RPI setting cpu0 will set it for all cores.

[tribunal88]

Should there be an entry in the systemd services (systemctl list-unit-files --no-pager)? Nothing in there jumped out at me?

[joolswills]

It's not a systemd service, but you can trigger raspi-config init.d script manually to see if that sets ondemand correctly.

sudo /etc/init.d/raspi-config start

maybe it is not starting up on boot (if nothing is being logged anymore - clear syslog and see to avoid confusion with dates)

I can't really advise further - if you can reproduce it on a fresh unmodified retropie-setup image then let me know, but I suspect it's due to a change you have made.

[tribunal88]

It's not being executed on boot for sure, but running the script works:

~ $ sudo /etc/init.d/raspi-config start
[ ok ] Starting raspi-config (via systemctl): raspi-config.service.
~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand

Not sure if this might have anything to do with it, but it seems to have stopped performing that script after I added rpcbind to start on boot (through systemd). Rpcbind is needed to make NFS work.

So being the enterprising individual that I am, I decided to hook this into systemd so it will actually register as a "service". Here's how it's done:

1) create a file /lib/systemd/system/raspbi-config.service with the following contents:

[Unit]
Description=raspbi-config CPU governor customization

[Service]
ExecStart=/etc/init.d/raspi-config start
ExecReload=/etc/init.d/raspi-config restart
ExecStop=/etc/init.d/raspi-config stop

[Install]
WantedBy=multi-user.target
Alias=raspbi-config.service

2) run the following command to enable it as a service (it will create a couple symlinks) sudo systemctl enable raspbi-config.service

3) Start the script sudo systemctl start raspbi-config.service

4) Make sure it's working

~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
~ $ systemctl status raspbi-config.service
â raspbi-config.service - raspbi-config CPU governor customization
   Loaded: loaded (/lib/systemd/system/raspbi-config.service; enabled)
   Active: inactive (dead) since Tue 2016-05-10 01:09:53 UTC; 41s ago
  Process: 877 ExecStop=/etc/init.d/raspi-config stop (code=exited, status=0/SUCCESS)
  Process: 864 ExecStart=/etc/init.d/raspi-config start (code=exited, status=0/SUCCESS)
 Main PID: 864 (code=exited, status=0/SUCCESS)

And if you run the systemctl list-unit-files --no-pager command, you'll find it among the services and listed as "enabled". And sure, enough, on boot it's showing back up in the syslog.

May 10 01:09:53 ***** raspi-config[864]: Checking if shift key is held down: No. Switching to ondemand scaling governor.

If anyone else runs into this problem, this is a permanent fix that works within the proper Debian framework and should survive system updates or customizations (if that is what caused the script to stop running to begin with on my setup).