Switch-OC-Suite
- Thread starter meha
- Start date
- Views 136,242
- Replies 760
- Likes 32
timings have to be adjusted for each individual device. this is because every chip has different capabilites, and same timings can work on some devices, but not for others. you can check my values at github discussions
yes, but like i said, even if you have same ram chip, the timings work on my console, but may not work on your console. that's why there is no bs magical auto setting values, and you have to do painful procedure of manually adjusting
Last edited by meha,
you would get game crashes or AMS hang or crash, and yes if unlucky, can corrupt your nand. that's why it's recommended to do a full nand backup before any kind of ram OC.
yes starting from 2400 with no timing adjustments is a good starting point. if you are fine with performance of no timing adjustments, you can just use it.
or you can tighten(increase) one by one to test
Last edited by meha,
Thanks for all your work! I seem to have gotten lucky with my supposedly crappy Hynix RAM in my TOTK oled. It seems to handle 2400mhz pretty well. Looking forward to tweaking.
Little confused by some options as I noticed your personal settings use AUTO_ADJ with custom timings. Could you clarify the difference between AUTO_ADJ with custom timings and CUSTOM_ADJ with the same custom timings?
Likewise what's the difference between AUTO_ADJ with 0 for all timing settings and CUSTOM_ADJ with 0 for everything?
Little confused by some options as I noticed your personal settings use AUTO_ADJ with custom timings. Could you clarify the difference between AUTO_ADJ with custom timings and CUSTOM_ADJ with the same custom timings?
Likewise what's the difference between AUTO_ADJ with 0 for all timing settings and CUSTOM_ADJ with 0 for everything?
good luck
CUSTOM = Only adjust timings of presets that are not 0. so CUSTOM with all 0 is same as NO_ADJ
AUTO = adjust all parameters. 0 for AUTO uses default values. non 0 for auto uses that value
changing timings works for both CUSTOM and AUTO
this might be confusing, but if you raise memory frequency, the parameter values in register also need to be increased accordingly. and AUTO_ADJ does that. auto adjust values to correct value
Last edited by meha,
I'm testing RAM OC with parameters meha provided for Samsung (obviously, my memory is Samsung MGCL, too) and GPU undervolt (HiOPT Table).
Unfortunately, RAM OC probably caused my OLED to freeze. After the incident, I tested this OC with the provided memtest homebrew (which I should have done in the first place), and on the 6th loop (fast test), it errored at the Stuck Address. I am sharing this information in case it can be of any use.
Also, what's the difference between SLT Table and HiOPT one? I use the latter for now, and it seems that it allows for around 4 hours of playtime in TOTK in portable mode (medium brightness) with GPU set to 768MHz (I never go beyond this value), 1600MHz RAM, and Reverse-NX set to Docked. It's actually quite good so far.
It's worth mentioning that I followed the hekate_ipl.ini tip about the order of the loader.kip string placement. Turns out it hasn't been working before I edited my hekate_ipl.ini file...
And another question, how many loops should I wait for when testing RAM stability? For both fast and slow tests.
Unfortunately, RAM OC probably caused my OLED to freeze. After the incident, I tested this OC with the provided memtest homebrew (which I should have done in the first place), and on the 6th loop (fast test), it errored at the Stuck Address. I am sharing this information in case it can be of any use.
Also, what's the difference between SLT Table and HiOPT one? I use the latter for now, and it seems that it allows for around 4 hours of playtime in TOTK in portable mode (medium brightness) with GPU set to 768MHz (I never go beyond this value), 1600MHz RAM, and Reverse-NX set to Docked. It's actually quite good so far.
It's worth mentioning that I followed the hekate_ipl.ini tip about the order of the loader.kip string placement. Turns out it hasn't been working before I edited my hekate_ipl.ini file...
Post automatically merged:
And another question, how many loops should I wait for when testing RAM stability? For both fast and slow tests.
Last edited by Purpeliz,
slt is slightly aggressive undervolt, and hiopt is very aggressive undervolt. unfortunately hiopt does not seem to work correcty for now.
and yes, that's why ram timing has to be adjusted for each device. same timing works on mine, don't work on yours
memtester has to be run several hours for stability, but since sometimes its not good at catching errors, it is recommended to just actually run some GPU intensive games and see if it freezes or not. we test with intensive games like Kirby Discovery, Nier Automata, Crash Bandicoot, Zelda TotK, to see if game freezes or not
Last edited by meha,
First of all: Huge thanks for this utlity. I love tinkering with clocks, timings etc. on my PC as well 
I wanted to share my findings using this utility the last couple of days. Please keep in mind that I have not the greatest understandings of RAM timings nor do I think myself of some kind of expert. Before I start here are some infos regarding my switch unit:
Switch Oled (picofly mod) with Samsung MGCL RAM. For more details take a look at the HardwareInfo picture.
I started with the suggested RAM timings for Samsung MGCL values found in the github discussion section , which unfortunetly didn't work out for my unit. I lowered the Timing values each by one and tested again and it was stable. To do that I used the provided memtester to stress test the new values - after looping the stress test 11 times I decided it was stable. After that I played OctoPath 2, which did not crash with the new values after hours of gameplay.
So here is my adjusted config: Samsung MGCL : DRAM Timing: 1 Vdd2 1150mV, vddq 625mv, 2400Mhz: 4-2-3-3-4-3-4 - can also be found on github discussion.
To check what the results are I used the tinymembench tool in applet mode and did the bandwidth test with 1 thread. CPU clock at 1020 Mhz and RAM at 2400 Mhz. The results are generally higher transfer speeds and maybe more importantly lesser deviation. Pictures below show the results. 2400default is 2400 Mhz with autodajusted timings, the other two are with the tweaked timings. Two so it is at least somewhat comparable.
Btw if anyone knows of a better way to test using the memtool please let me know.
I'm currently playing OctoPath 2 and couldn't see any noticable improvment but I haven't really put the system to work. I will test with 60fps and higher settings the next few days to see how much of an imporvement it can provide while under heavy load.
I hope this can provide some helpful information on the topic.
I wanted to share my findings using this utility the last couple of days. Please keep in mind that I have not the greatest understandings of RAM timings nor do I think myself of some kind of expert. Before I start here are some infos regarding my switch unit:
Switch Oled (picofly mod) with Samsung MGCL RAM. For more details take a look at the HardwareInfo picture.
I started with the suggested RAM timings for Samsung MGCL values found in the github discussion section , which unfortunetly didn't work out for my unit. I lowered the Timing values each by one and tested again and it was stable. To do that I used the provided memtester to stress test the new values - after looping the stress test 11 times I decided it was stable. After that I played OctoPath 2, which did not crash with the new values after hours of gameplay.
So here is my adjusted config: Samsung MGCL : DRAM Timing: 1 Vdd2 1150mV, vddq 625mv, 2400Mhz: 4-2-3-3-4-3-4 - can also be found on github discussion.
To check what the results are I used the tinymembench tool in applet mode and did the bandwidth test with 1 thread. CPU clock at 1020 Mhz and RAM at 2400 Mhz. The results are generally higher transfer speeds and maybe more importantly lesser deviation. Pictures below show the results. 2400default is 2400 Mhz with autodajusted timings, the other two are with the tweaked timings. Two so it is at least somewhat comparable.
Btw if anyone knows of a better way to test using the memtool please let me know.
I'm currently playing OctoPath 2 and couldn't see any noticable improvment but I haven't really put the system to work. I will test with 60fps and higher settings the next few days to see how much of an imporvement it can provide while under heavy load.
I hope this can provide some helpful information on the topic.
Attachments
well, for me it works ok for now. I rolled back to the default loader.kip and enabled only HiOPT GPU undervolt (without RAM OC this time). I've been playing Divinity Original Sin 2 for a couple of hours and it seems to be ok. if by "doesn't seem to work correctly" you mean higher frequencies, I never go higher than 768, so I guess I'm in the safe zone. sort of...
anyway, thank you for your work. power efficiency is pretty good so far!
Everything is in the github link in the main post.
Post automatically merged:
Are there any other possibilities to further improving power efficiency? Anything that COULD be done in the future? For example, getting more than 4 hours of playtime in portable with 768MHz GPU, Reverse-NX set to Docked?
Don't get me wrong though, it's already very impressive and a must have tool!
Also, as far as I can tell, out of the box 1600MHz and 1996MHz RAM frequencies (with default loader.kip values) have the same power draw. Is it correct?
Last edited by Purpeliz,
When I'm setting up a loader for Erista, should I be starting my individual timings at 0 or 1? I get that higher numbers equal tighter timings, but I'm not clear on how a setting of 0 vs 1 will work with Erista since the auto/custom adjust box is hidden.
I think I'll set up a quick emunand on a spare sd card and use TOTK to test stability.
Thanks a ton for all the work you've put into this project! I always enjoyed RAM overclocking on desktops in spite of the time commitment, and I never thought the same would be possible on the Switch of all things!
I think I'll set up a quick emunand on a spare sd card and use TOTK to test stability.
Thanks a ton for all the work you've put into this project! I always enjoyed RAM overclocking on desktops in spite of the time commitment, and I never thought the same would be possible on the Switch of all things!
Timings don't work for erista. currently Mariko Only.
and for clarification, Timing 0 for AUTO_ADJ uses default values, so it's same as 1 for most timings
Timing preset 0 for CUST_ADJ does not adjust values, and 1 uses that value for adjustment
Post automatically merged:
higher freq of course draws more power, but it would not be that much for ram.
if increasing power efficiency was so simple, the manufacturers would already have done that. but undervolting helps with power efficiency some bit. if you want more battery life, lower the clocks.
Post automatically merged:
There were Minor bug fixes to Switch OC suite version 1.5 (latest release file has been replaced)
now 2400Mhz will be more stable.
Last edited by meha,
I misread one of your earlier posts, thanks for clarifying. I've got that itchy trigger finger from RAM OCing on desktops, so my mind read what it wanted hear
Is there a good overlay to see voltage in real-time?
Yes, I understand it's not that simple, I was wondering if there is anything experimental or remotely possible. You know, its just curiosity, nothing more. Sorry if it bothers you.
if you go to misc section in sys-clk-oc, you can see the voltages.
but please do note that these voltages are what pcv tries to set and may not be actual voltages. pcv can lie.
Similar threads
-
- Locked
