Forum > Windows
V8 Optimized App
Jason G:
Looks Jolly good to me. The Everest benchmark you showed before , I think was faulty or there was a wrong setting, with a blue window did say "Single Channel DDR2-760FB SDRAM", So I think it is just wrong, the other things you show no problem.... If you think something about bios I'd be checking anyway.
Everything I can find on different ram configurations tested with with Fully Buffered DIMMS on similar systems (like the Mac Pro) is suggesting that the way you have it (dual rank, 4 slots) will show less than maximum bandwidth , but much lower(faster) latency. That is good :D
Fast Latency is more important for small random memory accesses (Like seti) , and high bandwidth is more important for database servers and stuff. (depending what they store )
so what you have will be the fastest combination for workstation / crunching use I reckon.
I think adding more sticks would increase bandwidth but raise latency too, making that more suitable for a high capacity database server that accesses big blocks of continuous data. (less suitable for seti / workstation]
All my opinions to be taken with a grain of salt, until you've worked out what's best for you ;)
If you can find a way to measure ECC correction errors, Like the Mac Pro Has, Then you can tighten the timing (latencies) until it squeals then back off a bit. Of course that depends on how much control you have to start with.
Jason
RottenMutt:
--- Quote from: j_groothu on 19 Oct 2007, 03:32:01 am ---Looks Jolly good to me. The Everest benchmark you showed before , I think was faulty or there was a wrong setting, with a blue window did say "Single Channel DDR2-760FB SDRAM"...
--- End quote ---
Good catch i totally missed it. I use to get 7000MB/s read in Everest, now i don't. I checked the bios and everything is set correctly, then i checked the DMI events and there were ECC errors:( I'm RMA'ing the board...
Jason G:
--- Quote from: RottenMutt on 19 Oct 2007, 10:21:45 am --- I use to get 7000MB/s read in Everest, now i don't. I checked the bios and everything is set correctly, then i checked the DMI events and there were ECC errors:( I'm RMA'ing the board...
--- End quote ---
LOL, the old 'When in doubt chuck it out" methodology. It will be interesting to compare a benchmark of new board against the data you have already, with everything else set the same. I have not seen measured anywhere the cost of the ECC errors on speed, definitely reliability though.
Was there indication whether they were "hard uncorrectable" ECC Errors ? Or were they "ECC correction events" ?
Gecko_R7:
--- Quote from: j_groothu on 19 Oct 2007, 03:32:01 am ---
Fast Latency is more important for small random memory accesses (Like seti) , and high bandwidth is more important for database servers and stuff. (depending what they store )
I think adding more sticks would increase bandwidth but raise latency too, making that more suitable for a high capacity database server that accesses big blocks of continuous data. (less suitable for seti / workstation]
Jason
--- End quote ---
Noticed your comment regarding latency.
So, on a Q6600 Quad for example, Seti would respond better w/ DDR2-800 @ CL-3 than cranking to higher bandwidth, say DDR2-1200 but having to run CL5?
Is this right?
Jason G:
--- Quote from: Gecko_R7 on 19 Oct 2007, 10:24:48 pm ---Noticed your comment regarding latency.
So, on a Q6600 Quad for example, Seti would respond better w/ DDR2-800 @ CL-3 than cranking to higher bandwidth, say DDR2-1200 but having to run CL5?
Is this right?
--- End quote ---
Conceptually I guess yes. Practically It would depend on what things you were using the machine for etc... Accessing small amounts of data spread randomly through Ram would benefit from lower latency (fast starting for a transfer) more than improved bandwidth (but slower starting). That "probably" makes general sense for non-server ram/mobos/buffered ram too, but as I see quoted here often "your mileage may vary".
That's why I have a problem with going by the bandwidth benchmarks as a performance guide. They would tend to use large blocks of data similar to streaming database [video] content or something like that. And these don't seem to make much mention of latency (access startup time) at all.
The statement I made was really regarding a specific combination of fully buffered Dimms on a Mac Pro similar motherboard. As I understand it (which may be wrong) These use a memory branching structure with serial links to interleave extra slots (giving a total of eight slots). Roughly understood, When these are all populated, the latency on each pair is increased by one (1) .. giving a slower start access, but more bandwidth due to interleaving structure.
With only four slots populated, in the correct combination, the latency remains at the original (fast value), but the bandwidth is less.
This may be all completely irrelevant for Q6600, which uses ordinary dual channel [not FB Dimms or branch interleaveing]. so should give the same latency whichever slots are filled [provided dual channel slot match is observed].
The conceptual argument/possibility of lower latency being preferred for seti type applications remains though (as you point out). [And you or I probably wouldn't be the first to suggest that backing off on amount of, and bandwidth of, ram but going for fastest(lowest) latency, might be a good idea for a workstation / cruncher]
Jason
[PS: As a guesstimate , if 3 cycle latency and 400Mhz (DDR2-800) is 7.5ns , and 5 cycle latency at 600MHz (ddr2-1200) is 8.33ns then a small access will start about 10 % faster with the low latency ddr2 800.
So if I was just doing seti and checking my emails I'd go the ddr2-800 low latency,
If I was editing video, I'd go for the higher bandwidth ddr2-1200. ]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version