Hmmm, I like the idea of combining threads Firstly, Dual DDR... Do you just use normal DDR memory ?? or do yo uneed some special (problalbly more expensive) memory to make it work ? and how good is it ? will I go... "damnnnn" ? Secondly, do people still make turbo circuits? and (heh heh heh) how exactly did they work ? or was it only ever a concept, so they made the button and got no further? tnx!
Dual-DDR. Uses normal DDR memory. How good? Depends on the CPU you combine it with. The bandwidth-beast P4 will see considerable benefit from it relative to single-channel DDR platforms (eg i845), whilst the AthlonXP will not see any great benefit from it due to the FSB bottleneck (what's the point in having 6.4GB/s from northbridge to memory if you've only got 2.1GB/s from CPU to northbridge?). Turbo...ahhh....if you're asking this, you're probably too young to remember...if you only remember a pointless button, that means you came too late to the party. It went out with the introduction of the pentium pretty much, and ATX completely dropped the idea. You're thinking of it the wrong way. The turbo being enabled was not a special, faster mode for the computer, but was rather the standard speed of operation (eg, with a 486DX 33MHz, with the turbo ENABLED you ran at 33MHz). When you disabled the turbo, the CPU would drop to around 7MHz, in order to execute legacy CISC code which was reliant on the CPU clock speed for timing (if you are programming in machine code or assembler, where there are no built-in functions or libraries, you often have to build in timings by assuming or defining the clock speed you're working with. Of course, if you then increase your clock speed, you have a problem, and your program may run too fast. An example I came across was running the original Wing Commander on my 486DX33. The version I had was on CD-ROM, but this gave rise to a problem. If you had the turbo on, it would load normally from the single-speed CD-ROM (yup...74 minutes to read an entire CD...), but once loaded the game would run too fast. However, with the turbo off, the game would run at a reasonable speed, but the PIO transfer from the CD-ROM would take around 6 minutes to complete (to load a single mission).). Thus it was a requirement to have the ability to run this older code. With the advent of the pentium however, there was enough cpu power to emulate these slower modes of operation correctly, and less call for such code to be executed (and hence the dropping of native CISC code from the Pentium Pro's P6 architecture, which became the basis of PII and P3 processors. As an interesting reversal, running any CISC code on a modern x86 CPU is INCREDIBLY slow, as CISC instructions do not sit well in today's pipelined RISC cores for the x86 instruction set. It is not a day to day problem, however, as modern compilers and software use the RISC instructions).
wow! they should implement them, but have them as like, OC switches (an idea, maybe? ). as for the DDDR, hmmm. Im thinkiing of an athlonXP 2100+. Tis a shame it wont help much, but is there not a way of breaking the imit ? it seems a bit stupid having one anyway :-/
Imit? I assume you mean limit. No...that arises because the FSB on the 2100+ is 133MHz, DDR, 64 bit. 64 x 2 x 133000000 = 2100MB/s. If you got a 166FSB (333DDR) athlon, such as the 2800+, then you would have 2.7GB/s from CPU to northbridge. Still nowhere close to 6.4GB/s which is theoretically offered by a dual-DDR400 memory architecture. The only real use of the dual-DDR architecture on the nForce is with the integrated graphics core version of the chipset, where the 6.4GB/s is shared between that graphics core and the CPU. However, 6.4GB/s doesn't go far on a modern gfx card, especially not when in contention with a CPU. Any gains realised in the nForce over single-DDR platforms for the athlon are due to better memory controller design, latency advantages in the dual-channel system allowing for greater efficiency in the use of the CPU's FSB bandwidth and other similar issues. They are not due to the outright bandwidth of the system, as it is absolutely impossible for the CPU to take advantage of these, and DMA requests require a negligably small amount of bandwidth relatively, and the AGP's DMA is something that should be avoided wherever possible anyway, since it will always lead to a great performance hit, regardless of available northbridge-memory bandwidth.
Well, I bet your CPU would get really pissy if you kept changing the FSB speed (probably the only way to accomplish this as multipliers today are locked tighter than a chastity belt in some cases) while it was running, like shifting a car from first to fourth gear, not to mention the rest of the components that rely on the CPU's FSB for its timing (PCI, AGP, RAM, et. al.). Finally, there's the fact that people, for the most part, are idiots and will find some way to screw up their systems using that switch and blame someone else, which will aggrevate the hell out of already incredibly pissed-off tech support people.
well then the mobos that can use them would have to be adaptyed wouldnt they! Some kind of temporary storage for the runnign data (like hibernate) stored in a microchip (possibly the stuff being deveolped at cambridge ?) while the motherboard changes and restarts requirted components (not the IDE channels so HDD and CDROMS dont have to be reloaded), quick as a flash! Its not a bad idea, its just not suited to current mobo technology
Actually, I take back most of my last post, as mobile processors do this (well, they actually underclock to conserve power), but the main reason this isn't implemented is practicality. Isaac already hit upon why the turbo button isn't used any more, and there's no reason today that an extra overclock instantly, where as a a good portion of motherboards let you overclock in the BIOS. So, in short, stop being so lazy Jaffer
pff, im just saying its a good idea for a feature maybe it is not needed nowadays, buts it could still be a fun idea
as said by hexus... http://www.hexus.co.uk/review.php?review=464&page=10 does this not say differantly to everything yall have said ? I thought the athlonxp could not go above 2.x gbit bandwidth ?
The athlonXP itself can't. I already explained where the higher performance comes from. Go back and READ my post.
I imagine you'd have to overclock the CPUs fsb pretty heavily to gain much benefit from dual DDR with the Athlon XP as it stands now...though a good single channel DDR setup like KT333 with some good memory (say PC3200) will still keep an AthlonXP happily fed with bandwidth. The dual channel really does make use of the available bandwidth much more efficiently though, thanks to the design of the memory controllers...Using Sandra (which is getting more and more of a useless benchmark, but still), my KT266A based board gets 87% (Ex Buffered) and 93% efficiency (Int Buffered) for the memory. Nforce 2 is something around 98% for both I think, which might not seem much, but it is better.
