USB instead of microSD for the operating system causing overheating
-
And to make things a lil more complicated, according to this:
https://en.m.wikipedia.org/wiki/Nintendo_64_technical_specifications
... not only the N64 architecture had a 32 bit system bus, but also most of its games used the faster and more compact 32 bit data operations. lol -
@zupi the bus architecture being less than the processor capability seems pretty common. But the majority of the games made being 32 bit definitely explains how it is that the other four games I tested run fine. Zelda, Mario (runs fine from SD as well), wipeout 64, and OgreBattle (correct the name if I'm wrong, only played it once), run fine from the USB stick without over clocking the pi 3. Golden Eye doesn't do so well, and I'll know within the next few months (hopefully) if it is due to the operating system managing memory as 32-bit, but only if I can get a 64 bit emulator thats good. I'm trying to help cross compile and test Debian libraries for aarch64, but I'm also taking 6 college classes at the moment along with starting a business, and going right into the summer semester with 4 classes, then right back to 6. So I'm constantly busy.
I also have no idea what bit the buslines are on the pi 3, my google search failed me.
Surprisingly, it appeared that Dreamcast games ran alright from the SD. I hadn't managed to find that controller file to edit the fields on to be loaded into the array the emulator uses to interface the controller, so I hadn't really had a chance to test Dreamcast out, but shenmus start screen and video demo looks fine on sd. I hope it works good though. Right now I'm working on helping a friend by working on a submodule of Joust Mania for the pi 3 to get the sound to work right. When I'm done with that, I'll see if I can find reicasts source code so I can see where it loads the file from, because I hadn't found good on the net for that.
Anyway, I was hoping since the N64 games play well (a lot of them) without over clocking the processor by running the operating system and games from the USB, that someone may want to try it, and fool around with the settings to see how to get the processor to not overheat so fast when using shaders. All the consoles cause this when using shaders if running the operating system and the games from usb, but the performance boost is noticeable. I didn't have to scale the graphics down or anything.
If someone is down to try, all you have to do is install raspbian lite on a microSD card, follow the raspberry pi foundations instructions to transfer the operating system to the USB drive (very easy to copy and paste by using SSH), then once raspbian is bootable without the SD card, install retropie on top of it. Also, add a script to bypass asking for your password, and add the script to start emulation station. Make a back-up image, because I messed something up the first time I tried and had to start over, which was easy because I then knew what to do already.
Besides N64 games running better, its also fun to set up, it was for me.
I am starting to think that I may just have to wire a little fan to it though. -
@zupi I forgot to mention why bus lines wouldn't need to be up to the bits of the processor. The processor would normally have more than just some cores under the square you can see. It also has an instruction register, memory address register, memory buffer register, input/output address register, input/output buffer register, program counter, and the execution unit which is what the cores make up.
The bus lines, or bus, are just routes for information to take. The memory for a, let's say a game ROM, if stored in ram, it would be very likely that it is "scattered" throughout the ram if you could actually see it. The registers keep track of the addresses that the pieces are located, and more. The pieces most of the time are written onto a page that fits into a frame. The pages are pretty small, and do not make a whole process by themselves, a lot of the time anyway.
So the pages are at their own address. The registers keep track of the addresses. When a process needs to load, they load into the buffer. Each address goes to a bus, and would not need much room to get into that memory buffer. When a process needs to be loaded into the process counter ( what I kept calling a table, because I picture a table and forgot that its actually not the correct term) it pulls the processes from the buffer, which the buffer collects from the multiple addresses that are stored within the register. A single 64 bit process is stored into ram as very small units the size of frames that the memory management system determines, and do not need 64 bit sized busses for each page to travel to the buffer. They wouldn't require much at all. But, once they are to go into the execution unit, a 64 bit process can be loaded into a core if the memory manager understands how to tell the processor to do so, after it has cumulated into the buffer.
There's a lot more to it than that, but I'm just showing the very basic reason as to why a bus does not need to be able to transfer the amount that a processing core can handle.
-
I m not so technically advanced but I am quite confident that your assumptions seem to be more relevant to raspberry's architecture than the emulators themselves.
Either way we can all enjoy raspberries, either by gaming and projects or torturing ourselves causing troubles and searching for solutions and optimizations .
It's in human nature after all. -
@NastyButtler322 said in USB instead of microSD for the operating system causing overheating:
@dankcushions all of it is compiled as 32 bit, because the operating system is 32 bit. But the games are compiled to be ran on a system using a 64 bit processor, and memory management scheme in mind. A 64 bit emulator can not do the memory management, that's the operating system, and the operating system is 32 bit. If the operating system were 64 bit, a 32 bit emulator would not make a difference, but at least a 64 bit emulator can be used in its place in that case, and if both are 64 bit, then the memory management can implement a larger segmented paging scheme, and those larger processes can be pushed from the table into each core. A faster I/O secondary memory helps relieve the problem of small ram that the pi 3 has that people complain about all the time.
the whole emulator and rom is in RAM the whole time and nothing much gets transferred to/from the drive (SD or USB) once the game is running. the pi 3's 1GB is LOADS more than N64 uses.
linux provides ample facilities to monitor disk i/o, so don't take my word for it. here's the output of
vmstat 5whilst mario 64 is playing:procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 509540 18316 102016 0 0 0 0 3730 4756 11 1 88 0 0 1 0 0 509416 18316 102016 0 0 0 0 5022 5952 11 3 85 0 0 1 0 0 509324 18316 102016 0 0 0 0 2838 3791 10 1 89 0 0 1 0 0 508952 18316 102016 0 0 0 0 2593 3690 8 1 90 0 0 0 0 0 508828 18324 102016 0 0 0 7 2962 4801 9 3 89 0 0 0 0 0 508548 18324 102016 0 0 0 0 2433 3127 7 1 92 0 0 1 0 0 508084 18324 102016 0 0 0 0 2305 3377 7 1 92 0 0 1 0 0 508052 18324 102016 0 0 0 0 2260 3139 14 1 85 0 0 1 0 0 508052 18324 102016 0 0 0 0 6360 11882 13 3 84 0 0 1 0 0 507960 18324 102016 0 0 0 0 5093 9343 15 1 84 0 0 0 0 0 507960 18332 102008 0 0 0 9 3454 5932 15 1 83 1 0 0 0 0 507928 18332 102016 0 0 0 0 2650 4781 14 2 84 0 0 0 0 0 554672 18332 102016 0 0 0 3 2431 4020 12 1 87 0 0 0 0 0 554704 18340 102008 0 0 0 6 3041 4038 7 2 92 0 0see, no swp use, loads of memory free. not much cpu either. GPU is the bottleneck for the most part.
-
@dankcushions just saw your reply to me talking about memory management. I believe that I already said that I know its in ram already. The problem is not related to swap space either. I'm not even sure if swap space is implemented in raspbian. Its the other operations executing when the game is interrupted more frequently than it would as a 64 bit segment scheme. Those other processes, not the game, are accessed from and to the card at times while the game waits on them. Mario ran fine for me in the first place. If you do not want to try everything from the USB including the operating system then dont. I'm not going to point some things out to try to add credibility that I know what I'm talking about, but its you that's barking up the wrong tree. The experiment is simple, if you don't want to try running the operating system and games from the USB card to see what the difference is with both the operating system and games from the USB, then don't. But I'm not writing an entire text book about operating systems on a forum, if you want that than I recommend ' Operating Systems Internals and Design Principles 6th edition, by William Stallings' . And I'm saying that because if you don't put the time in to learn a subject, then parts of an explanation are just going to be misunderstood, forgotten, and the whole point is missed in the end. I'm currently taking 6 classes, and about to do homework. I was wanting to see if someone would be interested to try because performance does increase from USB 2.0, and I thought that someone would be interested in working that kink out. If you want to prove me wrong then the way to do it is by replicating what I said I did, running the operating system and games from USB, and compare the playability of the n64 games between the USB setup and the microSD set up. But not the microSD for the operating system and the USB for the games. Its a simple experiment that anyone can do. Its a noticeable difference. Its more to it then "the game is in ram". If you really want to know what is going on, which I doubt, then read and study that book I recommended. Its not as simple as a game sitting in ram.
Anyway, I solved the over heating problem. The vram needs to be lowered to 90mb or below.
-
The experiment is simple, if you don't want to try running the operating system and games from the USB card to see what the difference is with both the operating system and games from the USB, then don't. But I'm not writing an entire text book about operating systems on a forum, if you want that than I recommend ' Operating Systems Internals and Design Principles 6th edition, by William Stallings' . And I'm saying that because if you don't put the time in to learn a subject, then parts of an explanation are just going to be misunderstood, forgotten, and the whole point is missed in the end. I'm currently taking 6 classes, and about to do homework
i'm a computer science BSc (hons) graduate. good luck with your homework..
-
Has anyone looked into the potential benefits of ball bearings?
-
@dankcushions Yeah? Hons? That's cool. The picture of the linux application along with your response of the game being in ram made no sense as a response to what I said in the quote. I'm not saying that you are lying, but I have a very strong suspicion that you are. I could sort of understand if you typed that and missed something I said, and did not include that quote. But the quote with what you said tells me that you have absolutely no idea what I was saying, which should be very easy if you remembered your Operating Systems class, along with about 5 other classes that are in the BS curriculum and all involve basic things about processes, memory management, page sizes, and process sizes. Considering that you were in no way trying to help with the problem of over heating due to my choice in the secondary storage device, and instead trying to badly argue a point that you never made other than "I'm barking up the wrong tree"; I think you like pretending to know things that you do not. I think that you like pretending to know more than people that you didn't know before hand actually know what is going on. I do not think you have a BS in computer science (with hons), but I do think you're full of BS about computer science.
So good luck feeling like you're some one that you're not. Its not like you can't actually learn what you're pretending to know. This is what happens when you decide to call people out on stuff that you're the faker about.
-
@NastyButtler322 i'm not about to get my degree certificate from the attic just to win an argument online (although i'm slightly tempted now!). you'll find you encounter some resistance if you make bold claims about n64 tweaks you've made, especially without any supporting evidence (the plugins can show fps, and linux can measure realtime IO in a variety of ways) or details about your testing process. make a wiki page about it, even. isn't that part of the fun?
i absolutely encourage experimentation and theories, but with n64 emulation the bottlenecks are demonstrable and they're not anything to do with the storage device. my
vmstatoutput literally proves that. look into whatbi,boandwaindicate.also, this isn't the place for name-calling and bad attitudes, but i don't want to put you off experimenting. running everything directly from USB should provide several benefits in retropie. i encourage you, or anyone, to think of some good ways to benchmark it.
-
@NastyButtler322 I'm guessing running n64 must reach the temps near its throttling limit and the extra heat caused by a usb stick might just put it over. Those little heatsinks do little to prevent overheating. USB sticks do generate heat, some brands producing more heat than others. The case can also add to the heat. Tried a case that acts like a heatsink?
How about you provide before and after temps to actually see what's going on and not just assuming what the cause of the problem is.
-
@dankcushion you already won. You've got BS hons.
-
@Darksavior said in USB instead of microSD for the operating system causing overheating:
@NastyButtler322 I'm guessing running n64 must reach the temps near its throttling limit and the extra heat caused by a usb stick might just put it over. Those little heatsinks do little to prevent overheating. USB sticks do generate heat, some brands producing more heat than others. The case can also add to the heat. Tried a case that acts like a heatsink?
How about you provide before and after temps to actually see what's going on and not just assuming what the cause of the problem is.
Seems like the problem solved when I lowered the vram in emulation station to 90MB. But I haven't tested it much since then. It was doing it with every system that I tried to use shaders on. The N64 game play was running great, and did not cause over heating since I did not bother trying to use shaders for that system. I just mentioned that N64 plays well this way to give a reason to people so that they may want to try it and possibly have more help solving the problem, but it is solved well enough for me now.
Any cases you would recommend that act like a heatsink?
Also, do you know if there are any ammonia, hydrogen, and water filled heat sinks?
Wazzz up
-
@NastyButtler322 apologies, no. I don't have a pi3. I'm using a pi2. If I do get a pi3 in the future I will consider cutting one up like this guy:
-
@NastyButtler322 I've seen someone in these forums mention the flirc case for heat dissipation. The top portion of the case is aluminum and it has a small area sitting over the processor. This essentially turns your case into a heatsink with a large area to dissipate heat from.
-
@NastyButtler322 Speaking of water cooling, I like how this costs 4-5 times as much as the Pi itself:
https://modmymods.com/modmymods-raspberry-pi-mini-water-cooling-kit-mod-0171.html
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.