So what really is faster...3.8GHZ CPU but NB at 2000 or 3000MHZ?

[Mechromancer]

Hers is that full Madshrimps review. I think the full review is interesting as well. I really appreciate this hard work guys. Anyways, it's always interesting to compare results:http://www.madshrimps.be/?action=getarticle&articID=909

I'm fascinated with this HT link issue. Pushing it is killing 3D speeds. I'd like to test those speeds with some interesting HyperTransport 3.0 features that seem otherwise useless and unassuming in our BIOSes. Are you all familiary with Isochronous Flow Control Mode, VC1 Traffic Support, UnitID Clumping, and 2x LCLK Mode?

http://forums.guru3d.com/showthread.php?t=267708

2) Isochronous Flow-Control Mode: This has to do with how information is passed between the CPU, the GPU and the RAM along the NorthBridge. It has been a part of the BIOS for HT since AGP 8X, but the option to enable or disable it is a fairly recent addition. When this option is enabled, it assigns the information a number, in the order it was received. Each bit of information is then processed in that order along the route. In toher words, there is no loss of information, but the processing in this orderly manner has drawbacks. If you choose to enable this feature, you will also need to enable UnitID Clumping and then under PCI-E COnfiguraiton and the NB-SB section of the BIOS, VC1 needs to be enabled as well.
3) UnitID Clumping: Simply put, it accounts for not all devices being equally quick at processing information. This allows each device to support a longer waiting line. VC1 accounts for a major drawback of Isochronous Flow-Control mode in that the flow control mode does not allow any information to break line. Everything must wait it's turn. Therefore, if one piece of info is intended for the CPU and in front of it is info the for GPU, the info for the GPU needs to be processed before the CPU info is processed; plus, if there is a waiting line of info to be processed onthe GPU, the CPU info is held up all that much longer. VC1 comes to the rescue by letting the CPU info break line, bypassing the GPU info jam to join the CPU info queue.
4) Tristating (in all forms): Tristating is a power saving feature in addition to ASPM linking. Whatever sections you want to enable Tristate in, you reduce the energy needed to run that area, but the downside is that you also reduce that area's performance.
5) 2xLCLK: This setting only affects HT 3.0, so Phenom's may benefit from it while with Athlon's, it just does not apply. LCLK stands for Latency Clock. The 2x means that instead of one full bandwidth HT Link you are requesting two half bandwidth HT Links. For performance, at times it is better to have a two lane highway; traffic flowing in both directions at the same time along the same strip of asphalt at 50mph, than it is to have a single lane highway along the same strip of asphalt with traffic lights controlling the directional flow at 100mph.

When I enabled a combination of these I got a good bump in performance when overclocking. I believe they're cleaning up communication over highly clocked HT links when enabled. I was talking with Chew* about this yesterday, but basically I have to do some advanced testing with these features to prove what they do. They may add stability at higher clocks as well. I don't have the cooling to test above 3.6Ghz core and high HT-Link speeds though. Anybody want to try?

PS: NP NB-SB VC1 Traffic Support MUST be enabled when using Isochronous Flow Control Mode. It is also recommended you use UnitID Clumping 2/3&B/C.