USB instead of microSD for the operating system causing overheating
-
@NastyButtler322 You know you can edit the title to be relevant, don't you?
-
What you are saying makes absolutely no sense at all.
-
@AlexMurphy ive never seen a usb overheat and i have 2 hubs and 10 devices including a 1tb hdd running off of the 4 ports.
@NastyButtler322 can you explain how you have determined the ports are overheating?
-
@edmaul69 said in USB overheat:
Nonsense.
-
@AlexMurphy Sorry man, I didn't proof read it, and I typed this from my tablet which auto corrects things that I intended to be spelled the way I wanted, and my fingers are too big for the touch keyboard.
I edited this. I hope it makes more sense. I also thought I couldn't type a larger title, I updated that too.
-
@NastyButtler322 i use samsung sd cards and i kill the power all the time. Not one problem. I had issues with Sandisk and Kingston and some others that would corrupt all the time. But now i use a legit 64gb and 16gb samsung cards without a single problem.
-
@edmaul69 sorry. My ports are not overheating. Those are fine. The operating system is being booted and ran from a USB stick. The increase in data transfer speed to the main memory and the processor is causing the processor to overheat. The USB stick is six times as fast for the processor to read from than the microSD. So the processor waits on processes much less, and gets to work much more since it does not have to wait as long as it does using microSD for information to input.
-
@NastyButtler322 did you put a heatsink on your cpu?
-
sorry to say but you're barking up the wrong tree. even the largest n64 games are small enough to be loaded entirely into RAM. there's no benefit in faster storage speeds, except maybe the tiny amount of time it takes to load games.
I'm pretty sure that is due to the 32 bit operating systems memory management of a 64 bit game, the processes are smaller in between the calls to the next process and therefore has more breaks and loading then the intended use of the game on 64 bit processors.
:D
-
They can go entirely into ram. But the memory management system that the operating system implemints divides the processes up into segments. Once a process is complete, the process stops that, hands control to the operating system, the operating system either has another process loaded not related to the one that just was loaded, or it will load the process that the previous process needed loaded depending on the priorities that the operating system has determined. When the segments are smaller processes, then these occur more frequently than the larger 64 bit processes that a 32 but operating system would not allow. Even if all of the processes are loaded into ram.
Wazzz up
-
@NastyButtler322 the n64 emulator is compiled as 32-bit. there are no 64-bit processes
-
@NastyButtler322 also, processes are constantly being added and removed from ram. They are usually stored as segmented pages, if an operating system process needs to load, 60MB a second does noticeably make a difference from 10MB per second, the results are right in front of me lol I'm playing with it right now. A lot of pages are not even the processes themselves, they are references to other pages that lead to the absolute memory location. The operating system loaded into a faster interface while running other processes that read from that faster interface definitely make a difference.
-
@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.
Wazzz up
-
@edmaul69 Yeah.
-
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.
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.