Opinion on overclock settings
Likewise as GoldMan. I searched on amazon for the the PSU when I was upgrading around last christmas from a rpi2 that I had for a couple years and had found nothing of the official power supplies. I didn't know an official power supply existed until a couple months ago on the forums here, I almost denied its existence.
I had increased the over_voltage from 1 to 2 on my configuration and I started to get undervolt warnings again. I guess the power of awareness makes this seem really obvious now, but I have quite a few things plugged in as it is sort of a balance of power. I set it back to over_voltage=1 and it is okay; over_voltage=1 has been enough for both core_freq=600 and arm_freq=1500 on rpi3b+.
@Efriim That is actually very reassuring, there is very little information that I have found that indicates what over-voltage "ought" to be sufficient. What all do you have connected to your pi, besides a commodore 64 printer?
Yes it is something to understand the needed voltage steps as well as the added AVS over voltage. From my note taking:
The "over_voltage_avs=" will be used for arm frequencies in the range of 601-1200; the value assigned to over_voltage_avs is determined initially once at boot and is typically 31250(0.03125V) or 37500(0.0375V); giving the core voltage an amount equal to 1.23125V or 1.2375V respectively and any "over_voltage" is added on to those amounts, while "over_voltage_min" is added onto 1.2V until the AVS ignores it (possibly not exceeding 1.25V min).
The "over_voltage_avs_boost=" will be used for arm frequencies in the range of 1201-1600; the value assigned to the avs_boost is determined initially once at boot and is typically 143750(0.14375V) 150000(0.15V); giving the core voltage an amount equal to 1.34375V or 1.35V.
The determinants for the AVS values have been hard to comprehensively assign given their inconsistency with the other initialized config.txt settings; as for the assumed factor, it seems any of the arm and gpu core frequencies can have an effect, and further away from my understanding the OSC and PLL (phase locked loop) have a direct correlation.
As well the implicit incorrectness in my notes, for example using an arm_freq less than 600 was away from where I wanted to test, and overclocking any of the gpu cores could have had more special results for the AVS not actually recorded.
If the arm_freq is set to 1200 and the effective governor/scaler/forceturbo is actively using this mode, without over_voltage; the highest core/gpu_freq that can be used was around 530 at 1.2313V, this amount achieved graphical errors, the gpu doesn't like to get far past 500 while the gpu core doesn't go far beyond 600.
Combining the settings below alone would result in halted system because the core_freq requires a greater voltage than the AVS provided by the arm at 1200, 1.2313V. There is perhaps an exception if exists a way to make effective the AVS_boost without the arm exceeding 1200, or just add a over_volt=5 and the additional 0.125V will be enough for core_freq=600, 1.3563V
arm_freq=1200 gpu_freq=500 core_freq=600
If the arm_freq is normally overclocked 1400-1500 then the AVS_Boost (~0.15V+1.2V) will be added (~1.3500V)
The maximum core_freq was about on the mark of 608 with this voltage and 601 with the hinder avs_boost (1.3438V). These are maximums and I didn't prove any stability, only that core_freq=608 would not boot with less than 1.35V.
The maximum arm_freq achieved with 1.35V was 1556 where an over_voltage of 1 was needed to go higher.
I found that core_freq=600 is stablewith over_voltage=0 and an avs_boost of 0x2191c (137500) + 1.2V = 1.3375V which is a lower voltage than I previously thought ( 1.34375V) by a 6250uV step.
The AVS is weird.
I guess it is worth noting that the AVS is dynamic across all cores, for example when a process uses all 4 cores it will use more voltage and give low-voltage warning in some scenarios. However I think the same AVS value will be shared regardless of the core.
I have a Flash Drive and a Logitech Nano Receiver and... ethernet. If I plug in my controller to charge I get undervolt, If I then unplug the Logitech receiver then the undervolt warnings will go away.
I have this table I haven't updated it in a while the sdram voltages aren't really recommended.
well none of it is really recommended, it is possibly difficult to read and get much useful information from.
As it was initially stated by quicksilver, and I could confirm the other day experiencing this; the over_voltage in excess will contribute to the undervoltage detected across the board. Though it is possible and even practical to undervolt combining the use of "over_voltage_min" and setting the cores to lower frequencies.
With only the setting arm_freq=1200. It was sufficient for all of the games I tried on psx and snes, while keeping a low enough temperature and voltage profile, not needing a fan or exceeding 1.2375V per core.
Still remains, it is sometimes an imperfect power supply coupling or too many peripherals.
the highest core/gpu_freq that can be used was around 530 at 1.2313V, this amount achieved graphical errors, the gpu doesn't like to get far past 500 while the gpu core doesn't go far beyond 600.
That makes sense, I was getting crashes in quake 3 when I would take the gpu/core up to 500 without any over-volting, it could have also been exacerbated by the power supply issue.
Still remains, it is sometimes an imperfect power supply coupling or too many peripherals.
Does that happen when you connect everything to the pi istelf? Looking at the megapi case (that a cool case!) It looks like it powers the usb hub the same way as the nespi case. I can't remember how the power is handled (whether it comes straight from the power supply or from the pi via the poor wiring). The case may be powering the peripherals in a first-pass manner causing the current to the pi to drop.
I tested these settings for over 3 hours with no problems.
arm_freq=1450 gpu_freq=500 core_freq=500 sdram_freq=500 over_voltage=1 over_voltage_sdram=1
over_voltage=1 is sufficient as you predicted, I probably don't need the the over_voltage_sdram either (BTW you were right, I had it miss-labeled as you did lol). It made a pretty good improvement, prboom now runs Doom at 3x resolution, even Ninja Baseball Batman runs smoother now, which surprised me.
I tested arm_freq=1500 and got crashes on quake 3 after about an hour and a half, So I guess that is just a bit too high. Too bad, the 1500=500+500+500 would have satisfied my inner OCD.
Looking closely at the megapi board, the usb hubs appear to share a powered connection through the case as opposed to being more directly routed to the pi. Much too soon before, when I had been using over_voltage=1, having both my controller charging and the logitech receiver plugged in to these front ports did cause the power to drop low enough for warnings but not consistently leading me to think that it is the power supplies microusb connection.
I have disabled the swap space on all of my installations, I can't say if this is very important because I haven't operated much at all while it was enabled.
I'm wondering what make did your Pi come from? For example I have an element14 board.
Also the microsd is it UHS-1 or 3 or a kingston class(4) or (6). A slower microsd in theory could offer instability when computations exceed its limits.
I have $40 dollars that I have saved and want to spend on upgrading something on my pi.
A controller is likely. I was also looking into getting an rtc module but these take the gpio that the case is already using, I don't know if I could fit it. An official powersupply was a maybe, but I'm finding I can work with the one I have now. A smaller fan that will fit correctly but sanding the case a millimeter I think will work just as well. There was a link someone shared me, that was a fan module controller that worked with retroflag cases, to control the fan power.
Any other ideas? Controller recommends? What do you use?
over_voltage_sdram=1 can be discarded, as the default voltage for all the sdram components on the rpi3b+ are
where over_voltage_sdram=1 will be ignored and 2 will step up the over_voltage_sdram_p by 1 giving all the value of 2.
To lower the voltage below the default you have to use over_voltage_sdram_p_min=-1 and so forth.
I found a Sega controller.
Good reviews. I dont think I will be missing analog too much. 10ft usb.
Some of the console controllers can be had for the same price, I think I saw an XB1 official for $22. Which has me hesitant on whether I should get something like this instead.
@Efriim I don’t know what make my pi is, i will note that here when I open this thing up again. SD card is a Sandisk ultra plus v10, it was $20 at Walmart.
That is a pretty awesome looking controller, official sega! Do they make a Saturn version? That’s the only way it could be better. I use a ps4 controller through the Bluetooth, it has worked well for a year.
Sandisk ultra plus v10
That is a class10, is equivalent by some standards to a UHS-1 by definition 10mb/s minimum transfer speed. This card has up to 48mb/s transfer. Which as far I know is high functioning and should be suitable for retropie.
There are sometimes unique uses and advantages to having a class 1 or class 4, they have lower minimum transfer rates and so will have lower bus width(incorrect term?) when reading small amounts of data. Reading snes roms, saves and configs, will be more efficient however an entire operating system will be slow, as these also have lower top speeds, capacity and often quality.
I've been testing the same settings 1500 and 500, 500, 500. It is possible that the manufacture of pi, has used different ram for the device. The brand distributors RS components; I have read they use a sdram chip of lower technical performance.
Or it is possible that a reset was missed when changing settings.
But don't be disheartened, the real performance is how you use it.
Also I have only ever used and seen one rpi3b+ so I am skeptical that this is the case, but I am curious.
There is a Saturn version of the controller, it lacks a "mode" button when compared to the genesis. I can't tell if I'm looking at computer generated imagery of the controller anymore when I look at amazon, I wonder how it feels and if it is the same size, if it makes my hands bleed, if the reviews are fake.
I'm also considering the Super NES, PS2 or Wii Classic(nintendo) adapters to usb.
@Efriim I haven't had any problems with the sd card, roms are loaded from a usb drive anyway, so all it does is load scraped images and videos; the usb drive i use is USB 2.0 which has never seemed be an issue either. Loading times are satisfactory, even for large ps1 games.
That sega controller would look dynamite with your case, but if the sky is the limit then why not consider a bliss box? https://bliss-box.net/
I only load dos/pdfs/ports/scummvm/savestates from usb. They were most convenient, since dosbox requires a configuration already, and scummvm creates a shortcut. The ports are easy to symlink and the savestates are like a backup. And they can all be plugged into a computer and used that way too.
I have a UHS-3 microsd, I think it performs a little slower than a class-10 in regards to the entire operating system.
simpleethat last edited by
I usually skip them when I see them for $50-$100. The dpad:analog integration is cool along with two more buttons, and it has wireless as well as a 10ft cord.
I think I would get the MadCatz fighter style controller, MadCatz wasn't that bad back in the day. It loses wireless for a 9ft usb cable. And adds an analog and ps4 touchpad.
simpleethat last edited by
@Efriim perfectly understandable about the price. I can say that the build quality on them is fantastic, but I also own $100 worth of controllers for playing NES and Genesis games... kinda silly whenever I actually think about it. For reasons that I can't really fathom I always avoid wireless when it comes to my retropie builds. Maybe one day I'll worry myself enough to think about that but not today; tomorrow isn't looking to good either.
Isn't the Playstation classic fairly easy to mod and fairly robust hardware wise?
Anyway, I hope you're pleased with your decision however it goes.
I think I prefer wired controllers, lag and battery life isn't a worry, and you can't run off with your controller and forget where you put it.
I haven't looked far into the psclassic. I think it uses a different emulator than pcsxr yet can install the ARM compiled pcsx and also other emulators probably retroarch. I think the only external storage available is the USB front slot and the internal memory storage is probably 16gb. Performance I hear fails in some games, even the built-in ones, but I don't know any specifications or details about this.
I ordered the 8bitdo M30 (make me cancel it and get the psclassic). Altogether this is going to be a gift for a friend, the M30 I think will be a great 16-bit console pad. Once I give away my retropie it would be cool to have something else to replace it, I love PSX and I like at least the Menu System and Switch Disk, 16gb is enough for me, but 5ft controllers I think is not...
I have the 8bitdo M30.
- It has 4 modes for different types of connectivity (macOS, dinput, xinput, nint-switch) and can also be used plugged in with a USB-C connection.
- It comes with a 3ft USB type-C, Using the USB connection seems to lose function of two of the center navigation buttons, favourite and heart)
- Holding the controller the way it is shaped I want to hold it higher, but can't operate the dpad unless I hold it lower, however it isn't at all challenging to hold it just right, I'm possibly just being picky.
- The dpad maps as an axis in at least 2 of the 4 connection modes, but it is easy to press and use. The start button can't be held for more than 3 seconds because this shuts down the controller. Mapping the controls I expected wouldn't be easy, and it looks like I'll need to make emulator specific adjustments to get what I wan't out of it, this goes for the ES and RetroArch side.
Other than that, I wish it had a select/mode button and came with a 6ft usb type-c.
@Efriim I think you made the right choice, buying a ps1classic is taking a step backward when you have a well curated retropie setup; it is just a money grab from sony.
Having the controller shut down after holding the start button is a pretty cool feature, I wish the ds4 did that. Also a way to check battery level would be awesome.
Maybe you can get functionality back for those 2 buttons with the xpad driver?
I returned the 8bitdo M30 for full credit to get the PSClassic of equal or lesser value. I will have two controllers and a console to hack. The specs of the psclassic are a slight improvement to the RPI3B I think it has the smaller and more efficient Arm Cortex A35 as opposed to the A53, running at 4x1.5ghz. The GPU and RAM are both significantly better with opengl3 and vulkan support, and ddr3. Development is furthering in modifying the underlying system for most emulation, it only has 16gb of internal emmc, no wireless and only 2 usb slots, it also keeps the archaic usb-micro power supply.
I am expecting for it to arrive tomorrow.
And onto overclocking. While still in the experimental ranges. I've been using an under-clock combined with an over-clock at:
arm_freq=1200 #Maximum without reaching the next AVS level. gpu_freq=250 core_freq=500 sdram_freq=500 #No over-voltage
One of the top games I got; Armored Core 3 Portable on PPSSPP, I can get a steady 30fps with these settings. Where the core could go in the range of 460-530 on either end of performance; any more and I think it would need an over_voltage and any less and I think I would see the performance decrease for this emulation at least. Similarly the arm_freq=1200 any more at all and the over_voltage_avs_boost will take effect and increase the core operating voltage from 1.2375V to ~1.35V taking it down to arm_freq=1000 and the performance suffers. The sdram can be underclocked to 400 but it makes a wedge for the fps to drop occasionally, 450-500 isn't bad and the sdram can be overclocked independent of the core voltage and with greater stability behind the slower cores.
here are some small powersaving configurations to add to config.txt since you are using a nespi case.
#disable both the onboard activity and power leds. dtparam=act_led_trigger=none dtparam=act_led_activelow=off dtparam=pwr_led_trigger=none dtparam=pwr_led_activelow=off
i first read them here https://sudomod.com/forum/viewtopic.php?f=43&t=4258
and if the ds4 is at all like the ds3, holding the ps(home) button down for 10 seconds will power it off, though that is a relatively long button press.
@Efriim How much 'power saving' yields disabling the LEDs ?