Archived

This topic is now archived and is closed to further replies.

Chuck_B

Northbridge and Southbridge BIOS Settings

Recommended Posts

I've overclocked my processor and voltage settings in my ASUS bios no problem where my E8500 is running at 4.15 ghz on air, but I've left the Northbridge and Southbridge settings at "Auto" basically because I can't figure out what to do there.Can someone explain to me how the Northbridge and Soutbridge settings affect what I'm doing and where I should have them set in the bios? I just don't get it, and the manual is no help. The bios' "Auto" setting is working just fine apparently, but I'm always looking to tweak out just a little more if I can possibly do so.I've got FSB at 434(!) and a generous 1.425 volts going to the CPU. I use the 4 gb switch and all non essential background services shut down.As always, thanks in advance for any simplification you folks can provide.

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

If you are running at 4.15 Ghz on air, and your system is running stable, I would leave the Northbridge and Southbridge voltages in auto.Changing the the Northbridge or Southbridge voltage or references is not going to gain you any more in the area of performance if the system is currently running stable.

Share this post


Link to post
Share on other sites

Well, Sargeski, that's kind of the assumption I've been operating under. Since I don't really understand their purpose in relation to performance and tweaking, is that the consensus?

Share this post


Link to post
Share on other sites

Chuck, my NB is set to 1.61 in the BIOS for 1.63 actual. I leave the SB in auto. The only reason I locked in the NB is that if I pushed the FSB too far, Auto would set the NB above 1.7. 4.15 on a 434 FSB. Your vCORE, is that with or without the droop?What strap are you using? What is your MEM running at?How's FS running at 4.15? How's that PBY memory? How about timings and volts?Sorry, my turn to ask you questions now :-lol :-lol. Warmest Regards,Jeff

Share this post


Link to post
Share on other sites

Jeff:>>4.15 on a 434 FSB. Your vCORE, is that with or without the droop?With or without the whaaat? :-)>>What strap are you using? What is your MEM running at?>>How's FS running at 4.15? How's that PBY memory? How about timings >>and volts?MEM is at 100 mhz, and everything else -- EVERYTHING -- is set to "Auto", and FS9 is running unbelievably well. The ASUS BIOS with Super Tweaker is just fantastic. I've got 2 profiles set, and all I have to do is invoke one or the other at start up and I'm good to go.On 3 monitors, with all sliders right, traffic at 90% and about a half dozen addons including active sky, radar contact and FDC across my network via WideFS, it easily gets 30 - 40 FPS (although I've got it locked at 28) and virtually no blurries or stutters. Core 1 runs at about 67c when flying, core 2 maybe 5c lower.I own FSX but haven't even started it in over a year and I don't feel I need it. I'm sure it would run just fine however.

Share this post


Link to post
Share on other sites

So ya want to tweak? Really? OK, here are some excerps from conversations we had several months ago about tweaking a system. Using the Northbridge to optimize is all about optimizing the memory buss to Front side buss interface. The setting that provides this function is called tRD. Try to get through the basics first. ** It's pretty much true that increased memory clock speeds can provide only "Felt," subjective improvements in FSX (given a normal budget!) This conversation has progressed on to attempting to understand why any improvements might be "felt" at all.The increased memory speed/FSX performance improvement premise - Should Not - be considered by normal builders. Use whatever ram that will allow you to run your FSB to generate a maximum O/C on your CPU. For instance, if you need to go to a 400Mhz FSB, buy DDR2-800 ram. Anything beyond that is science: You will be into the realm of the future of computer technology and will be provided a subjective improvement more in relationship to how much you spent for the stuff.And speaking of science, Consider the actual capability of our current FSB. At the quad pumped data rate on a 400Mhz FSB (400x4 or 1600), a FSB data event occurs every .07ns. Therefore, a data bit has the capacity to be uploaded onto this FSB every .07ns. Yes, 7 one-hundredths of a billionth of a second. At a 400Mhz FSB, a FSB data event occurs every .07ns. That's the FSB's data rate (FDR). These events are Not all used, but they are available.Think of it like a conveyor belt with troughs. The conveyor belt's speed is such that one of its troughs pass by a loading window every .07ns. These conveyor belt troughs may or may not get loaded (with a data bit). That is going to be a timing issue. But a ride on this FSB express is available at .07ns intervals. These numbers get amazing in hurry.On to Latency: Latency means "wait-time." Waiting for what? "Latency" means how long a data bit must wait to hop-on board the FSB express. Remember, the ram is running on its own Mhz cycle. The better the FSB and the ram cycles can be synchronized, the better performance will occur. This syncronizer is the northbridge's memory controller and the function is called tRD (Timing, Read Delay).That means that a ram latency of 45ns suggests the ram had to skip (wait-through) 641 asynchronous FSB data events 45ns / .7ns = 641) before is was able to finally synchronize with the FSB to achieve a data transfer event. The data transfer finally occurred (the busses finally "synchronized") on the 642nd FSB data event.(Math? There are 642, .07ns intervals in 45ns)Adjusting either the FSB or the Ram speed to enable the ram to use more closely spaced "FSB data events" would reduce the ram's need to "wait for a synchronous moment" (aka "latency"). This could potentially increase performance. If Nehalam will run a 133Mhz FSB, but just use more closely spaced cycles *tRD 3-ish?) But it will have Nothing to do with DDR3 ram, per-se. It will be about using more closely spaced Quickpath (FSB) cycles with any user client (like ram).By this analysis, changing the FSB speed (either up or down) is only helpful if it allows its clients (like ram) to utilize more closely spaced FSB generated data events. A 133Mhz FSB is plenty. Nehalem will prove this in just a couple of months.Increasing the FSB speed makes no difference. We have to understand this is not about speed like a car. Every "thing" in the computer travels at the speed of light. It's all just electricity.This is - entirely - about timing.The trick is to allow the FSB and the ram to synchronize as often as possible. It appears that data transfers at 45ns intervals (aka "latency") is about the record . . . but so far it has been only obtained on the basis of under-considered experiments.Even that old poky 200Mhz FSB provides a 1ns interval. If that 1ns interval syncs better with a particular ram speed interval, performance could actually increase at a 200Mhz FSB. For instance, if a 200Mhz FSB allowed some ram Mhz speed to sync-up to the FSB every 35 cycles, the latency would drop to 35ns.***********Now the results a tweeker can expect to achieve with these various settings. ** I with GEX, I leave AG and all traffic completely off for the 744X. 20FPS is a miracle down town, gets better up the river. With the Lear (default airplanes), 4x3.6Ghz/~ hi-50ns can handle the FSX "canned" Ultra High ('cept water down one notch) with frames bouncing through the 20s. Starts touching the 30s up the river a ways. Scenery loads at highest resolution. What's all this "crispness" stuff? Highest res is highest res. Is there something better than that? Looks Very "tight" to me.My benchie starts over the Statue of Liberty and proceeds North up the Hudson. 4000 feet at 220 knots. They're actually making an airport outa Stewart (IRL). Used to be just an old freight-port. Tried out the runway as a drag strip, once (in the ol' rental Firebird). Great HoJo's (was?)there. Driving up from JFK (Got FSGenesis?), those Hudson cliffs are For Real. That's a good destination.I agree, it's just too close to call . . . for anyone else. A turbo-charge of 20ns of reduced latency might be a bit like fueling up my car with midgrade gas after running regular for a year. I can tell, but I'd be hard pressed to convince anyone else.But for the hobbiest in us all, this is really quite interesting. I've been playing around with the ram latency control levers a bit and these observations seem pretty close:1) Each CL is worth ~ 1ns2) Each RAS/CAS Read delay is worth ~ 1ns3) Each RAS/CAS Write delay does nothing (but I believe Everest only monitors outbound or -read- traffic).4) RAS Precharge does nothing5) Precharge delay does nothing6) Each + 100 Mhz of ram-buss clock is worth ~ 1ns.And then the Big Dog tRD:7) Each increment is worth 1 FSB cycle (For instance 2ns @ 400Mhz)So, if someone wants to figure out what latency new sticks or settings will yield, just add (or subtract) from what a user has now.For instance, 800Mhz at 4-4-4-12 gets me better latency than ~ 980Mhz at 5-5-5-15. Here's the math (and it worked). The extra ~ 100Mhz (at ~ 980) nets me -1ns, but I net +2ns because I have to drop CL and the two tDelays. I loose 1ns. 800's more stable anyway and I can run at its rated 2.2v 44412. The O/C meant nothing. Now, I get 1066 that can run at 44412 and I get the keep that 1ns (or I drop to 667 ram and loose 1ns?) Stop the madness!I think that "HotSpot" we kept hearing 'bout might have been about getting 2ns for each CL drop. Haven't looked at that CAWLI (?) concept yet. What was it supposed to do anyway? I forget.Also notice the ram is using the same "tool" for internal data transfer as the Northbrige. The Northbridge calls it:"FSB to RAM Read Delay" (or tRD).The Ram Module just calls it:"RAS to CAS Read Delay,""RAS to CAS Write Delay."I'm sure these numbers represent cycles too, only ram-buss cycles.What'dya know.Aren't you glad you asked?

Share this post


Link to post
Share on other sites