The online community for MiSTer FPGA enthusiasts
https://misterfpga.org/
I think its going to lead to a nightmare of support questions. Now not only can you have people having overclocked the Arm but also their memory potentially to just on the edge of stability.
Hello.
After I used an optical HDMI cable (galvanically separated Mister from the LCD TV), the 1100 MHz overclock works.
I've also been exploring tweaking some of the DDR3 registers in a way that isn't overclocking but might improve things for core developers.
Weird:
viewtopic.php?t=303
I don't think the N64 core will need this anymore as it's coming along great but there's some fascinating improvements from overclocking memory in Robert's DDR3 test core.
There are across the board improvements to latency. There is a great improvement to bandwidth on non-burst reads. There is barely any improvement to bandwidth on burst reads.
At stock 800 MHz, burst=1:
Bandwidth: 562 MB/s, avg delay: 15
Overclocked to 1050 MHz, burst=1:
Bandwidth: 648 MB/s, avg delay: 13
At stock 800 MHz, burst=128:
Bandwidth: 873 MB/s, avg delay: 16
Overclocked to 1050 MHz, burst=128:
Bandwidth: 901 MB/s, avg delay: 12
Very nice to see! Any instability to report? Do you have a simple script to run for these? I've been running the 1300 OC pretty consistantly and it has been very stable for me. (Antonio's setup)
See https://github.com/coolbho3k/MiSTer-Ove ... _mem_oc.sh
Change the TARGET_KHZ line in mister_mem_oc.sh before copying it over to your SD card with your desired frequency (in KHz).
These must be in increments of 25000. For example:
TARGET_KHZ=800000 800 MHz, same as stock.
TARGET_KHZ=850000 850 MHz
TARGET_KHZ=900000 900 MHz
TARGET_KHZ=950000 950 MHz
TARGET_KHZ=1000000 1000 MHz
TARGET_KHZ=1050000 1050 MHz
TARGET_KHZ=1100000 1100 MHz
how would I go to combine the CPU OC + the memory OC in one script?
You can just copy the following lines near the top of the memory overclock file, after #!/bin/bash
echo "1200000" > "/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq"
echo "Max CPU frequency set to 1200 MHz"
Thanks! 1050 on memory and 1.3ghz on the CPU is stable for me. 1100 on the memory crashes right away at both 1.2ghz or 1.3ghz
Nope, I updated the kernel way back when you did the beta, but since then I just let the main update do its thing.
Why it shouldn't work?
Is it possible that it actually doesn't apply without any error message? It would be funny, me believing it's running while it's actually not XD
Placebo power, but I did some benchmarks at 1300, 6 months ago and it was working.
Neocaron wrote: ↑Thu Aug 31, 2023 7:38 pmNope, I updated the kernel way back when you did the beta, but since then I just let the main update do its thing.
Why it shouldn't work?
Is it possible that it actually doesn't apply without any error message? It would be funny, me believing it's running while it's actually not XD
Yeah it will probably apply without any error message. The list of valid frequencies is baked into the kernel driver.
The frequency has to be a multiple of 200 for everything to be even. 1.4 GHz is far too high and you can't really do 1.3 GHz.
For 1.3 GHz to work you have to set a bunch of other clocks to slightly weird values so I didn't bother.
Coolbho3k wrote: ↑Thu Aug 31, 2023 7:41 pmNeocaron wrote: ↑Thu Aug 31, 2023 7:38 pmNope, I updated the kernel way back when you did the beta, but since then I just let the main update do its thing.
Why it shouldn't work?
Is it possible that it actually doesn't apply without any error message? It would be funny, me believing it's running while it's actually not XDYeah it will probably apply without any error message. The list of valid frequencies is baked into the kernel driver.
The frequency has to be a multiple of 200 for everything to be even. 1.4 GHz is far too high and you can't really do 1.3 GHz.
For 1.3 GHz to work you have to set a bunch of other clocks to slightly weird values so I didn't bother.
So which frequency would get apply then if it's set at 1300000?
Is the 1400000 number connected to the right value? Since you just told me this I tried it and it didn't immediately crashed
Neocaron wrote: ↑Thu Aug 31, 2023 7:45 pmCoolbho3k wrote: ↑Thu Aug 31, 2023 7:41 pmNeocaron wrote: ↑Thu Aug 31, 2023 7:38 pmNope, I updated the kernel way back when you did the beta, but since then I just let the main update do its thing.
Why it shouldn't work?
Is it possible that it actually doesn't apply without any error message? It would be funny, me believing it's running while it's actually not XDYeah it will probably apply without any error message. The list of valid frequencies is baked into the kernel driver.
The frequency has to be a multiple of 200 for everything to be even. 1.4 GHz is far too high and you can't really do 1.3 GHz.
For 1.3 GHz to work you have to set a bunch of other clocks to slightly weird values so I didn't bother.
So which frequency would get apply then if it's set at 1300000?
Is the 1400000 number connected to the right value? Since you just told me this I tried it and it didn't immediately crashed
Coolbho3k wrote: ↑Thu Aug 31, 2023 8:01 pmNeocaron wrote: ↑Thu Aug 31, 2023 7:45 pmCoolbho3k wrote: ↑Thu Aug 31, 2023 7:41 pmYeah it will probably apply without any error message. The list of valid frequencies is baked into the kernel driver.
The frequency has to be a multiple of 200 for everything to be even. 1.4 GHz is far too high and you can't really do 1.3 GHz.
For 1.3 GHz to work you have to set a bunch of other clocks to slightly weird values so I didn't bother.
So which frequency would get apply then if it's set at 1300000?
Is the 1400000 number connected to the right value? Since you just told me this I tried it and it didn't immediately crashed
- I forget if it sets it to 1200000 or doesn't do anything haha.
- No it isn't connected to anything. You can try 2000000 and it won't crash.
Oh boy
Ok so I looked into my og file I was using up until now and it was set to 1200000 while the name was 1.3ghz so that explain why I was having a significant performance boost still compare to stock XD Glad I'm not crazy.
Using the loading of N64 Resident Evil 2 USA as a reference benchmark:
Stock= 35 seconds
memory 1050+cpu at 1.2ghz= 31 seconds
memory 1050+cpu at 1.4ghz= 31 seconds as well
memory 1050+ stock CPU= 35 seconds
So you probably set a limit to basically go to the highest available value if higher.
Neocaron wrote: ↑Thu Aug 31, 2023 8:15 pmOh boy
Ok so I looked into my og file I was using up until now and it was set to 1200000 while the name was 1.3ghz so that explain why I was having a significant performance boost still compare to stock XD Glad I'm not crazy.Using the loading of N64 Resident Evil 2 USA as a reference benchmark:
Stock= 35 seconds
memory 1050+cpu at 1.2ghz= 31 seconds
memory 1050+cpu at 1.4ghz= 31 seconds as well
memory 1050+ stock CPU= 35 secondsSo you probably set a limit to basically go to the highest available value if higher.
The main thing I want to go for is better performance on that core, not just loading times. Because the N64 core uses extensive use of DDR3. Also if you know of a game that lags with the N64 core and is consistently reproducible we can try to see if there's better performance in some situations with overclocked memory.
I know the core won't be cycle accurate and that Robert is targeting stock memory speeds, but N64 seems like the first FPGA core where a memory overclock may make a bit of a real performance difference in the end.
Coolbho3k wrote: ↑Thu Aug 31, 2023 10:42 pmNeocaron wrote: ↑Thu Aug 31, 2023 8:15 pmOh boy
Ok so I looked into my og file I was using up until now and it was set to 1200000 while the name was 1.3ghz so that explain why I was having a significant performance boost still compare to stock XD Glad I'm not crazy.Using the loading of N64 Resident Evil 2 USA as a reference benchmark:
Stock= 35 seconds
memory 1050+cpu at 1.2ghz= 31 seconds
memory 1050+cpu at 1.4ghz= 31 seconds as well
memory 1050+ stock CPU= 35 secondsSo you probably set a limit to basically go to the highest available value if higher.
The main thing I want to go for is better performance on that core, not just loading times. Because the N64 core uses extensive use of DDR3. Also if you know of a game that lags with the N64 core and is consistently reproducible we can try to see if there's better performance in some situations with overclocked memory.
I know the core won't be cycle accurate and that Robert is targeting stock memory speeds, but N64 seems like the first FPGA core where a memory overclock may make a bit of a real performance difference in the end.
Oh yeah I agree! It was just a basic test to show that the OC of the CPU was working even when set at 1.4 it was just setting 1.2 instead. I'm sure performance on arm based emulators has been improve significantly with these 2 OC combine, glad to see it stable at 1.2ghz+1050.
Neocaron wrote: ↑Thu Aug 31, 2023 11:18 pmCoolbho3k wrote: ↑Thu Aug 31, 2023 10:42 pmNeocaron wrote: ↑Thu Aug 31, 2023 8:15 pmOh boy
Ok so I looked into my og file I was using up until now and it was set to 1200000 while the name was 1.3ghz so that explain why I was having a significant performance boost still compare to stock XD Glad I'm not crazy.Using the loading of N64 Resident Evil 2 USA as a reference benchmark:
Stock= 35 seconds
memory 1050+cpu at 1.2ghz= 31 seconds
memory 1050+cpu at 1.4ghz= 31 seconds as well
memory 1050+ stock CPU= 35 secondsSo you probably set a limit to basically go to the highest available value if higher.
The main thing I want to go for is better performance on that core, not just loading times. Because the N64 core uses extensive use of DDR3. Also if you know of a game that lags with the N64 core and is consistently reproducible we can try to see if there's better performance in some situations with overclocked memory.
I know the core won't be cycle accurate and that Robert is targeting stock memory speeds, but N64 seems like the first FPGA core where a memory overclock may make a bit of a real performance difference in the end.
Oh yeah I agree! It was just a basic test to show that the OC of the CPU was working even when set at 1.4 it was just setting 1.2 instead. I'm sure performance on arm based emulators has been improve significantly with these 2 OC combine, glad to see it stable at 1.2ghz+1050.
BTW I just wrote a script to print and tweak all the memory timings: https://github.com/coolbho3k/MiSTer-Ove ... timings.sh
Edit the timings at the top however you like. It doesn't seem to do much for cores but you can play around with it if you want.
I can tighten to 5/6/6/11 at stock but definitely crash at 1050 MHz with those settings.
I can run at 6/6/6/14 though.
Thanks! It's nice to have options like this, I'm all for this kind of tinkering :p I wonder if any of your discoveries could be applied to fix antonio's villena 128mb 4 cells memory incompatibility by allowing to tweak the SDRam timing or overclock it to go around its limitation. I have bought another one a months ago, but I don't like e-waste ^^... so If you know a possible way to get acces to the SDram to experiment with timing or frequency that would be awesome. It would be just experimentation obviously because I'm pretty sure touching SDram timing (or speed) could cause problem with many cores.
Neocaron wrote: ↑Sun Sep 03, 2023 2:31 amThanks! It's nice to have options like this, I'm all for this kind of tinkering :p I wonder if any of your discoveries could be applied to fix antonio's villena 128mb 4 cells memory incompatibility by allowing to tweak the SDRam timing or overclock it to go around its limitation. I have bought another one a months ago, but I don't like e-waste ^^... so If you know a possible way to get acces to the SDram to experiment with timing or frequency that would be awesome. It would be just experimentation obviously because I'm pretty sure touching SDram timing (or speed) could cause problem with many cores.
I think SDRAM is all MiSTer framework stuff and is already fully tweakable by core developers.
Ok thanks for educating me on that, I guess it's the whole point of the SDram in the first place.
