User:RhythmicDaze

Short Bio
Guten Tag! When it comes to me, I love tech. Since grade school, I've always been fascinated by computer hardware and software, finding ways to tweak and meddle with that of which could probably be left well alone (in a working state). Fixing computers and game consoles, sometimes other electronics and appliances, is what I love doing; that's my fun! I'm easy to get along with, patient and forgiving, so you'll never have me yelling at you for a wrong edit or an article not being formatted the way I prefer. Respect is above all the most important to me, and you'll always be treated fair by me.

As for my part in the community, I started helping out here in March of 2013. Mainly, I maintain the Hardware performance page. There, I make sure that users can make proper comparisons between their hardware and user-posted results by making sure the information they add is correct and formatted for readability. It's my first for Wiki editing though I hope my contributions go a long way towards benefiting those who come to this Wiki.

I make editing mistakes too. In that case, if you have tips for future editing based on previous edits I have made, please let me know through my talk page, User talk:Bb 20, or through an email.

I hope you found this reading enlightening! Have a great day :)

Pages I look after
Here's what I tend to:
 * Hardware_performance
 * Hardware_performance/create
 * Hardware_performance/entries
 * Hardware_performance/intro
 * Hardware_performance/nav
 * Template:HardwareEntry
 * Template:HardwareEntry/doc

To Do
Hardware_performance:
 * 1.9.x
 * [X] SSD's must be listed with their capacity.
 * The Samsung 850 EVO 128GB and 256GB models have different transfer speeds as per their capacity. The higher the capacity, the higher the transfer speeds, typically. We don't need this for HDDs or SSHDs.
 * [X] iGPUs/APUs, GPUs and CPUs should list their frequencies when overclocked, but not required when at stock freqs.
 * Not all users list their devices freqs when asked, so we assume they are defaulted anyway. As long as they list the device model then we can gauge the performance from there. (Should also save a considerable amount of page bytes!)
 * [X] Comment lengths may be increased if the above is enacted.
 * Suggested extra words could be up to 'two' for a total of 17 words.
 * [X] Change seed from "Hardware Performance Test" to "forest".
 * I get the feeling that not everyone types it in right when generating a world; not putting in a space, or mistyping.
 * We NEED an area like this where: we have low framerates, and an open area where we can see the framerate rise. A mix of these two in one small area will do us very good.
 * [-] Include a cut-to-the chase tutorial on benchmarking. Can't link any videos as per rules :(
 * No mic audio, include only the required steps. Include posting your entry?
 * [X] Recommend setting gamemode to Creative as we don't need to be bothered by any hostile mobs, and we get to the co-ords faster.

Machine specifications
Acer Aspire V3-571G:
 * CPU: Intel Core i5-3210M, 2.5GHz
 * RAM: G.Skill F3-1600C9-4GRSL, DDR3L 1600MHz CL9
 * iGPU: Intel HD Graphics 4000, 350MHz
 * dGPU: Nvidia GeForce GT 630M, 2GB DDR3
 * Storage: Samsung 850 EVO, SSD 120GB
 * Optical: Caddy - TOSHIBA MQ01ABD100H, SSHD

Intro
I have always been interested in tweaking software to have it work faster for me. Overclocking, Windows registry editing, optimization utilities, ect... Those are the types of things that I like to play around with. This nice thing about the Nvidia Control Panel is that you can have profiles per executable that contain different options for how the graphics drivers work with that program. Here, I will show you some of the effects of these profile options when coupled with javaw.exe.

Testing Methodology
Currently, I am using Java JRE 8 to do these tests. However, performance is very similar to that of Java SE 7 Update 40. Also, Fraps is being used to collect these figures. The reason for this is that when you have the debuging overlay enabled while in-game, your FPS drops by a good few percent, a lot of times for me it drops by ~100FPS!

NOTE: Each test below was recorded within 60 second period.

If we calculate the percent difference between the average number of frame for both of these results then we come out with a 18.53% FPS difference! I call that a hit, folks.

Results
NOTE: Each test below was recorded within 120 second period.

Best Settings
Max pre-renderded frames = 4, Power management mode = ON, SLI rendering mode = OFF, Thread optimization = OFF,

These combination of settings above should give the player the best performance overall.

Conclusion
Changing Nvidia Control Panel options is something you will want to look into if you want to squeeze more performance out of your machine. This is great for if you can't immediately upgrade your hardware components, overclock or if your machine can't be upgraded for that matter.

Intro
This series of tests will determine if low RAM frequency, or and overclocked set of DIMMs for that matter, has any bearing on Minecraft's performance. I'm putting this in here for all you people, but the idea for doing this is to help me figure out if this information belongs on the Hardware Performance page or not. That is to say, just make things more organised, easier to understand and compare against/with without all sorts of useless information! I will be doing a series of tests similar to that of what I did above with my Java experiments.

A note before preceding!
I've mentioned this before, both in my previous Nvidia tests and on the Hardware Performance page, but make sure that when you are benchmarking to not use the debugging HUD whenever possible! The reason I say this is right below:

NOTE: Each test below was recorded within 120 second period, using the same methods of testing as on the Hardware Performance page.

Again, the FPS hit is big, some 21.49% in fact! This is why it is a good idea to use a program, such as Fraps for instance, to collect the frame rate for you. When I talk about consistency, this is a great example of why the same settings for everyone benchmarking Minecraft matters.

Testing Methodology
With the same testing methodology as written on the Hardware Performance page in mind, the only differences as to how I collected these result are as follows:
 * Only used default window size
 * I could have done these tests at 2560x1080 or with a maximized window, but I felt that the higher the frame rate I had for each result and using that to compare against other results I created would yield more accurate percentages .. if that makes sense. Also if someone wanted to quantify my results with similar hardware then they wouldn't be restricted to having to use my monitor res to get the same results (one less thing to worry about).
 * "Facing: north (Towards negative Z) (180.0 / 0.0)
 * This ensures I will always have consistent results! I should just get everyone to do that, ja? :P
 * Always day
 * I didn't want mobs like Zombies and Skeletons suddenly appearing around me should night come, which could potentially affect my frame rate. (That requires testing out though)

Results
Curiously, when I hit 1600 and 1866MHz my frame rate went down. Not sure what happened there, though it looks like the sweet spot is 1333MHz for Minecraft. I'll follow up with more benchmarks (in time).



NOTE: The average frame rate and number of frames drawn per 120 seconds match-up, which in turn means that frames drawn were consistent.

Conclusion
In the end, and I've seen this before with other benchmarks, when I hit 2133MHz I got the same performance as 1333MHz. This means that beyond this there is likely not benefit to amping up your RAM frequency. Although, it looks like increasing your CPU frequency or multiplier can at least do some good!

Hypothesis
Minecraft is stored on a data storage device in a folder called ..\.minecraft where, by default, all your launcher profiles and worlds are saved to. When you enter a world, Minecraft loads the chunks in a radius around you until the task is complete or until you move in to an area where no chunks are loaded and need to be called forward. If you stay in one area, no more chunks need be loaded, however, these chunks are updated frequently by whatever is within them be it mobs or moving liquid (I'm sure you can fill in the rest). What I currently believe is that loading a chunk is costly in terms or I/O, so loading a chunk or chunks and waiting until the task is complete, as opposed to a less costly chunk update or saving a chunk to that drive.

If this is so then:
 * there will be less I/O requests by the drive,
 * less I/O requests means more time and resources for the CPU, RAM and GPU to drive the game graphics ending up in peek frame rates,
 * the drive, being used much less frequently, should not impact the frame rate during a benchmark at all.

Benchmarking
Setting a baseline for these tests, I followed the instructions on the Hardware Performance page to see what frame rate I would receive when using an SSD. Then I compared that to other drive configurations. Here are the results:

SSD (SATA, 6Gb/s):
 * Windowed = 73-119
 * Maximized = 50-93
 * Fullscreen = 62-93

SSHD (SATA, 5400rpm, 6Gb/s):
 * Windowed = 74-125
 * Maximized = 61-97
 * Fullscreen = 63-97

HDD (USB 3.0, 7200rpm):
 * Windowed = 74-119
 * Maximized = 29-94
 * Fullscreen = 63-95

HDD (USB 2.0, 7200rpm):
 * Windowed = 77-121
 * Maximized = 60-96
 * Fullscreen = 53-96

Conclusion
From what I gather, once all your chunks are loaded, all the load is on the CPU and GPU, not the storage device. I can safely say for myself that the storage device really isn't a main requirement for our benchmarking, but it can remain optional for the moment.