On Monday 18 August 2008 23:03, Ted Hilts wrote: > Jeff Soules wrote: > > AMD is a chip manufacturer. They started out (~20 years ago) as a > > "second source" for 286 processors, but since then they have been > > producing independently-designed chips within the x86 architecture > > (i.e. they use the same instruction set). > > > > (See: > > AMD: http://en.wikipedia.org/wiki/AMD > > x86 architecture: http://en.wikipedia.org/wiki/X86_architecture) > > > > So 1: > > AMD is a separate chip manufacturer. They are now a competitor, not a > > second source. > > > >> 2. Is there any significant architectural differences between the > >> products manufactured by these two companies??? > > > > Yes. I'm not an expert on what those differences are, but they are > > different chips with different hardware details. > > It looks like there are differences in the CPU pipeline length (or > > used to be), in the way some instructions are implemented, in number > > of cores available, etc. You can find out more by googling > > "difference between amd and intel architecture" or some such, a lot of > > the links I was finding are outdated though. Keep in mind both > > companies are releasing new chips every few months; something that was > > true in mid-2007 will not necessarily be true any more, etc. > > > >> 3. I ask the above question because it seems that the chips produced by > >> one seem not be be plug in capable with the chips produced by the other > > > > That is correct; they are not plug-in compatible. One needs an Intel > > motherboard for Intel processors and an AMD mobo for AMD processors. > > > >> 4. I also ask the above question because over the last 2 years software > >> problems "seem" to occur around one but not the other??? > > > > I haven't heard anything about this; I'm sure that one chip has > > different problems from another, but all have problems. > > > >> 5. Also, there is a non-i386 computer containing the AMD acronymn listed > >> with ARM and a dozen other non i386 computers listed by Debian. > > > > Not sure what you're referring to. http://www.debian.org/ports/ lists > > the different chip architectures supported by Debian. AMD64 (iirc, > > someone will doubtless correct me if I'm wrong) is separate because > > AMD chips had real 64-bit support before the Intel ones. > > i386 traditionally refers to the 32-bit x86 instruction set. > > > >> 6. How is it that (for example) the Debian i386 AMD chip (some but not > >> all) are more condusive to the Debian kernel for certain kinds of > >> operations but not so with the Intel chip? > > > > Not sure what you're referring to. This is a pretty vague statement. > > > > What version of Debian were you planning to run? You should find both > > AMD and Intel chips supported perfectly well by the stable branch of > > Debian. > > The vendors are correct that you must use AMD motherboards with AMD > > processors, Intel motherboards with Intel processors; but either one > > should be capable of doing what the other does (within 32-bit > > applications). AMD implements the i386 instruction set; everything > > should work fine there. There will be some differences in 64-bit > > land, because not everyone supports 64-bit software at this point > > (Java, Flash, etc. are not yet released in 64-bit compatible > > versions). This requires some workaround but is generally manageable; > > software that is not available in 64-bit versions will usually just be > > run in 32-bit compatibility mode. (Modern kernels are available for > > both 64-bit and 32-bit architectures, of course; they just won't be > > identical, because one is built with 64-bit support, one is not). > > > > This isn't a processor-specific mailing list, so while I'm sure people > > here will be able to answer your questions, they won't necessarily be > > the best answers. It might be helpful if you could specify why you're > > asking, or what exactly you're trying to do. > > > > Best, > > Jeff Soules > > > > On Mon, Aug 18, 2008 at 1:28 PM, Ted Hilts <[EMAIL PROTECTED]> wrote: > >> Can someone enlighten me regarding my confusion with the term AMD. > >> > >> 1, I know that the term AMD (American Micro Devices) is supposed to be a > >> 'second source' for Intel 32bit and 64bit microprocessors. But it seems > >> based on what I have read on this relationship between AMD and Intel > >> that there is controversy, legal actions, competition, and architectural > >> differences regarding the manufacture and selling of these > >> microprocessors. So this suggests to me that AMD is not really a 'second > >> source' (a licensed second manufacturing and selling source supplier of > >> identical products as designed and manufactured by another company). > >> > >> 2. Is there any significant architectural differences between the > >> products manufactured by these two companies??? > >> > >> 3. I ask the above question because it seems that the chips produced by > >> one seem not be be plug in capable with the chips produced by the other > >> -- it seems that the boards produced for one are different that the CPU > >> boards produced for the other??? > >> > >> 4. I also ask the above question because over the last 2 years software > >> problems "seem" to occur around one but not the other??? > >> > >> 5. Also, there is a non-i386 computer containing the AMD acronymn listed > >> with ARM and a dozen other non i386 computers listed by Debian. I > >> understand this second listing of non i386 machines (one example being > >> the Motorola 68xxx) but am confused about the AMD non i386 machines > >> place in this listing. > >> > >> 6. How is it that (for example) the Debian i386 AMD chip (some but not > >> all) are more condusive to the Debian kernel for certain kinds of > >> operations but not so with the Intel chip??? I base this on Debian > >> documentation where the Intel chip is not even mentioned. > >> Bottom line, over the past 2 years I have been struggling with the idea > >> of using the correct (if there is such a thing) microprocessor > >> board/chip combination appropriate for certain operations but not at the > >> exclusion of all other possible operations. Maybe I have just confused > >> myself and every Intel board/chip combination is replaceable with every > >> AMD board/chip combination. But this is not what vendors have been > >> telling me. They are telling me that on MS Windows OS (eg: XP) I can > >> use either the AMD board/chip combination or the Intel board/chip > >> combination but the boards and chips are not mutually compatible - AMD > >> chips must go into AMD boards and Intel chips must go into Intel boards. > >> Also, I am being told that some Debian software will operate on some AMD > >> board/chip combinations but not others and that this has something to do > >> with the specific kernel where one Debian kernel version will not run > >> the same (for certain operations) as another version. > >> > >> So, I am confused and frustrated. I used to think that Debian kernels > >> would all run without exception on either AMD or Intel board/chip > >> combinations and the odd quirk in a kernel version would be resolved > >> with a newer version. I was also told that the chip sets (including the > >> MP chip(s) had different parameters and an Intel chip set combination > >> was not compatible with an AMD chip set combination thus making the > >> boards non compatible with one another. In fact, I am told, it is these > >> other chips (including and working with the MP chip) that account for > >> many differences some of which play havoc with certain Linux kernels. I > >> am also told that indiscriminate use of a Debian kernel may bring > >> problems that occur on an Intel system or vice-versa for a AMD system. > >> > >> Is there a CHART that matches Debian kernels to tested and acceptable > >> AMD and Intel board/chip set matches while indicating limitations, > >> constraints, and possible special operations for both??? > >> > >> I have seen this same question (in a variety of forms) asked on this > >> forum as well as others but I haven't seen a complete answer. > >> > >> Thanks in advance, for any comments, technical references, etc. == Ted > >> Hilts > > Thanks Jeff. > > What I want to do is acquire a fast quad core CPU board and associated > chip set (either Intel or AMD) manufactured. The purpose is to > establish a virtual enviornment with a Linux host as the basis for that > computing environment. Over the last 2 years there have been many > changes regarding how a virtual computing environment can come > together. First I encountered Xen and then became aware of several > existing Linux approaches. I followed the lists the best I could and > started to wonder which would be the optimal approach. I decided that > Debian would be my best bet but I was unsure of what virtualisation > technique would be best. > > I want to run server applications on this Debian host with that host > virtualizing the servers. I need each server to be capable of > networking into my LAN as well as into the INTERNET. I need the > networking between servers on the LAN and well as the INTERNET to be > easily connected and understood preferably by means of a GUI. But I > want the entire networking effort OPEN SOURCE so I don't want a GUI that > is non Debian. The networking of virtualised servers -- let's say 10 -- > has me worried as I want to assign static LAN based IP address > (192.168.x.x) and name (server-apache.network.com) and SAMBA connection > protocal for every server. In other words I want the servers to be able > to interconnect with each other using shares. > > Also, recently, I discovered that a dual or quad CPU board only > provides load balancing and not greater speed. If for example the CPU > speed is given as 3 Gb and there are numerous servers on that machine > the speed of each of the two (dual core) or 4 (quad core) or 8 core > components is reduced thus reducing the speed of each process so the > total processing of core elements is 3 Gb. This means for an 8 core > unit the speed is reduced to 3 Gb divided by 8. At this time I haven't > got a clue whether the virtual system should be single core or multi > core as there could be speed advantages and perhaps the manner of > virtualising might work best by using some kind of quota control??? > > Maybe you or someone else reading this response (or possibly a Debian > mentor) could help me with this objective. > > Anyway, thanks -- Ted
[1]This popped to mind. Other interesting videos in that location. 1. http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/low/686_Virtualisation_in_Debian_-_Present_and_future.ogg -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
