Re: debian-user] Re: AMD vs Intel and the Debian kernel
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 <thilts@mcsnet.ca> 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/
Reply to: