MiSTer FPGA Forum

MI2 test is in the Cartrographer's room at the start. Thats the hardest bit of music for the system.

FPGA64 wrote: ↑Sat Jul 30, 2022 1:04 pm MI2 test is in the Cartrographer's room at the start. Thats the hardest bit of music for the system.

Here ya go, you be the judge. I'm not much of a MIDI expert. Please excuse the squeaking and static noises in the background, that's just my loud as hell NAS. I assure you the mister output is clear. This is running at 1.2ghz overclock with munt on AO486.

MI2 intro: https://vocaroo.com/1aA9Sv1NDw2q

MI2 Wally's room: https://vocaroo.com/1bP4EDnSQsjB

wizzo wrote: ↑Fri Jul 29, 2022 10:47 am I ended up doing a little test measuring temperatures at different speeds. The reported temperatures are meaningless given all the variables, but I wanted to see the relative temperature difference. We all seem to agree 800mhz (stock) with a fan and heatsink is safe, right?

• I have an aluminium heatsink and a noctua fan. I ran the test without a case.

• I attached a temperature sensor to the base of the heatsink with a thermal pad, then the sensor connected back to the nano's i2c bus through the RTC board.

• I had an ambient temperature of around 21C.

• I ran through the following a couple times at each speed: menu idle, NES Gradius II, PSX Crash Warped, AO486 Monkey Island 2 with munt running, AO486 Ultima 7 with munt running (Kitrinx mentioned this game was particularly demanding and sensitive to timing issues)

• At each step I left it running long enough for the temperature to stabilise.

Unless someone really wants me to, I won't write out the whole table here. It turned out to be very predictable and linear. The summary is:

• The highest temperature I recorded was 31.4C which is AO486 and munt running at 1.2ghz. The game running didn't seem to matter.

• Lowest temperature was 28.8C for NES running at 400mhz.

• The difference between 800mhz and 1.2ghz across the board is around 0.5C.

• The difference between 400mhz and 800mhz was around 0.3C.

• munt started running well at 1ghz and I had trouble telling the difference between that and 1.2ghz (someone else probably can tell)

• The temperature difference is so small that I had trouble with ambient temperature affecting the result too much.

• I noticed 2 possible glitches in Ultima but they also occurred at 800mhz. Noticed no glitches otherwise, but this probably needs a lot more testing.

So that's that. Personally I'm satisfied that the overclock is safe. It's hard to say what the internal temperature of the chip is, or how it's affected by passive cooling and no heatsink... but it's like a 3% temperature difference with my setup. Putting my case back on was like 5x worse for temperature than overclocking to 1.2ghz

This is awesome that you did that! Thank you for taking the time. It shows how conservative the power budget on the chip is in the first place and how completely safe this really is. I can also confirm the complete stabilty with every core I thrown at it at 1.2ghz. Temperature wise, It has to be negligeable for me as well on the antonio Villena model, but I don't have hard number.

Munt is totally useable at 1.2ghz. It's 95% there.

Neocaron wrote: ↑Sat Jul 30, 2022 9:49 pm Munt is totally useable at 1.2ghz. It's 95% there.

Seems like a good reason to put this in main and let the user decide if they want to hunt down how to enable it.

Given that we now have actual hard power and heat measurements, and they're barely different, maybe it would make sense to include the option as a kernel tunable?

It would be nice to get a direct comparison with the mt32-pi as well. I keep saying "oh it's pretty close" but what I really mean is "I literally cannot tell the difference but I'm afraid of someone jumping in and calling me an idiot"

wizzo wrote: ↑Sun Jul 31, 2022 1:55 am It would be nice to get a direct comparison with the mt32-pi as well. I keep saying "oh it's pretty close" but what I really mean is "I literally cannot tell the difference but I'm afraid of someone jumping in and calling me an idiot"

Even without having a MT32pi, when I tried munt a few months ago I could tell it wasn't dead perfect at 1.2ghz but still awesome! It was much better than regular audio, so it's still an upgrade. It's a good middle ground for people, especially currently. At 1ghz it was missing notes, so not great.

I hope Sorg will consider the option... Thanks again wizzo for getting proper temp readings.

Its still unproven. The arm cores have no thermal throttle. Its a very dangerous thing to put into main and should be left as a user replace option.

FPGA64 wrote: ↑Sun Jul 31, 2022 12:18 pm Its still unproven. The arm cores have no thermal throttle. Its a very dangerous thing to put into main and should be left as a user replace option.

I have to agree. Even as a "hidden" option there's some implication of it being supported and safe if the patch is shipped. Where would the warning go as well? It'd be up to the third party scripts to warn users of potential risk. It sounds like there are people in this thread too who got unlucky and overclocking causes crashes

FPGA64 wrote: ↑Sun Jul 31, 2022 12:18 pm Its still unproven. The arm cores have no thermal throttle. Its a very dangerous thing to put into main and should be left as a user replace option.

The de10 nano uses a particularly heat-tolerant SoC, specced to run safely at up to 125 degrees C, so any conceivable temperature increase is harmless to the hardware - the worst thing that could happen would be timing issues in the most complex cores (mainly ao486).

Bring this thing to main (IMO) - the improvement to onboard munt/fluidsynth alone outweighs the potential cons.

ToothbrushThreepwood wrote: ↑Sun Jul 31, 2022 8:41 pm

FPGA64 wrote: ↑Sun Jul 31, 2022 12:18 pm Its still unproven. The arm cores have no thermal throttle. Its a very dangerous thing to put into main and should be left as a user replace option.

The de10 nano uses a particularly heat-tolerant SoC, specced to run safely at up to 125 degrees C, so any conceivable temperature increase is harmless to the hardware - the worst thing that could happen would be timing issues in the most complex cores (mainly ao486).

Bring this thing to main (IMO) - the improvement to onboard munt/fluidsynth alone outweighs the potential cons.

Looked for myself, checks out here.

"TJ Operating junction temperature –55 125 °C"

So there is no on die sensor on the Cyclone V series? I haven't been able to search up much information on this topic.

Isn't the rated speed of the ARM cores 925MHz rather than 800? And I assume they meant that to be without any additional cooling at all?

ToothbrushThreepwood wrote: ↑Sun Jul 31, 2022 8:41 pm

FPGA64 wrote: ↑Sun Jul 31, 2022 12:18 pm Its still unproven. The arm cores have no thermal throttle. Its a very dangerous thing to put into main and should be left as a user replace option.

The de10 nano uses a particularly heat-tolerant SoC, specced to run safely at up to 125 degrees C, so any conceivable temperature increase is harmless to the hardware - the worst thing that could happen would be timing issues in the most complex cores (mainly ao486).

Bring this thing to main (IMO) - the improvement to onboard munt/fluidsynth alone outweighs the potential cons.

Excatly the point since the FPGA is on the same die as the Arm cores this may cause subtle timing issues. We all know the majority of people given a go fast option will turn it on regardless and so this will make support so much harder as we also know that when it breaks people will not remember they have "Turboed" the arm chips.

It therefore should not be in Main but a User replacement for those who understand the risk

But that involves so much pain that the feature is essentially unusable.

wizzo wrote: ↑Sun Jul 31, 2022 4:19 pm I have to agree. Even as a "hidden" option there's some implication of it being supported and safe if the patch is shipped. Where would the warning go as well? It'd be up to the third party scripts to warn users of potential risk.

It could be put in some "experimental/unsafe features" tab (like in the PSX core) and have the warning in the scroller text.

I'm not actually interested in this feature myself, but I'm also not a fan of stopping new options/features being implemented only because of the "user might break something" argument. MiSTer is not exactly an off the shelf commercial product for casual users, and ours are probably a bit above average when it comes to understanding how things work, so being a bit adventurous is not a bad thing, imo. And there are already plenty of options within the OSD which might cause problems when used incorrectly. We answer questions about them occasionally too.

And if it was proven to have really catastrophic effects it could be always removed.

akeley wrote: ↑Mon Aug 01, 2022 8:50 am It could be put in some "experimental/unsafe features" tab (like in the PSX core) and have the warning in the scroller text.

At least 99% of the people would still forget that they have turboed the ARM cpu.
If you added a big red flashing warning sign over the whole screen with a blaring horn that can not be clicked past for 5sec then most people would still forget, sure less then 99%.

grizzly wrote: ↑Mon Aug 01, 2022 10:49 am

akeley wrote: ↑Mon Aug 01, 2022 8:50 am It could be put in some "experimental/unsafe features" tab (like in the PSX core) and have the warning in the scroller text.

At least 99% of the people would still forget that they have turboed the ARM cpu.
If you added a big red flashing warning sign over the whole screen with a blaring horn that can not be clicked past for 5sec then most people would still forget, sure less then 99%.

It was just an example. You could put it in mister ini too, or whatever, I'm sure there is a reasonably safe way of implementing it.

And no, it wouldn't be 99% of users, more like 9, but whatever the number, it's still not a good reason to stop others benefitting from this feature. I find all these nannying attitudes rather bizarre, this is a device for adults and what they do with it past certain level of warnings is on them.

akeley wrote: ↑Mon Aug 01, 2022 11:27 am And no, it wouldn't be 99% of users, more like 9, but whatever the number, it's still not a good reason to stop others benefitting from this feature. I find all these nannying attitudes rather bizarre, this is a device for adults and what they do with it past certain level of warnings is on them.

Normally I would agree with your point of view and I'm
not normally such a spoil sport. But in my own experience requesting features, Sorg seems to be very risk averse when it comes to the Linux system and is pretty firm on his position. I think this is some of the stuff that will get brought up during the pull request

wizzo wrote: ↑Mon Aug 01, 2022 12:02 pm But in my own experience requesting features, Sorg seems to be very risk averse when it comes to the Linux system and is pretty firm on his position. I think this is some of the stuff that will get brought up during the pull request

Yeah, pretty sure this will indeed happen, but I'm just talking about the principle, seeing as this "safety" theme appears now and then. And the arguments against are usually not very convincing, same as in this case.

But, I've also seen some position reversals over the years so, never say never

Experimental feature in main for a year or so until we get enough feedback could be a nice middle ground

Leaving it as an INI option rather than a OSD option seems like a reasonable middle ground. It's already pretty standard procedure to tweak the INI for various reasons, and folks who do so are (or should be) cognizant of how they could be messing up their MiSTer. Include some explanation that adjusting the ARM clock hasn't been rigorously tested, some DE-10 nanos have responded poorly to overclock, and anyone messing with it is doing so at their own risk.

The alternative would be to leave it as a per-core option, so cores that use the ARM side more extensively can take advantage of the overclock and other cores can be left safely at the regular speed (or even underclocked, for what little benefit that may provide).

Maybe you could have it not even as an ini option, but rather only as a kernel tunable. If the user has to add or write a custom script to invoke an overclock, they're more likely to remember that they've done so.

In other words, do the minimum possible to give the experts access without having to compile custom kernels, while deliberately not providing any obvious knobs for the less clueful to twiddle.

Eventually, if everything works well for a good long time, and we're not seeing a ton of support issues, adding an ini option might be safe.

I can easily mess up my PC by changing overclocking and other settings in the BIOS.

Would someone be willing to compile a new version and post it? The current binary causes problems with my Wi-Fi adapter. I compiled one myself, but neither Bluetooth nor Wi-Fi work in that version. :/

centsy wrote: ↑Mon Sep 05, 2022 12:47 am Would someone be willing to compile a new version and post it? The current binary causes problems with my Wi-Fi adapter. I compiled one myself, but neither Bluetooth nor Wi-Fi work in that version. :/

Here you go!

https://github.com/wizzomafizzo/mrext/b ... zImage_dtb

wizzo wrote: ↑Mon Sep 05, 2022 10:09 am

centsy wrote: ↑Mon Sep 05, 2022 12:47 am Would someone be willing to compile a new version and post it? The current binary causes problems with my Wi-Fi adapter. I compiled one myself, but neither Bluetooth nor Wi-Fi work in that version. :/

Here you go!

https://github.com/wizzomafizzo/mrext/b ... zImage_dtb

Thank you! Strangely my wifi is still not working with this version. Bluetooth does work fine (strange considering it's a combo adapter.) I have this adapter: https://misteraddons.com/collections/pa ... 4352060549

Anyone else run into this?

centsy wrote: ↑Mon Sep 05, 2022 3:28 pm Thank you! Strangely my wifi is still not working with this version. Bluetooth does work fine (strange considering it's a combo adapter.) I have this adapter: https://misteraddons.com/collections/pa ... 4352060549

Anyone else run into this?

Hmm I'm not sure. It works fine on the stock kernel though?

To be clear, the kernel I linked isn't *exactly* the stock kernel plus overclock. I also added a patch for my own wifi dongle and set it to compile wifi and bluetooth into the kernel rather than using modules. But I can't imagine why it would make the wifi on that dongle stop working?

wizzo wrote: ↑Tue Sep 06, 2022 1:14 am

centsy wrote: ↑Mon Sep 05, 2022 3:28 pm Thank you! Strangely my wifi is still not working with this version. Bluetooth does work fine (strange considering it's a combo adapter.) I have this adapter: https://misteraddons.com/collections/pa ... 4352060549

Anyone else run into this?

Hmm I'm not sure. It works fine on the stock kernel though?

To be clear, the kernel I linked isn't *exactly* the stock kernel plus overclock. I also added a patch for my own wifi dongle and set it to compile wifi and bluetooth into the kernel rather than using modules. But I can't imagine why it would make the wifi on that dongle stop working?

Yea, everything works great on the stock kernel. I see the same issue with the version on the Releases page in the first post, so I'm not sure if your customization is really at fault or if there is some other issue.

No issue to report with my bluetooth or wifi adapter. Weird.

wizzo wrote: ↑Tue Sep 06, 2022 1:14 am

centsy wrote: ↑Mon Sep 05, 2022 3:28 pm Thank you! Strangely my wifi is still not working with this version. Bluetooth does work fine (strange considering it's a combo adapter.) I have this adapter: https://misteraddons.com/collections/pa ... 4352060549

Anyone else run into this?

Hmm I'm not sure. It works fine on the stock kernel though?

To be clear, the kernel I linked isn't *exactly* the stock kernel plus overclock. I also added a patch for my own wifi dongle and set it to compile wifi and bluetooth into the kernel rather than using modules. But I can't imagine why it would make the wifi on that dongle stop working?

IIRC, some Linux features must be loaded as modules to work correctly; this was some change they made like twenty years ago. It was so long ago that my memory is quite vague, but I remember being frustrated that I couldn't compile static kernels anymore, as I regarded module loading as a security attack surface. (which, ultimately, proved to be correct, although not that important compared to just attacking the drivers directly, in either module or static form.)

While the base wifi and bluetooth can apparently be compiled in, since that's working fine for you, it's possible that the adapter driver he's loading is expecting them to be modules, and thus isn't working. A dmesg dump would probably help pin that down.

Malor wrote: ↑Sun Oct 16, 2022 1:24 pm

wizzo wrote: ↑Tue Sep 06, 2022 1:14 am

centsy wrote: ↑Mon Sep 05, 2022 3:28 pm Thank you! Strangely my wifi is still not working with this version. Bluetooth does work fine (strange considering it's a combo adapter.) I have this adapter: https://misteraddons.com/collections/pa ... 4352060549

Anyone else run into this?

Hmm I'm not sure. It works fine on the stock kernel though?

To be clear, the kernel I linked isn't *exactly* the stock kernel plus overclock. I also added a patch for my own wifi dongle and set it to compile wifi and bluetooth into the kernel rather than using modules. But I can't imagine why it would make the wifi on that dongle stop working?

IIRC, some Linux features must be loaded as modules to work correctly; this was some change they made like twenty years ago. It was so long ago that my memory is quite vague, but I remember being frustrated that I couldn't compile static kernels anymore, as I regarded module loading as a security attack surface. (which, ultimately, proved to be correct, although not that important compared to just attacking the drivers directly, in either module or static form.)

While the base wifi and bluetooth can apparently be compiled in, since that's working fine for you, it's possible that the adapter driver he's loading is expecting them to be modules, and thus isn't working. A dmesg dump would probably help pin that down.

Like Wizzo I don't see what the driver being statically linked vs. a module has to do with overclocking or why the overclocking would break it, assuming the driver works statically linked without the overclock patch.

I would say that this degree of "hacking" is easiest (and safest for that matter) for people who are comfortable jumping right in and looking at the error messages and even relevant source code and understanding what the problem might be.