Date: Wed, 18 Apr 2001 22:50:19 -0700 From: "Charles Burns" <burnscharlesn@hotmail.com> To: mwm@mired.org, jgowdy@home.com Cc: questions@freebsd.org Subject: Re: the AMD factor in FreeBSD Message-ID: <F121PZrIkyPzGNsokLQ000034d1@hotmail.com>
next in thread | raw e-mail | index | archive | help
>Jeremiah Gowdy <jgowdy@home.com> types: > > As for the AMD+SMP vs Intel+SMP, I can't say regarding the FreeBSD >support, > > however, AMD's SMP is supposed to be far faster than Intel's because it >has > > a Point-to-Point bus for the SMP connection, meaning _each_ CPU has a > > dedicated 200mhz (100mhz DDR) connection to the bus, when on an Intel >SMP > > motherboard the two or more cpus will share the same 100mhz bus. That >means > > on a 4 way SMP Intel system, each cpu will get an effective 25mhz access >to > > the bus under full load in theory. By the same theory, AMD cpus would >each > > have their own 200mhz dedicated connection to the bus, even in an 8 cpu > > setup. > >You're talking about the speed of the connection to the bus, without >talking about the speed of the bus. If the bus in question is 100MHz, >then in any 4-cpu system at full load, each cpu will have at most >25MHz on the bus, never mind that their connection to the bus is >200MHz. So you've just spent 4 times the amount on cpu bus hardware >for no gain in performance. > >If the bus is 133MHz, then each cpu can get 33MHz on the bus on a >loaded system, and the shared connection to the bus causes a problem. > >There may be something obvious I've overlooked - in which case, I'm >sure I'll be told about it. Nobody else seemed to take this one, so... P3/P4 systems use the GTL+ bus. Athlon systems use the Alpha EV6 bus. GTL+ systems share the connection to the southbridge among all CPUs, so the bandwidth is divided amongst them. This doesn't neccesarily eliminate the performance gains of using multiple CPUs, because rarely does a single CPU utilize all available bandwidth. It just seriously hampers it. There seems to be a misconception that ALL SMP Intel systems have this problem. While all Intel systems use the GTL+ bus, some of the higher end ones have several complete busses on the same motherboard. There are essentially multiple near-complete motherboards on the same PCB, but they share data and often split up memory bandwidth as well. Some of these also have multiple separate memory banks in which each CPU or set of 2 or 4 CPUs gets a full 64-bit pathway to 100MHz RAM (or a 16-bit pathway to 200MHz QDR RAM in the case of Rambus) This has some huge disadvantages, of course--mainly cost. Obviously the complexity of the electronics makes the board far more expensive to manufacture, but also the added testing involved is several orders of magnitude higher, especially considering that these boards have to have server-class reliability. The EV6 bus, which is (or at least was) used by Compaq/DEC Alphas, cheats by having a dedicated southbridge chip for each CPU. The only thing shared is the memory bandwidth (though you can again have multiple separate banks) and a few other things like video and stuff. While having multiple southbridges clearly makes the PCB more complex, the added complexity is FAR less than the GTL+ method. This method also makes Athlons more scalable. Someone mentioned that they are limited to 14 CPUs. Actually, neither the P3 or Athlon are limited by anything but the motherboard (other than artificial limitations that Intel might have engineered). You can theoretically have hundreds of Athlons on the same PCB. This would, of course, be impractical compared to just using lots of servers, but it is much more feasible than doing so with GTL+. A 100 MPU GTL+ motherboard would be the eighth wonder of the world. While EV6 may be better than GTL+, we have yet to see it work on real-world Athlon systems other than the 2CPU Tyan mobo. It's real advantages will show up with 8 and 16-way systems that may or may not ever be released. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F121PZrIkyPzGNsokLQ000034d1>