Sign in with
Sign up | Sign in
Your question

GA-MA790X-UD4P & 4x2GB G.Skill DDR2 1066

Last response: in Motherboards
Share
January 12, 2010 7:02:33 PM

I recently upgraded by adding another 4GB (2x2GB) G.Skill memory. However the system will not run the memory at any higher than 800MHz. Even manually settings the speed, multiplier and voltage doesn't work. Once the system is set @ 1066, the system hangs at the BIOS splash screen. 8GB runs fine @ 800MHz and the BIOS displays the timings @ 1066, but refuses to run @ said speed.
Is this a hardware limitation? or some BIOS setting I have overlooked?
a b } Memory
a c 78 V Motherboard
January 12, 2010 10:49:12 PM

Based on the adjustments you made and the results, you may have to trade-off a little speed for the added memory capacity. Most boards cannot run @their advertised speed with all RAM slots populated.
m
0
l
a b } Memory
a c 177 V Motherboard
January 12, 2010 11:05:34 PM

Most systems with AMD 7xx chipsets are limited to two DIMMs at 1066 or above...
m
0
l
Related resources
January 13, 2010 1:08:27 AM

Thanks for the feedback... that is Terribly Disappointing... What would you all suggest I do? Run 2x2GB @ 1066 or 4x2GB @ 800?

From Sisoftware Sandra, it shows my memory performance has dropped...
m
0
l
a b } Memory
a c 177 V Motherboard
January 13, 2010 1:48:18 AM

Definitely, run 8 @ 800; memory speed is vastly overrated (to the great finacial benefit of the memory companies - especially since the advent of the 1156/1366 platforms), and the only place it really shows up (unless you transcode a lot of video) is in 'synthetic' benchmarking - and that's why it's called synthetic - it doesn't relate to the real world. What matters in the real world is latency, as your system is almost never doing long sustained reads/writes from/to main memory... The speed-up from hardly ever swapping (which, think about it - involves a mechanical transaction) will far outweigh any benefit from higher raw memory clock speed!

(From a previous post...)
Quote:
...people often misunderstand the actual quantitative speed improvements inherent in faster ram... Here's the mistake: 1066 is 33% higher than 800 ([1066-800]/800 = 266/800 = .33), so 1066 RAM must be a third faster than 800, right? Not so! You have to figure in latencies. Most 800 will run at 4-4-4-12, while most 1066 is rated at 5-5-5-15, or, even worse, 5-5-5-18. Here's how to appraise the situation in reality: at 800 MHz, a RAM bus cycle is 1.25 nSec long (1000/800); at 1066 (1000/1066), it is roughly .938 nSec long - so, with an 800 stick at a 4 average latency, a RAM bus transaction takes 1.25 (cycle time) times 4 (latency), or 5nSec, while at 1066 it is .938 (cycle time) times 5 (latency), for a transaction time of (roughly) 4.7nSec - so you see, by going to nominally 33% faster RAM, you actually gain three tenths of a nSec per transaction: .3 (transaction gain) over 5(transaction total) = .06, for a real-world improvement of 6%...


(...from another...)
"There is a place where high speed, versus low latency, will be an advantage - any operations that require large, sustained, reads from and writes to RAM - like, as I mentioned, video transcoding... I always consider my 'pass/fail' system stress test to be: watch/pause one HDTV stream off a networked ATSC tuner, while recording a second stream off a PCI NTSC tuner, while transcoding and 'de-commercialing' a third stream to an NAS media server... But, for the vast majority of people, for the vast majority of use, this is not the case. What's going on behind the scenes: the task scheduler is scurrying around, busier than a centipede learning to tap-dance, counting 'ticks': ...tick... yo - over there, you gotta finish up, your tick is over, push your environment, that's a good fella; oops - cache snoops says we've got an incoherency - grab me a meg for him from over there; ...tick... you - get me the address of the block being used by {F92BFB9B-59E9-4B65-8AA3-D004C26BA193}, will 'ya; yeah - UAC says he has permission - I dunno - we'll just have to trust him; damnit - everybody listen up, we've got a pending interrupt request, everyone drop what you're doing, and you - over there - query interrupt handler for a vector - this is important!!! ...tick.... This is why (aside from the obvious matter of access architecture) that swap files are optimized in 4k 'chunks'... And the most fascinating (scary) thing about it all, is that, at some synaptic, neural level, we're doin' the same thing! (...though, the older I get, the less dependable my interrupt return mechanism is - I repeatedly find myself at the bottom of the basement steps, wondering "now what did I come down here for?!" )
m
0
l
January 14, 2010 1:22:19 PM

Thanks! Informative (honestly some did go over my head) but I definitely get what you're saying. Well 4x2GB ftw. Something else that stuck in the back of my mind is most 'casual' use of PCs never really require the amt of bandwidth these CPUs are able to push. Synthetic 10G vs. 12G, chances are i'll never hit the ceiling.

Thanks for the feedback, it's greatly appreciated.
m
0
l
!