Feizhou <feizhou at graffiti.net> wrote: > Yeah, read about it quite a while ago when it knocked out > the P4 2.8 processor. Intel is returning to the architecture. The original i686 was very efficient, it just didn't scale beyond 1.0GHz initially -- 1.5GHz with some mid-release asynchronous hacks, now possible 2.5GHz with more timing/async changes. Intel hasn't do a full i686 redesign since the original 1994 Pentium Pro. Understand that's because Intel thought everything would be IA-64 now. You have to plan architectures 5+ years in advance, because it takes at least 12 months to design, and another 24-36 months of timing closure. So when EPIC/Predication didn't deliver in the first IA-64 Itanium-Merced, even for IA-64's native ISA (not even looking at x86 comaptibility), that's when the Netburst team was formed. They did the design in only 18 months -- by completely by-passing timing closure, using very long pipes that have many stages doing absolutely nothing. That's where HyperTransport comes in -- it offers two schedulers in the hope that two virtualized cores can put more stages to use. It only works on the horribly inefficient Netburst architctures -- you will _never_ see HyperTransport on the Pentium-M or Intel's newer processors. The concept of multi-threading on a single core lives and dies with NetBurst. The next evolution is multi-threading across multi-core. > Thanks to their providing docs. AMD, Intel and nVidia are pretty open with specifications, except when legally bound otherwise. E.g., the biggest and ironic reason why nVidia couldn't share its AGPgart interface until about 18 months ago was a NDA with Intel (long story). > Yes, these are the chums in use in the newer boxes I used > to admin. I loved the 3ware + riser card fiasco though. Well, when you're pushing 200+ traces at 66MHz, there tends to be EMF/EMI issues. 3Ware isn't the only one that has had issues with traces. Remember, 3Ware 7000/8000/9000S (not 9550SX) use 0 wait state, 64-bit ASIC+SRAM devices. Trace length and timing is everything, and heavily affected by EMF/EMI. Again, I refer back to the i865 v. i875 issues. The traces of a PCB designed for the i875 -- such as the Asus P4C800 -- didn't necessarly work for the exact same chip in the i865, because it tested to lower tolerances. > The problems I have are related to their hardware, not > whether there are good drivers or not. Actually, the firmware has always been the issue. The ASIC+SRAM design was always sound. They've done some stupid things, like the RAID-5 firmware update for the 6000 series (which was _never_ designed for RAID-5). But other than that, it's always been a > The poor latencies just won't let me use a Pinnacle > DC10 board without crashing. ??? Let me guess, RAID-5 on a 9500S? ;-> > Yeah, whatever. Tyan come out with a board for servers > based on a VIA chipset for Pentium III cpus and so I got > to deal with them. The Tyan "Tiger" series is _not_ a workstation/server platform, it's the _desktop_ platform. That's a very common misnomer. The "Thunder" is the workstation/server series. ;-> > I cannot wait for a promise by a Nvidia rep about their > future chipsets using SATA NCP technology that will allow > an open source driver to be written to be acted on. Do you mean NCQ? Understand that nVidia is _totally_open_ with their designs right now, including the SATA. But the SATA hardware just doesn't do NCQ at all. But yes, nVidia has been extremely open. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)