Nehalem Preview - Intel Does It Again

[Guest UlfB]

Hi all,Nick, please forgive me for posting this stupid question. Your'e the top gun hardware guru!Question 1: I guess that this new Nehalem cpu family will require a new slot? New mobo needed to run this sun of a gun?Question 2: Will future high end mobos have the intelligence to support newbies, like me, to overclock without bothering about cpu voltage, dram voltage, fsb frequency and memory timings? I want a BIOS that doesn't make the overclocking so time consuming.Ulf B

[jwenham 1]

I can answer number 1. Yes you will need a new MOBO and the slot config is different as well. The new slot is a 1366 pin. As far as for overclocking I think there a some good boards out there now that sorta help you out but you still will have to have some good knowledge as how to do it. I would be interested to know if there are any good books that teach you how to OC and word the terminology in laymans terms.

[Guest UlfB]

jwenham,Yes, a good book that translates the tech terminlogy in laymen terms would be a nice thing. Also a translation to the labels used by different BIOSes. The different abbreviations are confusing.Obviously there is a market for explaining OC:ing in plain english and with use cases specific to mobos and cpu:s.Ulf B

[jwenham 1]

ULF B, I found this, not sure if its quality of info but may help get some basic knowledge.http://www.xbitlabs.com/articles/cpu/displ...e-oc-guide.html

[Guest UlfB]

Thanks, seems like a good article on OC:ing :-)Ulf B

[Noel 4,497]

That's exciting stuff. It bodes well for experiencing a outstanding boost in thruput performance and efficiency over my Penryn at 4Ghz. By the time I do my next upgrade there will be a signficant reason to do so.Noel

[Guest fsxmissionguy]

"You could always up the value in the config file as your Hardware capabilities increased ..."Or, you could simply hide the higher settings behind an Advanced System Configuration within the GUI, or with a command line switch such as "/screamingfastsystem" that changes the slider values before loading the GUI.Either way, the GUI can say: "Caution: Advanced System Configuration items require multiple processors, faster video card ..." etc.There's nothing really wrong with putting the settings in the GUI, it's all in the presentation and the proper setting of expectations.If you set expectations high, and then fail to meet them, then you create disaster.If you set expectations low, and then exceed them, you create positive buzz and massive sales increases.Marketing 101.The very last software group that needs to "tout" anything is Microsoft ACES. They should always keep a low product profile, and let everyone else do the ooohing and aahhhhing.The product is THAT good.My 2c.Cheers,

[Guest D17S]

It was interesting to observe that Quickpath buss <> Ram buss latency (our old FSB <> Ram buss) was only impressive relative to a standard Penryn setup. The Quickpath <> rambuss latency was exalted to be an uber-quick 46.9ns. That's pretty good, but we're doing that now with Penryn uber-rigs. Heck, even my plebeian DDR2-800 @ 44412/tRD6 gets 57ns. (Note: all this latency stuff was recorded with an Intel "good board")Also notice Quickpath runs at 133Mhz (and goes unstable at 140). O/Cs (so far) will be based on increasing multipliers and Not based on increasing QP buss speeds. That lends credence to the premise that our current FSB speed is a non-player in the big picture. QP proves that 133Mhz provides plenty of connectivity for ram running at up to(DDR) 2000Mhz. The latency (delay time) of the transfer event between the Quickpath buss and the Ram buss will Still be a final determiner. For instance at 133Mhz, each cycle is 7.5ns in duration. Woah. That's huge (It's only 2.5ns @ 400Mhz). That means each tRD notch has the capability of reducing latency 7.5ns. With our 400Mhz FSB, Intel only uses every 8 to 12th cycle (tRD 8 - 12). That means at 2.5ns per cycle, a tRD of 12 builds-in 12 x 2.5ns = 30ns of latency. That ~ 30ns is NeeDeD for tRD to do its loading job. Quickpath needs it too, but provides that data loading-delay time in a slightly different way. At 133Mhz, each cycle is 7.5 long. So Intel (I expect) has set tRD at ~ 4x. That would be 7.5ns x 4 = 30ns. Same deal, just using a slower Front side (oops, I mean Quickpath) buss. The real promise is to optimize the tRD function. For instance, I can run a tRD down to 6x on my P35's 400Mhz FSB. That tRD creates a latency of 2.5ns x 6 = 15ns. That's right on the edge for me. If I try to push the tRD loading process any "tighter," my dockmaster (tRD) has a heart attack and just keels over (the system just freezes). My poor ol' P35 just cannot handle a 2.5ns x 5 = 12.5ns FSB <> Rambuss loading increment . . . but the later and greater Quickpath really should . . . we hope. Again, if Quickpath's buss speed is 133Mhz, then its cycle legnth is 7.5ns. Quickpath really should be able to deal with a tRD of 2: Because 2 (tRD) x 7.5(ns) = 15ns. I can do that now with an old clunky P35. That 46.9ns at DDR1066 really suggests a tRD of 1 (at 7.5ns drop from a more normal 15ns tRD related latency). That be good. If they can maintain this tRD as DDR speed ramps up, that will be very, Very good. However if so, tRD related optimizations will no longer be available. Intel has already used it all.

[Noel 4,497]

Sam, what's your best guess on how better optimization for multi-core platforms will play out, in FS11 that would be . . . ?I'm guessing ACES will max out what can be accomplished in the multicore environment, as there will be sooo many users with at least dual core platforms. I'm hoping my Penny QX will have some life extension thru this mechanism. I know one thing, I am quite happy even with my crippled refurbed P5E. I hope the P5E3-Prem & memory don't have issues. I need to re-RMA this thing as it has weird sound problems the other guy didn't have, and it's only in FSX so far. I am going to start fresh again, I hope this week if the memory comes in. What is the best commercial aircraft in terms of performance in FSX? I use the PMDG 737 & 747 in FS9 and love them, but if another line is perhaps more effecient then I'd consider a switch.

[Guest Nick_N]

By FS11 8 or more cores (on a single slug) will most likely be the norm and this time Aces is not going to make the same mistake which happened many years ago when FSX was on the drawing board... they will be looking at how current and future technology can be exploited correctly and that is what Phil was saying with the term 'WAVE 2009' and I am sure what he meant was to stay tuned for more info as they get into that part of development.There is one downfall to developing such a complicated system and that is because once a dev path is selected, to go backwards just because something a year+ out changed, can not be done.. therefore they must be careful and look at things from a hardware engineering perspective perhaps with help from Intel/Nv/AMD/ATi for what is to come over what is available. Then there is the reluctance of those camps to deliver that type of information so there is a defined 'cut off' to what they can develop for and must commit at a certain point regardless of a change that could take place by the time the product goes to market.That is where, IMHO, they need to start looking at the result of their work well in advance of its release to make sure they are not designing based on "the hardware will catch up to us eventually" I don

[Guest D17S]

I believe improvements will come on 2 fronts. The first is multicore optimizations. That is where pure 10X-ing will occur. I'm at 4 cores now. Nehalem will "tock" down 32nm, then Sandybridge will "tick" in with another refinement to the Quickpath/Core2 "system." 32ns will allow lower power use, lower cost and More Cores! Don't be surprised to see 30+ cores. There's my 8X from my little ol' Q now. But another front will be progressing. Here's where the other 2X will come from. It appears we have about run out of latency room. That 133 FSB really told a story. Intel has reveled their projection of the need for increased bandwidth by removing all the (now recognized) transfer capacity excess now available by our current FSB speeds. They don't need it now . . . and are admitting they will not need it in the (near ~ 5 year) future. Transfer latency is near "best available" with an implied (final) tRD of 1 or 7.5ns. The rest of the "mechanical" process will be up to the ram modules. But still, consider this at a (then) widely available 2000Mhz ram speed (if each 100Mhz continues to = 1ns): This speed will take the latency down to ~ 47ns (Nehalem's current, with DDR1066) - 10ns (1000Mhz ram buss increase) - 7.5ns (one more increment of tRD) - 2ns (gotta get a bit of CL!) = 27ns latency. At best, we pick up another 20ns. That's a non-event now and it will be a non-event with Nehalem. This Quickpath / Latency connection that promises increased performance is a total bust. The improvement Is Not There. There's gotta be something else. The second front it Not about latency. The mechanical transfer system has been tweaked and poked and optimized about all it can be . . . actually, in my P35 - Right Now - with DDR2-800 memory! I'm at ~ 57ns. Another 30ns is going to save the world? Gotta be something else. All this uber -memory tweaking was mainly a learning exercise. Now we're ready to move on to a more likely "next step," Nehalem's real potential . . . and it will have NothinG to to with an on-die memory controllers or a Quickpath FSB morph. These mods are simply about using available real estate to make the part cheaper to build. The NB/FSB system has Massively more capacity than Quickpath. Namely, 500Mhz/133. 5 to 1, or 'bout 5 times the capacity? I think so. It seems that Intel's engineering staff may now be ready to move on to using this tweaked-out "mechanical" transfer system MoRe Effiently. --- That's the second front --- . This kind of thing got Intel a 20% clock for clock leg up on AMD with the Core2 design. Let's hope they can get another 20% on themselves, but it's still wait and see time. We'll see. The Only other serious airplane out there is the LVLD 767(X). I don't fly it, but It has the same horsepower and thereby the same requirements at PMDGs 744X. FS9 is still the platform of choice for technical flying. The biggest hardware brass ring is multicore optimization. I expect the entire software world is chasing that holy grail . . . cuz it Really Is the Holy Grail. Data loading optimizations will be important too, but I expect the multicore capable will be the biggest boost. We'll see 'bout that too.I just swapped in my rma P5K and it did Nada for my onboard sound problem . . . but the new board blue screened 3 times. They're gettin that one back. If you are starting over use this software install sequence. I'll by a $10 sound card before I start over. But as long as you're doing it . . . From Asus:"Dear Sir/MadamIf the troubleshooting below does not correct the issue there is a good chance the cause is a hardware failure of the onboard audio controller. (editor: Yea, right!) Please start by getting the latest audio driver from http://www.asus.com.tw/support/download/download.aspx.Completely uninstall the driver you have and reinstall the new driver. Make sure to remove it from Device Manager AND from Add & Remove Programs.Next, clear the system c-mos memory following the procedure in your manual. Make sure the power AND the battery on the motherboard is removed before shorting the CLR RTC solder points or jumper pins.Also, please make sure that if you are using AC 97 Legacy Audio that your front panel audio connector on the MB is connected and being used, if not used, has the return jumpers in place from the B_LINEOUT to the LINEOUT for BOTH the left & right channels. If the front panel audio is in use, please remove it from the header connector and place jumpers here for troubleshooting.Make sure you have a FRESH install of your OS on THIS motherboard and that the drive was partitioned and formatted on this motherboard. Make sure that you install the most recent drivers in the following order:1) Chipset/Motherboard drivers (Example, VIA 4 in 1's for VIA chipsets, Intel INF and Application Accelerator for Intel chipsets, Etc.) Do this BEFORE loading any other driver!2) Latest version of Direct X.3) Latest Video Card drivers.4) SCSI/ATA drivers5) Lan/NIC drivers6) Modem drivers, then any other drivers7) Finally, install sound card drivers LAST!Please call our phone support center at 812-282-ASUS if you need further troubleshooting assistance and our RMA Deparmtent if you need to send that motherboard in for repair at 510-739-3777 opt. 2Best Regards,Tim P.Asus Tech Support(812) 282-ASUS":Good luck.

[Guest Nick_N]

Right now it

[tfm 169]

Yes, but apparently "Cinebench shows us only a 2% increase in core-to-core performance from Penryn to Nehalem at the same clock speed. For applications that don't go out to main memory much and can stay confined to a single core, Nehalem behaves very much like Penryn."Thus, leaving multi-threading aside (as I believe 8 cores rather than 4 will make no appreciable difference for most purposes in FSX), the real gain seems to be in memory management, not raw number crunching.I gather from those who know about these things (Nick_N & Phil Taylor's blog) that FSX is in the category of application which "goes out to main memory much". So hopefully we will see SOME improvement with Nehalem. But presumably FSX's performance is not by any means wholly dependent on memory access. Surely raw processor power counts too. And it is this bit of the equation that - to my mind - looks a bit wobbly based on this article. Still, I suppose it's idle to speculate. It seems that no one even knows for sure whether Nehalem will ship with significantly higher clockspeeds: the article I posted a link to the other day said the clockspeeds would be significantly higher; but it was almost immediately contradicted by another one which said that Nehalem would ship at 3.2GHz tops. Fingers crossed.Tim

[Guest Nick_N]

Those benchmarks were on a crippled platform tooEarly BIOS, early board = early figuresFrom what they are showing ,.. its all good

[Guest D17S]

I'm only cautiously optimistic too. If it's about memory data flow rates, we're in trouble. Nehalem was only able to achieve latencies in the neighborhood of what we've already seen (locally actually). The results we saw here were entirely unimpressive, an ineffectively arguable 5%(?) or so (even now, watch the fur fly!) And FYI, those Nehalem memory latency runs were Not on that crippled 3rd party beta board. Anand swapped to a clean Intel board for those (most) critical runs. Our only 'core on core' hope is data management optimizations. Like the 20% Intel's Core2 got on the Athlon back then, if they can do that again (on themselves) that'd be nice. However consider that core on core, the Athlon is still a player. The Core2's real run-away from AMD was Clock Speed and Price. The Big Dog will Still be the raw horsepower of More Cores . . . and more to the point, apps that can use 'em.