Gaming AMD vs Intel

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

On Mon, 12 Sep 2005 06:58:58 -0400, George Macdonald wrote:

> On Mon, 12 Sep 2005 06:07:42 GMT, Wes Newell <w.newell@TAKEOUTverizon.net>
> wrote:
>
>>You're just a little more than confused. The CPU doesn't support AGP, PCI,
>>PCI-E or much of anything else except the ram directly. The rest still are
>>still functions of the chipset. The only thing that the CPU now supports
>>directly is the memory. All other system devices/buses are handled the
>>same way as the K7 was, over the FSB, or if you prefer, the HT Link
>>between the cpu and chipset.
>
> You have just proved your complete misunderstanding of what is on the K8
> die and what the HT I/O-link is used for. All CPU memory accesses mapped
> to I/O devices, such as AGP/PCI-e, or any PCI device must be trapped in the
> CPU's "north bridge" sub-set and diverted to the HT I/O link; obviously the
> corresponding MTRRs and associated logic *must* be on the CPU die. Same
> for CPU cache snooping - previously a north bridge/FSB function and now
> incorporated into the CPU.
>
No, I understand that since the memory bus is now split out of the chipset
northbridge, that there has to be some control in the cpu to split address
the proper bus. And once sent to the each of the other devices (Chipset or
memory controller) it has to be routed accordingly by that device. What
this internal logic (called a northbridge by AMD) doesn't do is actual
route the data to the proper destination of the final device. This is
still done in the chipset just as it was done in the K7. In simpler terms,
the internal cpu logic just strips out reads/ writes to memory addresses
and sends them to internal memory controller instead of out the FSB (HT
Link) as the K7 did. I did similar things when designing the products I
used to manufacture and sell. it's just logic.

> Apart from CPU I/O reads/writes and interrupts, a minor part of FSB
> traffic "volume", the HT I/O link has nothing in common with a FSB. The
> major volume of traffic on the K8 HT I/O-link, viz. DMA transfers, is
> handled and routed internally in the north bridge (MC Hub) of a FSB type
> system.

I don't consider the part you consider to be minor, minor. I consider it
the major part. And I assume AND does to, otherwise why replace the the
EV6 bus with HT. It's a fact that with the memory bus now split out of the
FSB, that the required bandwidth of the FSB (HT Link) dropped
dramatically, since most of the bandwidth in previous FSB applications was
taken up by memory read/writes. Maybe I should be blaming the Mb
manufactures for using FSB for a term for setting the cpu clkin to begin
with. CPU Host Clock would have been more specific anyway. That would have
also done away with the real speed of the FSB fiasco. All in all, I'm
getting to the point where I don't much care anymore.

--
KT133 MB, CPU @2400MHz (24x100): SIS755 MB CPU @2330MHz (10x233)
Need good help? Provide all system info with question.
My server http://wesnewell.no-ip.com/cpu.php
Verizon server http://mysite.verizon.net/res0exft/cpu.htm

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

On Mon, 12 Sep 2005 17:26:19 GMT, Wes Newell <w.newell@TAKEOUTverizon.net>
wrote:

>On Mon, 12 Sep 2005 06:58:58 -0400, George Macdonald wrote:
>
>> On Mon, 12 Sep 2005 06:07:42 GMT, Wes Newell <w.newell@TAKEOUTverizon.net>
>> wrote:
>>
>>>You're just a little more than confused. The CPU doesn't support AGP, PCI,
>>>PCI-E or much of anything else except the ram directly. The rest still are
>>>still functions of the chipset. The only thing that the CPU now supports
>>>directly is the memory. All other system devices/buses are handled the
>>>same way as the K7 was, over the FSB, or if you prefer, the HT Link
>>>between the cpu and chipset.
>>
>> You have just proved your complete misunderstanding of what is on the K8
>> die and what the HT I/O-link is used for. All CPU memory accesses mapped
>> to I/O devices, such as AGP/PCI-e, or any PCI device must be trapped in the
>> CPU's "north bridge" sub-set and diverted to the HT I/O link; obviously the
>> corresponding MTRRs and associated logic *must* be on the CPU die. Same
>> for CPU cache snooping - previously a north bridge/FSB function and now
>> incorporated into the CPU.
>>
>No, I understand that since the memory bus is now split out of the chipset
>northbridge, that there has to be some control in the cpu to split address
>the proper bus. And once sent to the each of the other devices (Chipset or
>memory controller) it has to be routed accordingly by that device. What
>this internal logic (called a northbridge by AMD) doesn't do is actual
>route the data to the proper destination of the final device. This is
>still done in the chipset just as it was done in the K7.

The K8 does things differently from the K7 - it's obvious but see below.

> In simpler terms,
>the internal cpu logic just strips out reads/ writes to memory addresses
>and sends them to internal memory controller instead of out the FSB (HT
>Link) as the K7 did. I did similar things when designing the products I
>used to manufacture and sell. it's just logic.

There have been MTRRs in the CPU for a while now but more to do with
cachability and write combining - there are *additional* structures & logic
elements in the K8 core which used to be part of north bridge action...
because of the need to arbitrate to main memory or I/O device mapped
memory... and of course the legacy "reserved memory" space.

>> Apart from CPU I/O reads/writes and interrupts, a minor part of FSB
>> traffic "volume", the HT I/O link has nothing in common with a FSB. The
>> major volume of traffic on the K8 HT I/O-link, viz. DMA transfers, is
>> handled and routed internally in the north bridge (MC Hub) of a FSB type
>> system.
>
>I don't consider the part you consider to be minor, minor. I consider it
>the major part. And I assume AND does to, otherwise why replace the the
>EV6 bus with HT. It's a fact that with the memory bus now split out of the
>FSB, that the required bandwidth of the FSB (HT Link) dropped
>dramatically, since most of the bandwidth in previous FSB applications was
>taken up by memory read/writes.

The HT I/O-link can also be required to carry high bandwidth data... as
already stated, all the DMA which used to be internal to the NB.

> Maybe I should be blaming the Mb
>manufactures for using FSB for a term for setting the cpu clkin to begin
>with. CPU Host Clock would have been more specific anyway. That would have
>also done away with the real speed of the FSB fiasco. All in all, I'm
>getting to the point where I don't much care anymore.

The mbrd mfrs have not helped here.

--
Rgds, George Macdonald

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:mtaai15fl4g50qh3p7a71nrq2g5evc7tt9@4ax.com...
> On Sun, 11 Sep 2005 13:52:36 -0500, Big_Pig <big_pig@farming.com> wrote:
>
>>Since there is no FSB to use as a reference for the CPU-core's
>>clockspeed (as well as some of the other clocks), we need something else
>>to provide the required reference clock signal.
>>
>>The solution to this problem is a 200MHz base-clock provided to the
>>processor by the on-board clock-generator on all 8th-Generation
>>platforms.
>>
>>This Article will explain how clocks are generated on an AMD
>>8th-Generation platform.
>>http://forums.amd.com/index.php?showtopic=55881
>
> This one doesn't have any mistakes🙂 -
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24707_PUB.PDF
>
> --
> Rgds, George Macdonald

LOL! THAT told em George!
regards,
McG.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

Wes Newell <w.newell@TAKEOUTverizon.net> writes:
>On Mon, 12 Sep 2005 06:58:58 -0400, George Macdonald wrote:

>> Apart from CPU I/O reads/writes and interrupts, a minor part of FSB
>> traffic "volume", the HT I/O link has nothing in common with a FSB. The
>> major volume of traffic on the K8 HT I/O-link, viz. DMA transfers, is
>> handled and routed internally in the north bridge (MC Hub) of a FSB type
>> system.
>
>I don't consider the part you consider to be minor, minor. I consider it
>the major part. And I assume AND does to, otherwise why replace the the
>EV6 bus with HT. It's a fact that with the memory bus now split out of the
>FSB, that the required bandwidth of the FSB (HT Link) dropped
>dramatically, since most of the bandwidth in previous FSB applications was
>taken up by memory read/writes. Maybe I should be blaming the Mb
>manufactures for using FSB for a term for setting the cpu clkin to begin
>with. CPU Host Clock would have been more specific anyway. That would have
>also done away with the real speed of the FSB fiasco. All in all, I'm
>getting to the point where I don't much care anymore.
>


You still haven't grasped the fundamental difference between a point-to-point
serial link and a shared bus. HT is a point-to-point serial link. It provides
full bandwidth between a processor socket and either another socket (in coherent mode) or a
southbridge (e.g. Serverworks HT2000) in non-coherent mode. Since an Opteron
has 3 HT links, the inter-socket communications are at full HT bandwidth and
are not perturbed in any way by IO traffic over a non-coherent link.

The inter-socket communications consist primarily of coherency traffic
(probes, (snoops on a FSB)) and memory transfers when one socket requires
data from DRAM controlled by another socket.

Because the links are point to point, the non-coherent HT link between
the processor socket and southbridge gets full bandwidth while the coherent link(s)
between processor sockets also get full bandwidth.

Contrast this with the shared bandwidth on a FSB and you'll easily see
the performance advantages of a point-to-point link like the HT.

The advantages hold true for sempron64 and athlon64 as well, even with
one HT link, because the HT is never used for memory traffic, unlike a
traditional FSB which carries memory and I/O traffic.

scott

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

"Scott Lurndal" <scott@slp53.sl.home> wrote in message
news:OYKVe.708$Jm.655@newssvr27.news.prodigy.net...
> Wes Newell <w.newell@TAKEOUTverizon.net> writes:
>>On Mon, 12 Sep 2005 06:58:58 -0400, George Macdonald wrote:
>
>>> Apart from CPU I/O reads/writes and interrupts, a minor part of FSB
>>> traffic "volume", the HT I/O link has nothing in common with a FSB.
>>> The
>>> major volume of traffic on the K8 HT I/O-link, viz. DMA transfers, is
>>> handled and routed internally in the north bridge (MC Hub) of a FSB
>>> type
>>> system.
>>
>>I don't consider the part you consider to be minor, minor. I consider
>>it
>>the major part. And I assume AND does to, otherwise why replace the the
>>EV6 bus with HT. It's a fact that with the memory bus now split out of
>>the
>>FSB, that the required bandwidth of the FSB (HT Link) dropped
>>dramatically, since most of the bandwidth in previous FSB applications
>>was
>>taken up by memory read/writes. Maybe I should be blaming the Mb
>>manufactures for using FSB for a term for setting the cpu clkin to
>>begin
>>with. CPU Host Clock would have been more specific anyway. That would
>>have
>>also done away with the real speed of the FSB fiasco. All in all, I'm
>>getting to the point where I don't much care anymore.
>>
>
>
> You still haven't grasped the fundamental difference between a
> point-to-point
> serial link and a shared bus. HT is a point-to-point serial link. It
> provides
> full bandwidth between a processor socket and either another socket (in
> coherent mode) or a
> southbridge (e.g. Serverworks HT2000) in non-coherent mode. Since an
> Opteron
> has 3 HT links, the inter-socket communications are at full HT
> bandwidth and
> are not perturbed in any way by IO traffic over a non-coherent link.
>
> The inter-socket communications consist primarily of coherency traffic
> (probes, (snoops on a FSB)) and memory transfers when one socket
> requires
> data from DRAM controlled by another socket.
>
> Because the links are point to point, the non-coherent HT link between
> the processor socket and southbridge gets full bandwidth while the
> coherent link(s)
> between processor sockets also get full bandwidth.
>
> Contrast this with the shared bandwidth on a FSB and you'll easily see
> the performance advantages of a point-to-point link like the HT.
>
> The advantages hold true for sempron64 and athlon64 as well, even with
> one HT link, because the HT is never used for memory traffic, unlike a
> traditional FSB which carries memory and I/O traffic.
>
> scott

Scott, you don't seem to have absorbed the essense of this thread which
seems to be not a discussion of the merits of HT but some sort of
argument about whether it is acceptable to refer to a HT link as a bus,
and whether the chip connected to by said link from an amd processor is a
"north bridge" or something else unnamed, and whether the HT link in
question connecting the cpu to said chip is a "front side bus".

I hope this clears up things for you.

del

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

"Del Cecchi" <dcecchi.nospam@att.net> wrote in message
news:3opj64F72carU1@individual.net...
>
> "Scott Lurndal" <scott@slp53.sl.home> wrote in message
> news:OYKVe.708$Jm.655@newssvr27.news.prodigy.net...
>> Wes Newell <w.newell@TAKEOUTverizon.net> writes:
>>>On Mon, 12 Sep 2005 06:58:58 -0400, George Macdonald wrote:
>>
>>>> Apart from CPU I/O reads/writes and interrupts, a minor part of FSB
>>>> traffic "volume", the HT I/O link has nothing in common with a FSB. The
>>>> major volume of traffic on the K8 HT I/O-link, viz. DMA transfers, is
>>>> handled and routed internally in the north bridge (MC Hub) of a FSB
>>>> type
>>>> system.
>>>
>>>I don't consider the part you consider to be minor, minor. I consider it
>>>the major part. And I assume AND does to, otherwise why replace the the
>>>EV6 bus with HT. It's a fact that with the memory bus now split out of
>>>the
>>>FSB, that the required bandwidth of the FSB (HT Link) dropped
>>>dramatically, since most of the bandwidth in previous FSB applications
>>>was
>>>taken up by memory read/writes. Maybe I should be blaming the Mb
>>>manufactures for using FSB for a term for setting the cpu clkin to begin
>>>with. CPU Host Clock would have been more specific anyway. That would
>>>have
>>>also done away with the real speed of the FSB fiasco. All in all, I'm
>>>getting to the point where I don't much care anymore.
>>>
>>
>>
>> You still haven't grasped the fundamental difference between a
>> point-to-point
>> serial link and a shared bus. HT is a point-to-point serial link. It
>> provides
>> full bandwidth between a processor socket and either another socket (in
>> coherent mode) or a
>> southbridge (e.g. Serverworks HT2000) in non-coherent mode. Since an
>> Opteron
>> has 3 HT links, the inter-socket communications are at full HT bandwidth
>> and
>> are not perturbed in any way by IO traffic over a non-coherent link.
>>
>> The inter-socket communications consist primarily of coherency traffic
>> (probes, (snoops on a FSB)) and memory transfers when one socket requires
>> data from DRAM controlled by another socket.
>>
>> Because the links are point to point, the non-coherent HT link between
>> the processor socket and southbridge gets full bandwidth while the
>> coherent link(s)
>> between processor sockets also get full bandwidth.
>>
>> Contrast this with the shared bandwidth on a FSB and you'll easily see
>> the performance advantages of a point-to-point link like the HT.
>>
>> The advantages hold true for sempron64 and athlon64 as well, even with
>> one HT link, because the HT is never used for memory traffic, unlike a
>> traditional FSB which carries memory and I/O traffic.
>>
>> scott
>
> Scott, you don't seem to have absorbed the essense of this thread which
> seems to be not a discussion of the merits of HT but some sort of argument
> about whether it is acceptable to refer to a HT link as a bus, and whether
> the chip connected to by said link from an amd processor is a "north
> bridge" or something else unnamed, and whether the HT link in question
> connecting the cpu to said chip is a "front side bus".
>
> I hope this clears up things for you.
>
> del
>

Actually once upon a time this thread was about AMD or Intel for gaming
--
Derek

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

"Del Cecchi" <dcecchi.nospam@att.net> writes:
>
>"Scott Lurndal" <scott@slp53.sl.home> wrote in message
>news:OYKVe.708$Jm.655@newssvr27.news.prodigy.net...
>> Wes Newell <w.newell@TAKEOUTverizon.net> writes:
>>>On Mon, 12 Sep 2005 06:58:58 -0400, George Macdonald wrote:
>>
>>>> Apart from CPU I/O reads/writes and interrupts, a minor part of FSB
>>>> traffic "volume", the HT I/O link has nothing in common with a FSB.
>>>> The
>>>> major volume of traffic on the K8 HT I/O-link, viz. DMA transfers, is
>>>> handled and routed internally in the north bridge (MC Hub) of a FSB
>>>> type
>>>> system.
>>>
>>>I don't consider the part you consider to be minor, minor. I consider
>>>it
>>>the major part. And I assume AND does to, otherwise why replace the the
>>>EV6 bus with HT. It's a fact that with the memory bus now split out of
>>>the
>>>FSB, that the required bandwidth of the FSB (HT Link) dropped
>>>dramatically, since most of the bandwidth in previous FSB applications
>>>was
>>>taken up by memory read/writes. Maybe I should be blaming the Mb
>>>manufactures for using FSB for a term for setting the cpu clkin to
>>>begin
>>>with. CPU Host Clock would have been more specific anyway. That would
>>>have
>>>also done away with the real speed of the FSB fiasco. All in all, I'm
>>>getting to the point where I don't much care anymore.
>>>
>>
>>
>> You still haven't grasped the fundamental difference between a
>> point-to-point
>> serial link and a shared bus. HT is a point-to-point serial link. It
>> provides
>> full bandwidth between a processor socket and either another socket (in
>> coherent mode) or a
>> southbridge (e.g. Serverworks HT2000) in non-coherent mode. Since an
>> Opteron
>> has 3 HT links, the inter-socket communications are at full HT
>> bandwidth and
>> are not perturbed in any way by IO traffic over a non-coherent link.
>>
>> The inter-socket communications consist primarily of coherency traffic
>> (probes, (snoops on a FSB)) and memory transfers when one socket
>> requires
>> data from DRAM controlled by another socket.
>>
>> Because the links are point to point, the non-coherent HT link between
>> the processor socket and southbridge gets full bandwidth while the
>> coherent link(s)
>> between processor sockets also get full bandwidth.
>>
>> Contrast this with the shared bandwidth on a FSB and you'll easily see
>> the performance advantages of a point-to-point link like the HT.
>>
>> The advantages hold true for sempron64 and athlon64 as well, even with
>> one HT link, because the HT is never used for memory traffic, unlike a
>> traditional FSB which carries memory and I/O traffic.
>>
>> scott
>
>Scott, you don't seem to have absorbed the essense of this thread which
>seems to be not a discussion of the merits of HT but some sort of
>argument about whether it is acceptable to refer to a HT link as a bus,
>and whether the chip connected to by said link from an amd processor is a
>"north bridge" or something else unnamed, and whether the HT link in
>question connecting the cpu to said chip is a "front side bus".
>
>I hope this clears up things for you.
>
>del
>
>

Del,

It is clearly not a bus. The northbridge is integrated into the
processor die. The other end of an HT link is either another
processor socket or a southbridge.

Hope that answers your query.

scott

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64 (More info?)

Scott Lurndal wrote:
> "Del Cecchi" <dcecchi.nospam@att.net> writes:
>
>>"Scott Lurndal" <scott@slp53.sl.home> wrote in message
>>news:OYKVe.708$Jm.655@newssvr27.news.prodigy.net...
>>
>>>Wes Newell <w.newell@TAKEOUTverizon.net> writes:
>>>
>>>>On Mon, 12 Sep 2005 06:58:58 -0400, George Macdonald wrote:
>>>
>>>>>Apart from CPU I/O reads/writes and interrupts, a minor part of FSB
>>>>>traffic "volume", the HT I/O link has nothing in common with a FSB.
>>>>>The
>>>>>major volume of traffic on the K8 HT I/O-link, viz. DMA transfers, is
>>>>>handled and routed internally in the north bridge (MC Hub) of a FSB
>>>>>type
>>>>>system.
>>>>
>>>>I don't consider the part you consider to be minor, minor. I consider
>>>>it
>>>>the major part. And I assume AND does to, otherwise why replace the the
>>>>EV6 bus with HT. It's a fact that with the memory bus now split out of
>>>>the
>>>>FSB, that the required bandwidth of the FSB (HT Link) dropped
>>>>dramatically, since most of the bandwidth in previous FSB applications
>>>>was
>>>>taken up by memory read/writes. Maybe I should be blaming the Mb
>>>>manufactures for using FSB for a term for setting the cpu clkin to
>>>>begin
>>>>with. CPU Host Clock would have been more specific anyway. That would
>>>>have
>>>>also done away with the real speed of the FSB fiasco. All in all, I'm
>>>>getting to the point where I don't much care anymore.
>>>>
>>>
>>>
>>>You still haven't grasped the fundamental difference between a
>>>point-to-point
>>>serial link and a shared bus. HT is a point-to-point serial link. It
>>>provides
>>>full bandwidth between a processor socket and either another socket (in
>>>coherent mode) or a
>>>southbridge (e.g. Serverworks HT2000) in non-coherent mode. Since an
>>>Opteron
>>>has 3 HT links, the inter-socket communications are at full HT
>>>bandwidth and
>>>are not perturbed in any way by IO traffic over a non-coherent link.
>>>
>>>The inter-socket communications consist primarily of coherency traffic
>>>(probes, (snoops on a FSB)) and memory transfers when one socket
>>>requires
>>>data from DRAM controlled by another socket.
>>>
>>>Because the links are point to point, the non-coherent HT link between
>>>the processor socket and southbridge gets full bandwidth while the
>>>coherent link(s)
>>>between processor sockets also get full bandwidth.
>>>
>>>Contrast this with the shared bandwidth on a FSB and you'll easily see
>>>the performance advantages of a point-to-point link like the HT.
>>>
>>>The advantages hold true for sempron64 and athlon64 as well, even with
>>>one HT link, because the HT is never used for memory traffic, unlike a
>>>traditional FSB which carries memory and I/O traffic.
>>>
>>>scott
>>
>>Scott, you don't seem to have absorbed the essense of this thread which
>>seems to be not a discussion of the merits of HT but some sort of
>>argument about whether it is acceptable to refer to a HT link as a bus,
>>and whether the chip connected to by said link from an amd processor is a
>>"north bridge" or something else unnamed, and whether the HT link in
>>question connecting the cpu to said chip is a "front side bus".
>>
>>I hope this clears up things for you.
>>
>>del
>>
>>
>
>
> Del,
>
> It is clearly not a bus. The northbridge is integrated into the
> processor die. The other end of an HT link is either another
> processor socket or a southbridge.
>
> Hope that answers your query.
>
> scott

North bridge, Southbridge, whatever.

Link, buss, likewise. The HT Link is a bus. A bus is not always a
link. At least among the folks I talk to. Hard to get too excited
about the terminology.

del (followups trimmed)

--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

On Wed, 14 Sep 2005 18:47:12 +0000, Scott Lurndal wrote:

> It is clearly not a bus. The northbridge is integrated into the
> processor die. The other end of an HT link is either another
> processor socket or a southbridge.
>
> Hope that answers your query.
>
It's an answer, just wrong. First, it is a bus, and second, it doesn't
connect to the chipset southbridge, it connects to the chipset
northbridge. Although AMD refers to the logic that splits the memory data
to the internal memory controller a northbridge, well I guess they can
call it whatever they like. The HT link (FSB, CPU bus or whatever you
want to call it) that connects to the chipset connects to the chipset
northbridge (the SIS755 In my case). The SIS755 connects to the
southbridge over a preprietary MUtiol bus. I guess at this point we have
to except that there's 2 northbridges. One in the CPU, and one in the
chipset. Either that or call either AMD or ALL the chipset manufactures
liars for calling there chip a northbridge too. Clearly, what used to be
all done in the chipset northbridge is now partly done in both the cpu and
chipset.

--
KT133 MB, CPU @2400MHz (24x100): SIS755 MB CPU @2330MHz (10x233)
Need good help? Provide all system info with question.
My server http://wesnewell.no-ip.com/cpu.php
Verizon server http://mysite.verizon.net/res0exft/cpu.htm

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

> Actually once upon a time this thread was about AMD or Intel for gaming

Hmmm...


Was that my origonal question

Well I'll be damned...

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.amd.x86-64,comp.sys.ibm.pc.games.action (More info?)

On Thu, 15 Sep 2005 00:10:27 GMT, Wes Newell <w.newell@TAKEOUTverizon.net>
wrote:

>On Wed, 14 Sep 2005 18:47:12 +0000, Scott Lurndal wrote:
>
>> It is clearly not a bus. The northbridge is integrated into the
>> processor die. The other end of an HT link is either another
>> processor socket or a southbridge.
>>
>> Hope that answers your query.
>>
>It's an answer, just wrong. First, it is a bus, and second, it doesn't
>connect to the chipset southbridge, it connects to the chipset
>northbridge. Although AMD refers to the logic that splits the memory data
>to the internal memory controller a northbridge, well I guess they can
>call it whatever they like. The HT link (FSB, CPU bus or whatever you
>want to call it) that connects to the chipset connects to the chipset
>northbridge (the SIS755 In my case). The SIS755 connects to the
>southbridge over a preprietary MUtiol bus. I guess at this point we have
>to except that there's 2 northbridges. One in the CPU, and one in the
>chipset. Either that or call either AMD or ALL the chipset manufactures
>liars for calling there chip a northbridge too. Clearly, what used to be
>all done in the chipset northbridge is now partly done in both the cpu and
>chipset.

Well, where there are still two chips for the "chipset" -- not the case for
nForce3/4 -- there is a *small* amount of north bridge functionality in the
chip at the other end of the CPU<->HT I/O-link: a mezzanine bus to AGP &
PCI-X or the PCI-e x16 graphics link... and maybe some other high
priority/speed link like multi-Gig network but that's piddly compared with
a memory controller and all the arbitration logic plus snooping to the FSB
in a real north bridge. In fact Intel dropped the term North Bridge years
ago and uses MCH for umm, Memory Controller Hub... and AMD would call your
"SIS755 north bridge" a HyperTransport Tunnel. Says it all from my POV -
it doesn't even talk like a duck.🙂

--
Rgds, George Macdonald

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Del Cecchi wrote:
>
> Well, you wanna be picky, cyan is blue. And taupe is tan.

I go away for a couple of weeks and you guys turn into a bunch of
interior decorators ?