What are the Ram and Cpu requirements?

[mseibert16]

I think the problem with my computer is that aotbt uses so much ram and cpu that i cant keep up with it. this causes it to glitch out and run out memory. Can someone tell me the requirements for smooth game play so I can play the game well.

[rcmaehl]

I run on a 3.2GHz Quad Core with 8GB ram and 2 GPUs (Nvidia GT 260 and Nvidia 9800 GT)

[disconsented]

Just fyi:

1. GHz is not a direct indicator of preformance
2. Core's are not a direct indicator of prefomance
3. Memory isn't a direct indicator of preformance

[Kr0nZ]

 

Just fyi:

1. GHz is not a direct indicator of preformance
2. Core's are not a direct indicator of prefomance
3. Memory isn't a direct indicator of preformance

 

 

not true,

 

3 ghz is going to run alot better than a 1 ghz

multi core(64bit) is going to run alot better than single core(32 bit)

4 GB of memory is going to run alot better than 1 GB

 

That said, Im running the pack on a laptop with 2Ghz, 4 GB memory, integrated graphics 128mb

Not great but playable

[disconsented]

not true,

 

3 ghz is going to run alot better than a 1 ghz

multi core(64bit) is going to run alot better than single core(32 bit)

4 GB of memory is going to run alot better than 1 GB

 

That said, Im running the pack on a laptop with 2Ghz, 4 GB memory, integrated graphics 128mb

Not great but playable

https://en.wikipedia.org/wiki/Megahertz_myth

Multi Core's only increase performance if the program is designed to take advantage of it

Program's will not use anymore ram than they need

[Kr0nZ]

https://en.wikipedia.org/wiki/Megahertz_myth

Multi Core's only increase performance if the program is designed to take advantage of it

Program's will not use anymore ram than they need

yes and if you are using multi core, you should be using 64bit OS and 64bit Java, which is taking "advantage of it"

[disconsented]

yes and if you are using multi core, you should be using 64bit OS and 64bit Java, which is taking "advantage of it"

That would be fine if minecraft was designed to take advantage of it.

Notice how I said "direct indicator of performance" instead of doesn't influence performance

[Loader]

At least it was an attempt to help though, right, and it gives an idea of very roughly what the pack takes to run nicely (and run the server in single player, I assume?).

 

I can tell you that it seems to take anywhere from 3-10% of my cpu cycles to run the server with a low pop (usually not more than 6) on an i7-3770k, and playing SP I can't seem to break 20% (spawning lots of villagers, lots of zombies, a wither to blow up blocks and shooting at anything interesting with the explosive dubstep gun) so the client doesn't seem very processor intensive, a processor that has a fifth of what I have available to use should be all but the very cheapest or old processors.

 

Graphics are harder to get results for, but I seem to be able to sit consistently at 25-30% use in the maximum on a Radeon HD7870 (I don't know how much of this is just the pack though, this includes all the overhead from windows and anything else I have running).  Still, it gives us a baseline.

 

Let's assume the overhead is really massive on your CPU and the total utilization is about a third of mine, then anything faster than Intel's Pentium G2140 should be OK even in the worst case the way I run it (check here),  The graphics card is a bit higher but you could turn things down, a 260, 660 or 760 (not mobile version) should be fine, and that's corroborated by what rcmaehl is saying (the 9800 alone would have to have some settings down a bit but would still be fine).

 

 

Briefly on this tangent;

With regards to MHz, Kr0nZ, that's only true if everything else is can be held to be the same (the exact same architecture).  I would be happy to underclock my processor to 2GHz to compete with a quad-core cellphone in zipping and unzippng, if you'd like to try it for real make a 1GB compressed file of some kind to try it.  That misunderstanding is the same thing that kept the Pentium 4 alive so long ("why is my dual core 4.3GHz Pentium D half the speed of that Core 2 Duo 2.6GHz?  These results must be wrong!")

 

32-bit vs 64-bit is less big of a deal than you'd think (it's mostly useful for allowing the operating system to address more RAM so you can have more applications running simultaneously), most programs, games in particular are still piss poor at dealing with large quantities of RAM, and don't benefit from the 64-bit CPU calculation savings.

 

Since we're talking about Minecraft here, the third one is actually the opposite of true - the more RAM you allocate the more work the CPU has to do, so if you're limited there already then you can actually slow things down greatly by allowing it more RAM.  There's a sweetspot on every system for every pack between stability and speed.

[AcesOyster]

Really Loader? That surprises me (and I am by no means a computer scientist), but I would have thought that only actually allocated space on the heap would slow down the CPU, and that having a huge reserved empty block would be fairly unimportant? Please tell me more (:

[Loader]

As I understood it a huge reserved empty block is fine, it's when you've got a bunch of stuff loaded in already that then doesn't get cleared (and keeps getting calculations run on) because you've got enough space available that it just loads new stuff into more.  Minecraft is a bit peculiar in that it really hates unloading chunks (the strange thing there is that even if they're not active it keeps them in the game logic loop so they slow everything down when you get enough of them to exceed the 50ms gameloop budget).

 

I could be not current, but it certainly used to be the case - I haven't actually done a test on it in about a year but you don't see people running 8-16GB anymore so I had just assumed it was still the same deal and hadn't changed.  The opposite is also true, of course - if it can't assign something memory and has to swap to disk then you get the lag spikes and slowdowns that we're all so familiar with.

 

Most of the threads I can find on it for examples are for Bukkit servers, so it might've been a Bukkit specific thing (I was using bukkit back then when I tested all this) but the common factor in all of them is this: if there's more RAM available, there can be more stuff allocated within that space - the more stuff that's actually loaded and in use the higher the CPU usage will be.  That's pretty much exactly in line with what you've said you thought would be the case.  I'm pretty sure the server picks what chunks you have to keep updating on, so on the client it'd only be an issue if you're playing singleplayer (SMP would still mostly benefit from more RAM).

 

If you're really interested, I guess I could test it properly and let you know if it's still the case, I just wanted to point out that it isn't so cut and dried as with most games where the loading in and out of textures and models are the majority of RAM usage (and with those it's true that more is better).

[AcesOyster]

Makes sense. I imagine that 1.7's streamlined code probably addressed that issue, but obviously we aren't there yet. Reasonably the best performance point on a modern CPU is memory cache size. Unfortunately chips with larger cache cost a hell of a lot more. At least as far as a game that uses as large an amount of RAM as modded minecraft.

Edited February 19, 2014 by AcesOyster

[plowmanplow]

Also, keep in mind that it is all well and good to digress on the theory of how resources get allocated/consumed/etc. but when it comes to MC (and specifically Modded MC with texture packs) any time you allocate someof these precious resources to one thing you'll be preventing something else from using them. While it is true that MC doesn't do anything specifically 64bit, but running 64bit Java on system with a decent amount of ram will let you allocate more than the paltry 1G in the launcher that a 32bit Java/OS will allow you to do. Toss in a large texture pack (big packs with lots of mods with textures can see the resource pack exceed 100M in a hurry) and your memory usage can easily double over what you have set in the launcher. Assigning too much memory to the client and the OS may start to starve especially if you have a lot of other things running at once. I'm running 8G of memory with 1.5G set in the launcher. Using a modpack with 135 reported mods and a 100M texture pack and the Java process running MC can sometimes exceed 3G. Try that same setup on a PC with 4G of ram and you are going to have a bad day.

 

Without putting it in really technical terms Java kind of acts like a gas in that it will expand to take up all the available space. If you set your launcher to 4G you better believe that before long it will be using the entire 4G of space. The Java garbage collection threads, which is what goes through and cleans up the "bloat" that isn't needed anymore can really chew on CPU cycles if you have the initial/max allocation set too high.

 

A lot of the folks coming on here have zero understanding about how the internals work. I'm a huge proponent of "teaching a man to fish", but I would give these recommendations to the uninitiated:

• Set your launcher to the absolute minimum amount of memory that will allow you to successfully run your chosen pack(s)
• Keep an eye on the actual amount of memory that task manager reports your MC/Java process to be using. If it gets to within 1.5G of your actual physical memory (on Windows) your system  will likely start to run poorly. The more things you have running will require this gap to be wider. If you have a browser with half a dozen or more tabs open and a few explorer windows you might want that gap to be 2G-2.5G or more. Start adding in Photoshop, SSH windows, Excel, Winzip/7zip and you'll fill up 8G in a heartbeat and start bulging at the seams.

Y'all have given out some great details and information. This is just my two cents, for what it's worth.