Nehalem demo

[chronodekar]

http://www.intel.com/technolog...next-gen/demo/demo.htm

This was being passed around my office and I thought some here may find it interesting.

I've not looked at the main site in a while, so if this has already been listed there, please forgive me for this repeat.

The flash is a big one (comes in little chunks), so I won't recommend anyone with slow connections to try it.


Enjoy! :beer:

 

[dguy6789]

Nice video.

 

[AdamK47]

The tubes sure do look zippy.

 

[Idontcare]

That is awesome. Watched the whole thing. Thanks for sharing your find!

Makes me hungry for desktop applications that will make use of a 4S nehalem system :heart:

 

[VirtualLarry]

Pretty neat. I didn't know about all of those new features yet, especially the things like QuickPatch failover mechanisms.

I suppose that's one thing to watch out for when overclocking, if one quadrant of your QPI bus fails to properly operate at that speed, the rest of the quadrants take up the slack, but your QPI bus speed could become slightly crippled.

We need a QPI bus-speed tester program to check for this.

 

[Idontcare]

Originally posted by: VirtualLarry
Pretty neat. I didn't know about all of those new features yet, especially the things like QuickPatch failover mechanisms.

I suppose that's one thing to watch out for when overclocking, if one quadrant of your QPI bus fails to properly operate at that speed, the rest of the quadrants take up the slack, but your QPI bus speed could become slightly crippled.

We need a QPI bus-speed tester program to check for this.

It is something I've wondered about in the past regarding ECC and on-die caches when overclocking. Surely you can end up with an OC that is stable but only because ECC is doing some heavy lifting with your otherwise unstable cache but we don't see it.

The downside to overactive ECC is that the effective cache latency is increased as the cpu spends time correcting the corrupt data, but so long as it does it successfully you and I never see a BSOD so we think our OC is teh bomb.

The bottom line is your observation is quite correct, wherever there be active error detection and correction in the hardware we need a stability program capable of detecting/reporting when these features are being utilized so we can determine if something we are doing (such as overclocking) is the cause to that effect. (and then using this feedback we can further optimize our OC to cause less of this effect)