Maximum System Bus Speed

Archived from groups: alt.comp.hardware.overclocking (More info?)

What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
GA-7N400 Pro2 by the way
36 answers Last reply
More about maximum system speed
  1. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Ziferten wrote:

    > What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
    > GA-7N400 Pro2 by the way
    >
    >

    It's a 333MHz FSB processor.
  2. Archived from groups: alt.comp.hardware.overclocking (More info?)

    No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is just
    AMD hype to sell the virtues of the DDR bus. Intel do the same trick but
    they multiply the real bus speed by 4x.

    The maximum that the processor will run at depends on many things. If it's
    un-locked you would be able to lower the multiplier and run it on a 200MHz
    FSB, however if its one of the more recent locked models the maximum FSB
    would be in the region of 175-190MHz, depending on how overclockable the cpu
    is, how good your cooling is etc.

    --
    *****Replace 'NOSPAM' with 'btinternet' in the reply address*****
    "David Maynard" <dNOTmayn@ev1.net> wrote in message
    news:1079lpdb7n97p69@corp.supernews.com...
    > Ziferten wrote:
    >
    > > What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
    > > GA-7N400 Pro2 by the way
    > >
    > >
    >
    > It's a 333MHz FSB processor.
    >
  3. Archived from groups: alt.comp.hardware.overclocking (More info?)

    BigBadger wrote:

    > No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is just
    > AMD hype to sell the virtues of the DDR bus. Intel do the same trick but
    > they multiply the real bus speed by 4x.

    Double and quad pumping the bus is not "hype." It's an engineering
    technique for transferring data twice, or 4 times for quad, per clock cycle.

    333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant number
    from a performance standpoint.


    > The maximum that the processor will run at depends on many things. If it's
    > un-locked you would be able to lower the multiplier and run it on a 200MHz
    > FSB, however if its one of the more recent locked models the maximum FSB
    > would be in the region of 175-190MHz, depending on how overclockable the cpu
    > is, how good your cooling is etc.
    >

    He didn't ask what speed he might be able to push it to. He asked "What is
    the maximum that the Athlon XP 2800+ supports?" and the "Maximum System Bus
    Speed" that the processor "supports" is the bus speed it's rated for.
  4. Archived from groups: alt.comp.hardware.overclocking (More info?)

    "Ziferten" wrote
    > What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
    > GA-7N400 Pro2 by the way


    Hi,

    the standard *system bus* for the XP2800+ is 333MHz, but you should be able
    to run it on the 400MHz *system-bus*. This would depend on whether or not
    your CPU was locked.

    I'm not familiar with your mobo.
    --
    Wayne ][
  5. Archived from groups: alt.comp.hardware.overclocking (More info?)

    David Maynard wrote:
    > BigBadger wrote:
    >
    >> No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    >> just
    >> AMD hype to sell the virtues of the DDR bus. Intel do the same trick but
    >> they multiply the real bus speed by 4x.
    >
    >
    > Double and quad pumping the bus is not "hype." It's an engineering
    > technique for transferring data twice, or 4 times for quad, per clock
    > cycle.
    >
    > 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant number
    > from a performance standpoint.

    I don't see much point in arguing this one in technical terms.

    The fact is the term 'FSB' was used for many years to refer to the
    memory/processor bus *clock frequency*, and reusing the same term for
    the bus *bit rate* has caused no end of confusion and was therefore a
    Bad Idea (tm).

    One could also argue that use of the term 'hertz' (as in MHz) in
    reference to anything other than the periodic interval of a waveform is
    incorrect. Heinrich Rudolf is probably spinning in his grave :-)

    Intel themselves can't even get it straight: If you look up P3
    processors at processorfinder.intel.com, 'Bus Speed' x 'Bus/Core Ratio'
    = 'Processor Frequency', but the same calculation yields a number 4x
    bigger than it should be when you look up 'pumped' processors.

    >> The maximum that the processor will run at depends on many things. If
    >> it's
    >> un-locked you would be able to lower the multiplier and run it on a
    >> 200MHz
    >> FSB, however if its one of the more recent locked models the maximum FSB
    >> would be in the region of 175-190MHz, depending on how overclockable
    >> the cpu
    >> is, how good your cooling is etc.
    >>
    >
    > He didn't ask what speed he might be able to push it to. He asked "What
    > is the maximum that the Athlon XP 2800+ supports?" and the "Maximum
    > System Bus Speed" that the processor "supports" is the bus speed it's
    > rated for.
    >
  6. Archived from groups: alt.comp.hardware.overclocking (More info?)

    P2B wrote:

    >
    >
    > David Maynard wrote:
    >
    >> BigBadger wrote:
    >>
    >>> No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    >>> just
    >>> AMD hype to sell the virtues of the DDR bus. Intel do the same trick but
    >>> they multiply the real bus speed by 4x.
    >>
    >>
    >>
    >> Double and quad pumping the bus is not "hype." It's an engineering
    >> technique for transferring data twice, or 4 times for quad, per clock
    >> cycle.
    >>
    >> 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >> number from a performance standpoint.
    >
    >
    > I don't see much point in arguing this one in technical terms.
    >
    > The fact is the term 'FSB' was used for many years to refer to the
    > memory/processor bus *clock frequency*,

    The term "FSB" has always referred to the "Front Side Bus" and not a
    'clock'. What you refer to is simply that, for a considerable length of
    time, the Front Side Bus 'speed', I.E. data rate, was coincident with the
    base rate of the system clock.

    It isn't, however, when the bus is dual or quad pumped.


    > and reusing the same term for
    > the bus *bit rate* has caused no end of confusion and was therefore a
    > Bad Idea (tm).

    I'm not using the term "FSB" to refer to a 'clock' or 'bit rate' or
    anything other than what it's always referred to: the "Front Side Bus."


    > One could also argue that use of the term 'hertz' (as in MHz) in
    > reference to anything other than the periodic interval of a waveform is
    > incorrect. Heinrich Rudolf is probably spinning in his grave :-)

    Yes. In previous discussions I've also pointed out that same argument as
    the perspective of the 'purist'. It does, however, beg the question about
    the data rate of a 166.6Mhz clocked double data rate bus being 333 'what'?
    To which I mused perhaps we should regret having changed from the original
    designation of "Cycles/Second" to "Hertz." (It's interesting to note that
    few would find such a problem with a bus rate designation of 333
    'Mega-Cycles/Second' but do when the synonym "Hertz" is substituted)

    "MHz" may not be a 'purist' form of usage here but it captures the
    pertinent aspect of the bus speed in a context consistent with the single
    data rate bus and is certainly not 'hype', which was the original point.

    I.E. Of what relevance to the 'real' (sic) 'bus speed' is it how the
    designer derived his timing signals? Other than to 'techies', that is.
  7. Archived from groups: alt.comp.hardware.overclocking (More info?)

    ~misfit~ wrote:

    > David Maynard wrote:
    >
    >>BigBadger wrote:
    >>
    >>
    >>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333
    >>>is just AMD hype to sell the virtues of the DDR bus. Intel do the
    >>>same trick but they multiply the real bus speed by 4x.
    >>
    >>Double and quad pumping the bus is not "hype." It's an engineering
    >>technique for transferring data twice, or 4 times for quad, per clock
    >>cycle.
    >>
    >>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>number from a performance standpoint.
    >
    >
    > Yes, but David my friend, you said "333MHz FSB". That is plainly incorrect,
    > the "MHz" part of it.

    Feel free to explain 333 'what' it is ;)
  8. Archived from groups: alt.comp.hardware.overclocking (More info?)

    David Maynard wrote:
    > BigBadger wrote:
    >
    >> No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333
    >> is just AMD hype to sell the virtues of the DDR bus. Intel do the
    >> same trick but they multiply the real bus speed by 4x.
    >
    > Double and quad pumping the bus is not "hype." It's an engineering
    > technique for transferring data twice, or 4 times for quad, per clock
    > cycle.
    >
    > 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    > number from a performance standpoint.

    Oh dear, oh dear, here we go again ... :) It depends on whether you measure
    the control lines or the data lines for quoting the "bus speed" number.

    I actually think a more accurate way of representing it (performance-wise)
    is a 128-bit bus (DDR) or 256-bit bus (QDR), both running at 166MHz. A good
    example is the latency for main memory. Say you have a 166MHz DDR system
    (aka DDR333), and a 100MHz QDR system (aka QDR400), and the CPU runs at 1GHz
    (6.0x for DDR, 10.0x for QDR). Excluding memory latencies, to fill a
    randomly-accessed 64-byte cache line would take:
    Waiting for bus strobe: 3.0 cycles (DDR system), 5.0 cycles (QDR system)
    Transferring data: 24 cycles (DDR), 20 cycles (QDR)
    Total: 27 cycles (DDR), 25 cycles (QDR)
    So DDR333 is, under random access conditions, only marginally slower than
    QDR400. The actual break-even point is 180MHz (actually slightly above due
    to memory latencies), but hopefully you get the idea. Of course, the QDR
    system will perform better under "streaming" type conditions, where the
    higher latency won't matter so much.

    Incidentally, this issue is exasparated by the P4's 128-byte cache line, as
    opposed to the 64-byte cache line of the K7.

    Finally, using the non-multiplied speed would stop people complaining that
    their motherboard only goes up to 250MHz :)

    [...]

    --
    Michael Brown
    www.emboss.co.nz : OOS/RSI software and more :)
    Add michael@ to emboss.co.nz - My inbox is always open
  9. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Michael Brown wrote:
    > David Maynard wrote:
    >
    >>BigBadger wrote:
    >>
    >>
    >>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333
    >>>is just AMD hype to sell the virtues of the DDR bus. Intel do the
    >>>same trick but they multiply the real bus speed by 4x.
    >>
    >>Double and quad pumping the bus is not "hype." It's an engineering
    >>technique for transferring data twice, or 4 times for quad, per clock
    >>cycle.
    >>
    >>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>number from a performance standpoint.
    >
    >
    > Oh dear, oh dear, here we go again ... :) It depends on whether you measure
    > the control lines or the data lines for quoting the "bus speed" number.

    No it doesn't. It has to do with how many data transfer cycles there are.

    > I actually think a more accurate way of representing it (performance-wise)
    > is a 128-bit bus (DDR) or 256-bit bus (QDR), both running at 166MHz.

    Except it isn't '128 bits' or '256 bits' wide. It does, however, transfer
    data at either 2, for dual pumped, or 4 times, for quad pumped, the system
    clock rate.

    > A good
    > example is the latency for main memory.

    Which is a separate component independent of the bus and not even ON, or
    even necessarily run at the speed of, the bus at issue.

    > Say you have a 166MHz DDR system
    > (aka DDR333), and a 100MHz QDR system (aka QDR400), and the CPU runs at 1GHz
    > (6.0x for DDR, 10.0x for QDR). Excluding memory latencies, to fill a
    > randomly-accessed 64-byte cache line would take:
    > Waiting for bus strobe: 3.0 cycles (DDR system), 5.0 cycles (QDR system)
    > Transferring data: 24 cycles (DDR), 20 cycles (QDR)
    > Total: 27 cycles (DDR), 25 cycles (QDR)
    >
    > So DDR333 is, under random access conditions, only marginally slower than
    > QDR400. The actual break-even point is 180MHz (actually slightly above due
    > to memory latencies), but hopefully you get the idea. Of course, the QDR
    > system will perform better under "streaming" type conditions, where the
    > higher latency won't matter so much.

    No, you're analyzing the memory, not the processor bus.

    We can sit here all day long proposing new terminology but that's
    irrelevant to the matter.


    > Incidentally, this issue is exasparated by the P4's 128-byte cache line, as
    > opposed to the 64-byte cache line of the K7.

    Processor (L2) cache has nothing to do with bus speed. It affects processor
    performance, of course, but then so does the L1 cache, cpu architecture,
    and core speed: none of which have anything to do with the bus speed either.

    Btw, what don't you call a 3.4 Gig P4 a 200Mhz P4 because the 'real clock'
    (sic) is 200 Mhz. That 3.4 Gig number is just 'hype'.

    > Finally, using the non-multiplied speed would stop people complaining that
    > their motherboard only goes up to 250MHz :)

    Requiring everyone to use the same bus and speed would solve it too but
    that hardly means it's desirable.

    >
    > [...]
    >
    > --
    > Michael Brown
    > www.emboss.co.nz : OOS/RSI software and more :)
    > Add michael@ to emboss.co.nz - My inbox is always open
    >
    >
  10. Archived from groups: alt.comp.hardware.overclocking (More info?)

    A bus must follow the same speed limits as private automobiles; measured in
    KPh or MPh (Kilo packets pre hour or Mega Packets per hour. So these
    processor Front Side Buses are vastly exceeding legal limits, and should be
    reined in. Likely pumping the accelerator too often is the cause.

    --
    Phil Weldon, pweldonatmindjumpdotcom
    For communication,
    replace "at" with the 'at sign'
    replace "mindjump" with "mindspring."
    replace "dot" with "."
  11. Archived from groups: alt.comp.hardware.overclocking (More info?)

    ~misfit~ wrote:

    > David Maynard wrote:
    >
    >>~misfit~ wrote:
    >>
    >>
    >>>David Maynard wrote:
    >>>
    >>>
    >>>>BigBadger wrote:
    >>>>
    >>>>
    >>>>
    >>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333
    >>>>>is just AMD hype to sell the virtues of the DDR bus. Intel do the
    >>>>>same trick but they multiply the real bus speed by 4x.
    >>>>
    >>>>Double and quad pumping the bus is not "hype." It's an engineering
    >>>>technique for transferring data twice, or 4 times for quad, per
    >>>>clock cycle.
    >>>>
    >>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>>>number from a performance standpoint.
    >>>
    >>>
    >>>Yes, but David my friend, you said "333MHz FSB". That is plainly
    >>>incorrect, the "MHz" part of it.
    >>
    >>Feel free to explain 333 'what' it is ;)
    >
    >
    > MegaSignals/second (MS/s). <g> Two signals per hertz.

    Hehe. Sure. That'll clear it up.

    I can just hear it now: people complaining it's (really) 'MicroSofts'/s ;)

    Btw, Hertz is defined as "hertz (Hz): 1. The SI unit of frequency, equal to
    one cycle per second. Note: A periodic phenomenon that has a period of one
    second has a frequency of one hertz. (188) 2. A unit of frequency which is
    equivalent to one cycle per second."

    http://www.its.bldrdoc.gov/fs-1037/dir-018/_2563.htm

    And the data transfer rate qualifies as "a periodic phenomenon."

    "Frequency" is not just an electrical term and is not restricted to
    electronic waveforms.

    You have to be careful about sloppy definitions. For example, look at this
    one: http://www.webopedia.com/TERM/H/Hz.html

    "Short for Hertz, a unit of frequency of electrical vibrations equal to one
    cycle per second. The Hertz is named after Heinrich Hertz, who first
    detected electromagnetic waves."

    Oh really? Only "electrical vibrations?" So Hertz doesn't apply to sound
    waves? The range of human hearing isn't 20 Hz to 20,000 Hz?

    Then we're going to have to send all our astrophysicists back to school too
    because they think frequency applies to orbits.

    http://arxiv.org/abs/astro-ph/0110209

    "We compute the maximum orbital frequency of stable circular motion around
    uniformly rotating strange stars described by the MIT bag model. The
    calculations are performed for both normal and supramassive constant baryon
    mass sequences of strange stars rotating at all possible rates. We find the
    lower limits on the maximum orbital frequency and discuss them for a range
    of masses and for all rotational frequencies allowed in the model
    considered. We show that for slowly and moderately rotating strange stars
    the maximum value of orbital frequency can be a good indicator of the mass
    of the compact object. However, for rapidly rotating strange stars the same
    value of orbital frequency in the innermost stable circular orbit is
    obtained for stars with masses ranging from that of a planetoid to about
    three solar masses. At sufficiently high rotation rates of the strange
    star, the rotational period alone constrains the stellar mass to a
    surprisingly narrow range."


    That second definition falls into the trap I allude to with my lament of
    the change from Cycles/s to Hertz: that using the name "Hertz" suddenly
    limits the scope.
  12. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Alright, so I didn't get an answer, but I learned way more about Hertz!
    "Ziferten" <ehaag_0@hotmail.com> wrote in message
    news:rV3dc.23273$YC5.20163@twister.rdc-kc.rr.com...
    > What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
    > GA-7N400 Pro2 by the way
    >
    >
  13. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Ziferten wrote:
    > Alright, so I didn't get an answer, but I learned way more about Hertz!

    Hehe. Well, actually you did. What it "supports" is what it's rated at.

    I rather suspect you want to know what you can 'get out of it' and that was
    answered too.


    > "Ziferten" <ehaag_0@hotmail.com> wrote in message
    > news:rV3dc.23273$YC5.20163@twister.rdc-kc.rr.com...
    >
    >>What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
    >>GA-7N400 Pro2 by the way
    >>
    >>
    >
    >
    >
  14. Archived from groups: alt.comp.hardware.overclocking (More info?)

    You said 333MHz...a MHz is a measure of frequency. The frequency in MHz of a
    XP2800+ FSB is 166...end of story.

    --
    *****Replace 'NOSPAM' with 'btinternet' in the reply address*****
    "David Maynard" <dNOTmayn@ev1.net> wrote in message
    news:107a2lp7v48lta7@corp.supernews.com...
    > BigBadger wrote:
    >
    > > No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    just
    > > AMD hype to sell the virtues of the DDR bus. Intel do the same trick but
    > > they multiply the real bus speed by 4x.
    >
    > Double and quad pumping the bus is not "hype." It's an engineering
    > technique for transferring data twice, or 4 times for quad, per clock
    cycle.
    >
    > 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant number
    > from a performance standpoint.
    >
    >
    > > The maximum that the processor will run at depends on many things. If
    it's
    > > un-locked you would be able to lower the multiplier and run it on a
    200MHz
    > > FSB, however if its one of the more recent locked models the maximum FSB
    > > would be in the region of 175-190MHz, depending on how overclockable the
    cpu
    > > is, how good your cooling is etc.
    > >
    >
    > He didn't ask what speed he might be able to push it to. He asked "What is
    > the maximum that the Athlon XP 2800+ supports?" and the "Maximum System
    Bus
    > Speed" that the processor "supports" is the bus speed it's rated for.
    >
  15. Archived from groups: alt.comp.hardware.overclocking (More info?)

    BigBadger wrote:

    > You said 333MHz...a MHz is a measure of frequency. The frequency in MHz of a
    > XP2800+ FSB is 166...end of story.
    >

    Yes. Hertz is "a measure of frequency." It's your assumption that a 'clock'
    is the only thing of interest that's the problem.

    The bus data rate of an XP2800+ is 333Mhz because that is the frequency of
    data arrival.
  16. Archived from groups: alt.comp.hardware.overclocking (More info?)

    kinda.... i was really after whether or not the 200(MHz? : )) bus was safe
    for the processor
    "David Maynard" <dNOTmayn@ev1.net> wrote in message
    news:107e56l2817b35a@corp.supernews.com...
    > Ziferten wrote:
    > > Alright, so I didn't get an answer, but I learned way more about Hertz!
    >
    > Hehe. Well, actually you did. What it "supports" is what it's rated at.
    >
    > I rather suspect you want to know what you can 'get out of it' and that
    was
    > answered too.
    >
    >
    > > "Ziferten" <ehaag_0@hotmail.com> wrote in message
    > > news:rV3dc.23273$YC5.20163@twister.rdc-kc.rr.com...
    > >
    > >>What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
    > >>GA-7N400 Pro2 by the way
    > >>
    > >>
    > >
    > >
    > >
    >
  17. Archived from groups: alt.comp.hardware.overclocking (More info?)

    >
    > Yes. In previous discussions I've also pointed out that same argument as
    > the perspective of the 'purist'. It does, however, beg the question about
    > the data rate of a 166.6Mhz clocked double data rate bus being 333 'what'?
    > To which I mused perhaps we should regret having changed from the original
    > designation of "Cycles/Second" to "Hertz." (It's interesting to note that
    > few would find such a problem with a bus rate designation of 333
    > 'Mega-Cycles/Second' but do when the synonym "Hertz" is substituted)
    >
    Hertz is a measure of Mega Cycles per second...we both agree on that.
    The dictionary 'physics' definition of a cycle is:
    one complete oscillation: one complete continuous change in the magnitude of
    an oscillating quantity or system that brings the system back to its
    original energy state.
    Therefore it does not matter how many data points is carried on the wave,
    the frequency is the number of cycles (or oscillations) per second and for
    an XP2800+ this is 166,600,000....or 166MHz
  18. Archived from groups: alt.comp.hardware.overclocking (More info?)

    BigBadger wrote:

    >>Yes. In previous discussions I've also pointed out that same argument as
    >>the perspective of the 'purist'. It does, however, beg the question about
    >>the data rate of a 166.6Mhz clocked double data rate bus being 333 'what'?
    >>To which I mused perhaps we should regret having changed from the original
    >>designation of "Cycles/Second" to "Hertz." (It's interesting to note that
    >>few would find such a problem with a bus rate designation of 333
    >>'Mega-Cycles/Second' but do when the synonym "Hertz" is substituted)
    >>
    >
    > Hertz is a measure of Mega Cycles per second...we both agree on that.

    Yep. Now, cycles of what?

    > The dictionary 'physics' definition of a cycle is:
    > one complete oscillation: one complete continuous change in the magnitude of
    > an oscillating quantity or system that brings the system back to its
    > original energy state.
    > Therefore it does not matter how many data points is carried on the wave,
    > the frequency is the number of cycles (or oscillations) per second and for
    > an XP2800+ this is 166,600,000....or 166MHz

    Except that we aren't talking about the 'physics' of a waveform in this
    context. We're talking about the bus data rate and that is 333Mhz.

    Let me give an analogy. Do you care what the magnetic flux on the platters
    in a 120 gig hard drive looks like? Do you care if it's FM encoded, or MFM
    encoded, or RLL encoded? No, all you care about is that it stores 120 gig.
    That is the 'relevant' summary information: the data you get.

    The same applies to the bus. It is of technical interest that it's a
    166.6MHZ clocked double data rate bus but the summary of interest is that
    it transfers data at 333MHz.

    Both representations are perfectly valid in the context of what they are
    describing and neither is 'hype'.
  19. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Ziferten wrote:

    > kinda.... i was really after whether or not the 200(MHz? : )) bus was safe
    > for the processor

    A 200Mhz bus (in this case you mean the base clock rate) is 'safe' in that
    it, alone, isn't going to physically damage the processor.

    Whether it will run at that speed is a bit more problematic.

    As an example, I have an AMD mobile, 512K cache (Barton), 2400+ running
    2,400MHz on a 200MHz (base clock rate) bus although it's spec'd for a
    133.3Mhz (base clock rate) bus. But I was able to run it like that because
    it's multiplier is unlocked and it took overvolting the processor, memory,
    and the chipset (probably because the memory is el-cheapo junk).


    > "David Maynard" <dNOTmayn@ev1.net> wrote in message
    > news:107e56l2817b35a@corp.supernews.com...
    >
    >>Ziferten wrote:
    >>
    >>>Alright, so I didn't get an answer, but I learned way more about Hertz!
    >>
    >>Hehe. Well, actually you did. What it "supports" is what it's rated at.
    >>
    >>I rather suspect you want to know what you can 'get out of it' and that
    >
    > was
    >
    >>answered too.
    >>
    >>
    >>
    >>>"Ziferten" <ehaag_0@hotmail.com> wrote in message
    >>>news:rV3dc.23273$YC5.20163@twister.rdc-kc.rr.com...
    >>>
    >>>
    >>>>What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte
    >>>>GA-7N400 Pro2 by the way
    >>>>
    >>>>
    >>>
    >>>
    >>>
    >
    >
  20. Archived from groups: alt.comp.hardware.overclocking (More info?)

    ~misfit~ wrote:

    > David Maynard wrote:
    >
    >>~misfit~ wrote:
    >>
    >>
    >>>David Maynard wrote:
    >>>
    >>>
    >>>>~misfit~ wrote:
    >>>>
    >>>>
    >>>>
    >>>>>David Maynard wrote:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>BigBadger wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB
    >>>>>>>processor....333 is just AMD hype to sell the virtues of the DDR
    >>>>>>>bus. Intel do the same trick but they multiply the real bus
    >>>>>>>speed by 4x.
    >>>>>>
    >>>>>>Double and quad pumping the bus is not "hype." It's an engineering
    >>>>>>technique for transferring data twice, or 4 times for quad, per
    >>>>>>clock cycle.
    >>>>>>
    >>>>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>>>>>number from a performance standpoint.
    >>>>>
    >>>>>
    >>>>>Yes, but David my friend, you said "333MHz FSB". That is plainly
    >>>>>incorrect, the "MHz" part of it.
    >>>>
    >>>>Feel free to explain 333 'what' it is ;)
    >>>
    >>>
    >>>MegaSignals/second (MS/s). <g> Two signals per hertz.
    >>
    >>Hehe. Sure. That'll clear it up.
    >>
    >>I can just hear it now: people complaining it's (really)
    >>'MicroSofts'/s ;)
    >>
    >>Btw, Hertz is defined as "hertz (Hz): 1. The SI unit of frequency,
    >>equal to one cycle per second. Note: A periodic phenomenon that has a
    >>period of one second has a frequency of one hertz. (188) 2. A unit of
    >>frequency which is equivalent to one cycle per second."
    >>
    >>http://www.its.bldrdoc.gov/fs-1037/dir-018/_2563.htm
    >>
    >>And the data transfer rate qualifies as "a periodic phenomenon."
    >>
    >>"Frequency" is not just an electrical term and is not restricted to
    >>electronic waveforms.
    >>
    >>You have to be careful about sloppy definitions. For example, look at
    >>this one: http://www.webopedia.com/TERM/H/Hz.html
    >>
    >>"Short for Hertz, a unit of frequency of electrical vibrations equal
    >>to one cycle per second. The Hertz is named after Heinrich Hertz, who
    >>first detected electromagnetic waves."
    >>
    >>Oh really? Only "electrical vibrations?" So Hertz doesn't apply to
    >>sound waves? The range of human hearing isn't 20 Hz to 20,000 Hz?
    >>
    >>Then we're going to have to send all our astrophysicists back to
    >>school too because they think frequency applies to orbits.
    >>
    >>http://arxiv.org/abs/astro-ph/0110209
    >>
    >>"We compute the maximum orbital frequency of stable circular motion
    >>around uniformly rotating strange stars described by the MIT bag
    >>model. The calculations are performed for both normal and
    >>supramassive constant baryon mass sequences of strange stars rotating
    >>at all possible rates. We find the lower limits on the maximum
    >>orbital frequency and discuss them for a range of masses and for all
    >>rotational frequencies allowed in the model considered. We show that
    >>for slowly and moderately rotating strange stars the maximum value of
    >>orbital frequency can be a good indicator of the mass of the compact
    >>object. However, for rapidly rotating strange stars the same value of
    >>orbital frequency in the innermost stable circular orbit is obtained
    >>for stars with masses ranging from that of a planetoid to about three
    >>solar masses. At sufficiently high rotation rates of the strange
    >>star, the rotational period alone constrains the stellar mass to a
    >>surprisingly narrow range."
    >>
    >>
    >>That second definition falls into the trap I allude to with my lament
    >>of the change from Cycles/s to Hertz: that using the name "Hertz"
    >>suddenly limits the scope.
    >
    >
    > Yup, it's a mine-field. I just personally have an aversion to people talking
    > about "800MHz" (FI) FSB's when it's really 200Mhz. Paint me pedantic.

    When "it's" the base clock you're right. But when "it's" the data rate then
    "it's" 'really' 800MHz.


    > --
    > ~misfit~
    >
    >
  21. Archived from groups: alt.comp.hardware.overclocking (More info?)

    The data transfer occurs 800,000,000 times per second. There are
    800,000,000 clocking edges per second, on each of which a transfer of the
    full bus width occurs. Now, is it more meaningful to call that transfering
    at a rate of 800,000,000 times per second or 200,000,000 X times 4 per
    second? As for the clocks that controls the memory, they generate
    400,000,000 pulses per second, and are derived from 800,000,000 pulses per
    second (to get the offset.) The FSB transfers to and from memory at 800 MHz
    for Pentium 4 CPU's rated for that. You can call it anything you want to,
    but you may not be understood, and certainly you will not change reality.

    --
    Phil Weldon, pweldonatmindjumpdotcom
    For communication,
    replace "at" with the 'at sign'
    replace "mindjump" with "mindspring."
    replace "dot" with "."


    "~misfit~" <misfit61nz@yahoomung.co.nz> wrote in message
    news:AbHdc.10438$d%6.184741@news.xtra.co.nz...
    > David Maynard wrote:
    > > ~misfit~ wrote:
    > >
    > >> David Maynard wrote:
    > >>
    > >>> ~misfit~ wrote:
    > >>>
    > >>>
    > >>>> David Maynard wrote:
    > >>>>
    > >>>>
    > >>>>> BigBadger wrote:
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>>> No it's not 333MHz, it's actually a 166 'MHz' FSB
    > >>>>>> processor....333 is just AMD hype to sell the virtues of the DDR
    > >>>>>> bus. Intel do the same trick but they multiply the real bus
    > >>>>>> speed by 4x.
    > >>>>>
    > >>>>> Double and quad pumping the bus is not "hype." It's an engineering
    > >>>>> technique for transferring data twice, or 4 times for quad, per
    > >>>>> clock cycle.
    > >>>>>
    > >>>>> 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    > >>>>> number from a performance standpoint.
    > >>>>
    > >>>>
    > >>>> Yes, but David my friend, you said "333MHz FSB". That is plainly
    > >>>> incorrect, the "MHz" part of it.
    > >>>
    > >>> Feel free to explain 333 'what' it is ;)
    > >>
    > >>
    > >> MegaSignals/second (MS/s). <g> Two signals per hertz.
    > >
    > > Hehe. Sure. That'll clear it up.
    > >
    > > I can just hear it now: people complaining it's (really)
    > > 'MicroSofts'/s ;)
    > >
    > > Btw, Hertz is defined as "hertz (Hz): 1. The SI unit of frequency,
    > > equal to one cycle per second. Note: A periodic phenomenon that has a
    > > period of one second has a frequency of one hertz. (188) 2. A unit of
    > > frequency which is equivalent to one cycle per second."
    > >
    > > http://www.its.bldrdoc.gov/fs-1037/dir-018/_2563.htm
    > >
    > > And the data transfer rate qualifies as "a periodic phenomenon."
    > >
    > > "Frequency" is not just an electrical term and is not restricted to
    > > electronic waveforms.
    > >
    > > You have to be careful about sloppy definitions. For example, look at
    > > this one: http://www.webopedia.com/TERM/H/Hz.html
    > >
    > > "Short for Hertz, a unit of frequency of electrical vibrations equal
    > > to one cycle per second. The Hertz is named after Heinrich Hertz, who
    > > first detected electromagnetic waves."
    > >
    > > Oh really? Only "electrical vibrations?" So Hertz doesn't apply to
    > > sound waves? The range of human hearing isn't 20 Hz to 20,000 Hz?
    > >
    > > Then we're going to have to send all our astrophysicists back to
    > > school too because they think frequency applies to orbits.
    > >
    > > http://arxiv.org/abs/astro-ph/0110209
    > >
    > > "We compute the maximum orbital frequency of stable circular motion
    > > around uniformly rotating strange stars described by the MIT bag
    > > model. The calculations are performed for both normal and
    > > supramassive constant baryon mass sequences of strange stars rotating
    > > at all possible rates. We find the lower limits on the maximum
    > > orbital frequency and discuss them for a range of masses and for all
    > > rotational frequencies allowed in the model considered. We show that
    > > for slowly and moderately rotating strange stars the maximum value of
    > > orbital frequency can be a good indicator of the mass of the compact
    > > object. However, for rapidly rotating strange stars the same value of
    > > orbital frequency in the innermost stable circular orbit is obtained
    > > for stars with masses ranging from that of a planetoid to about three
    > > solar masses. At sufficiently high rotation rates of the strange
    > > star, the rotational period alone constrains the stellar mass to a
    > > surprisingly narrow range."
    > >
    > >
    > > That second definition falls into the trap I allude to with my lament
    > > of the change from Cycles/s to Hertz: that using the name "Hertz"
    > > suddenly limits the scope.
    >
    > Yup, it's a mine-field. I just personally have an aversion to people
    talking
    > about "800MHz" (FI) FSB's when it's really 200Mhz. Paint me pedantic.
    > --
    > ~misfit~
    >
    >
  22. Archived from groups: alt.comp.hardware.overclocking (More info?)

    David Maynard wrote:
    > Michael Brown wrote:
    >> David Maynard wrote:
    >>> BigBadger wrote:
    >>>> No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333
    >>>> is just AMD hype to sell the virtues of the DDR bus. Intel do the
    >>>> same trick but they multiply the real bus speed by 4x.
    >>>
    >>> Double and quad pumping the bus is not "hype." It's an engineering
    >>> technique for transferring data twice, or 4 times for quad, per
    >>> clock cycle.
    >>>
    >>> 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>> number from a performance standpoint.
    >>
    >> Oh dear, oh dear, here we go again ... :) It depends on whether you
    >> measure the control lines or the data lines for quoting the "bus
    >> speed" number.
    >
    > No it doesn't. It has to do with how many data transfer cycles there
    > are.

    This is exactly what I mean :) There are some lines on the bus that
    "operate" at <x> MHz, and some that "operate" at <4*x> MHz. What, then, is
    the bus speed? There are valid arguments for both directions. From a
    performance standpoint, I personally think the <x> MHz number is better (and
    expand the "bus width" accordingly); you obviously think the MHz should be
    scaled.

    >> I actually think a more accurate way of representing it
    >> (performance-wise) is a 128-bit bus (DDR) or 256-bit bus (QDR), both
    >> running at 166MHz.
    >
    > Except it isn't '128 bits' or '256 bits' wide. It does, however,
    > transfer data at either 2, for dual pumped, or 4 times, for quad
    > pumped, the system clock rate.

    Hence why I explicitly said "performance-wise". The question I was answering
    was:
    Which closer represents the performance of a 64 bit <x> MHz QDR bus?
    (a) A 64-bit <4*x> MHz SDR bus
    (b) A 256-bit <x> MHz SDR bus
    The correct answer is (b).

    Of course, at the low level, it's still a 64-bit bus, except one part is
    operating at <x> MHz and another part at <4*x> MHz.

    [...]
    >> Say you have a 166MHz DDR system
    >> (aka DDR333), and a 100MHz QDR system (aka QDR400), and the CPU runs
    >> at 1GHz (6.0x for DDR, 10.0x for QDR). Excluding memory latencies,
    >> to fill a randomly-accessed 64-byte cache line would take:
    >> Waiting for bus strobe: 3.0 cycles (DDR system), 5.0 cycles (QDR
    >> system) Transferring data: 24 cycles (DDR), 20 cycles (QDR)
    >> Total: 27 cycles (DDR), 25 cycles (QDR)
    >>
    >> So DDR333 is, under random access conditions, only marginally slower
    >> than QDR400. The actual break-even point is 180MHz (actually
    >> slightly above due to memory latencies), but hopefully you get the
    >> idea. Of course, the QDR system will perform better under
    >> "streaming" type conditions, where the higher latency won't matter
    >> so much.
    >
    > No, you're analyzing the memory, not the processor bus.

    Errm, not at all. I specifically EXCLUDE any memory performance
    considerations from the analysis: see the third line of your quoted section.
    I'm solely analysing how long it would take to fill (or write out) a
    processor cache line over a DDR/QDR bus, which is pretty much all the
    processor bus is used for. The exact same argument applies to the
    point-to-point DDR busses in a K7 SMP system, if having memory in the
    picture makes things confusing for you.

    [...]
    >> Incidentally, this issue is exasparated by the P4's 128-byte cache
    >> line, as opposed to the 64-byte cache line of the K7.
    >
    > Processor (L2) cache has nothing to do with bus speed.

    Hence my "incidentally" (spot the recurring theme here: I don't usually put
    in words for no reason). The processor cache line size (note: cache LINE
    size, not cache size or anything else) and bus performance characteristics
    are quite interlinked for the performance of a processor. The larger cache
    line size improves streaming performance and decreases random-access
    performance, which is exactly the same characteristics as a QDR bus. My
    point was that the P4 has been heavily tweaked towards streaming
    computations, as opposed to having fast random-access times.

    [...]
    > Btw, what don't you call a 3.4 Gig P4 a 200Mhz P4 because the 'real
    > clock' (sic) is 200 Mhz. That 3.4 Gig number is just 'hype'.

    Why don't you call it a 6.8GHz P4? :P

    I call it a 3.4GHz CPU because it operates on a 3.4GHz clock rate. The
    external signalling is at 200MHz or 800MHz, but this has not the operating
    frequency of the CPU itself. DDR/QDR is a much trickier problem, as part of
    it is operating at 200MHz, and another part at 800MHz. Sort of as if the
    ALUs all operated at 6.8GHz and the floating point units all operated at
    3.4GHz. Oh, dearie me ...

    [...]

    --
    Michael Brown
    www.emboss.co.nz : OOS/RSI software and more :)
    Add michael@ to emboss.co.nz - My inbox is always open
  23. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Michael Brown wrote:
    > David Maynard wrote:
    >
    >>Michael Brown wrote:
    >>
    >>>David Maynard wrote:
    >>>
    >>>>BigBadger wrote:
    >>>>
    >>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333
    >>>>>is just AMD hype to sell the virtues of the DDR bus. Intel do the
    >>>>>same trick but they multiply the real bus speed by 4x.
    >>>>
    >>>>Double and quad pumping the bus is not "hype." It's an engineering
    >>>>technique for transferring data twice, or 4 times for quad, per
    >>>>clock cycle.
    >>>>
    >>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>>>number from a performance standpoint.
    >>>
    >>>Oh dear, oh dear, here we go again ... :) It depends on whether you
    >>>measure the control lines or the data lines for quoting the "bus
    >>>speed" number.
    >>
    >>No it doesn't. It has to do with how many data transfer cycles there
    >>are.
    >
    >
    > This is exactly what I mean :) There are some lines on the bus that
    > "operate" at <x> MHz, and some that "operate" at <4*x> MHz.

    It is irrelevant what "some lines" do. What's relevant is the data rate.


    > What, then, is
    > the bus speed?

    The bus 'speed' is the data rate.

    > There are valid arguments for both directions. From a
    > performance standpoint, I personally think the <x> MHz number is better (and
    > expand the "bus width" accordingly); you obviously think the MHz should be
    > scaled.

    It isn't a matter of 'scaling' anything. The data rate is the data rate.


    >>>I actually think a more accurate way of representing it
    >>>(performance-wise) is a 128-bit bus (DDR) or 256-bit bus (QDR), both
    >>>running at 166MHz.
    >>
    >>Except it isn't '128 bits' or '256 bits' wide. It does, however,
    >>transfer data at either 2, for dual pumped, or 4 times, for quad
    >>pumped, the system clock rate.
    >
    >
    > Hence why I explicitly said "performance-wise". The question I was answering
    > was:
    > Which closer represents the performance of a 64 bit <x> MHz QDR bus?
    > (a) A 64-bit <4*x> MHz SDR bus
    > (b) A 256-bit <x> MHz SDR bus
    > The correct answer is (b).

    The correct answer is (a) because that is REALITY. (b) is a figment of your
    imagination.


    > Of course, at the low level, it's still a 64-bit bus, except one part is
    > operating at <x> MHz and another part at <4*x> MHz.

    Nope. All the bits of the data arrive at precisely the same rate.

    >
    > [...]
    >
    >>>Say you have a 166MHz DDR system
    >>>(aka DDR333), and a 100MHz QDR system (aka QDR400), and the CPU runs
    >>>at 1GHz (6.0x for DDR, 10.0x for QDR). Excluding memory latencies,
    >>>to fill a randomly-accessed 64-byte cache line would take:
    >>> Waiting for bus strobe: 3.0 cycles (DDR system), 5.0 cycles (QDR
    >>> system) Transferring data: 24 cycles (DDR), 20 cycles (QDR)
    >>> Total: 27 cycles (DDR), 25 cycles (QDR)
    >>>
    >>>So DDR333 is, under random access conditions, only marginally slower
    >>>than QDR400. The actual break-even point is 180MHz (actually
    >>>slightly above due to memory latencies), but hopefully you get the
    >>>idea. Of course, the QDR system will perform better under
    >>>"streaming" type conditions, where the higher latency won't matter
    >>>so much.
    >>
    >>No, you're analyzing the memory, not the processor bus.
    >
    >
    > Errm, not at all. I specifically EXCLUDE any memory performance
    > considerations from the analysis: see the third line of your quoted section.

    You claim to be excluding it but you embed it in your analysis nonetheless.

    You also create artificial conditions in direct contrast to reality by, for
    example, trying to limit the analysis to 'random access' on a bus that is
    specifically designed for, optimized for, and RATED AT it's synchronous
    stream transfer rate whether it be SDR, DDR, or QDR.

    Heck, the names you (properly) use explain it even as you're denying it:
    SRD - Single DATA RATE, DDR - Double DATA RATE, QDR - Quad DATA RATE.


    > I'm solely analysing how long it would take to fill (or write out) a
    > processor cache line over a DDR/QDR bus, which is pretty much all the
    > processor bus is used for.
    > The exact same argument applies to the
    > point-to-point DDR busses in a K7 SMP system, if having memory in the
    > picture makes things confusing for you.

    You can wag imaginative theories and pick artificial 'conditions' all you
    want. I'm telling you how it works.

    >
    > [...]
    >
    >>>Incidentally, this issue is exasparated by the P4's 128-byte cache
    >>>line, as opposed to the 64-byte cache line of the K7.
    >>
    >>Processor (L2) cache has nothing to do with bus speed.
    >
    >
    > Hence my "incidentally" (spot the recurring theme here: I don't usually put
    > in words for no reason). The processor cache line size (note: cache LINE
    > size, not cache size or anything else) and bus performance characteristics
    > are quite interlinked for the performance of a processor. The larger cache
    > line size improves streaming performance and decreases random-access
    > performance, which is exactly the same characteristics as a QDR bus. My
    > point was that the P4 has been heavily tweaked towards streaming
    > computations, as opposed to having fast random-access times.

    We aren't talking about the "performance of a processor." We're talking
    about the bus data rate.

    > [...]
    >
    >>Btw, what don't you call a 3.4 Gig P4 a 200Mhz P4 because the 'real
    >>clock' (sic) is 200 Mhz. That 3.4 Gig number is just 'hype'.
    >
    >
    > Why don't you call it a 6.8GHz P4? :P

    Because the reality of it is that it's operating at 3.4 GHz.

    > I call it a 3.4GHz CPU because it operates on a 3.4GHz clock rate. The
    > external signalling is at 200MHz or 800MHz, but this has not the operating
    > frequency of the CPU itself.

    Well, close. Yes, it operates at 3.4 Ghz but the "external signaling" is an
    irrelevant comment. A 3.4 Gig processor is a 3.4 Gig processor regardless
    of the bus speed or even what external clock it derives it's internal clock
    from; as long as the internal clock ends up at 3.4 Ghz. And it doesn't
    matter if it comes from single pumping, dual pumping, quad pumping, hex
    pumping, or any other multiplier of the external clock.

    > DDR/QDR is a much trickier problem, as part of
    > it is operating at 200MHz, and another part at 800MHz.

    Nope, and it's not tricky at all. A 166.6 MHz clocked DDR bus has a stream
    rate of 333 million data cycles per second and a 200 MHz clocked Quad
    pumped bus has a stream rate of 800 million data cycles per second. Which,
    btw, is independednt of the bus width.

    Hertz is the synonym of "cycles per second." I.E. In the above examples,
    the DDR bus has a 333 MHz data rate and the QDR bus has an 800MHz data
    rate; which happens to be the way they are typically rated.


    > Sort of as if the
    > ALUs all operated at 6.8GHz and the floating point units all operated at
    > 3.4GHz. Oh, dearie me ...

    The problem is you want everything to be a 'waveform' and that just isn't
    the case. And, btw, not every signal in a 3.4 GHz processor is jumping
    around at 3.4Ghz either: that's just the clock rate.

    >
    > [...]
    >
    > --
    > Michael Brown
    > www.emboss.co.nz : OOS/RSI software and more :)
    > Add michael@ to emboss.co.nz - My inbox is always open
    >
    >
  24. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Well, not really. How about FM modulation, as in FM broadcast radio? The
    original carrier frequency is measured in MHz, but then it is modulated by
    an audio frequency, measured in KHz, and the results is a varying frequency,
    giving a waveform which does not necessarily EVER repeat itself. And then
    there is phase modulation, pulse width modulation, not to mention
    polarization. And what about "spread spectrum", as used to be found as a
    BIOS settings, giving a modulated clock rate? Don't try to read too much
    into brief definition.

    As clock pulse trains, they carry no more data than a 60 Hz or 50 Hz power
    line.

    --
    Phil Weldon, pweldonatmindjumpdotcom
    For communication,
    replace "at" with the 'at sign'
    replace "mindjump" with "mindspring."
    replace "dot" with "."


    "BigBadger" <big_badger@NOSPAM.com> wrote in message
    news:c56p7j$j12$1@newsg3.svr.pol.co.uk...
    > >
    > Hertz is a measure of Mega Cycles per second...we both agree on that.
    > The dictionary 'physics' definition of a cycle is:
    > one complete oscillation: one complete continuous change in the magnitude
    of
    > an oscillating quantity or system that brings the system back to its
    > original energy state.
    > Therefore it does not matter how many data points is carried on the wave,
    > the frequency is the number of cycles (or oscillations) per second and for
    > an XP2800+ this is 166,600,000....or 166MHz
    >
    >
    >
  25. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Ziferten wrote:
    > kinda.... i was really after whether or not the 200(MHz? : )) bus was
    > safe for the processor

    It won't kill it. <g>. It may fail to post or boot Windows without a vcore
    increase.

    However, whether you'll get it to run stably at 200MHz FSB is another
    matter. It's multi-locked right? With an increase in core voltage and maybe
    better cooling it could be acheivable. It all depends on your CPU, they
    aren't all created equal.
    --
    ~misfit~

    > "David Maynard" <dNOTmayn@ev1.net> wrote in message
    > news:107e56l2817b35a@corp.supernews.com...
    >> Ziferten wrote:
    >>> Alright, so I didn't get an answer, but I learned way more about
    >>> Hertz!
    >>
    >> Hehe. Well, actually you did. What it "supports" is what it's rated
    >> at.
    >>
    >> I rather suspect you want to know what you can 'get out of it' and
    >> that was answered too.
    >>
    >>
    >>> "Ziferten" <ehaag_0@hotmail.com> wrote in message
    >>> news:rV3dc.23273$YC5.20163@twister.rdc-kc.rr.com...
    >>>
    >>>> What is the maximum that the Athlon XP 2800+ supports? I use a
    >>>> Gigabyte GA-7N400 Pro2 by the way
  26. Archived from groups: alt.comp.hardware.overclocking (More info?)

    You seem to have a misconception about how DDR/QDR busses operate, or
    possibly busses in general. A "bus" in the computer world (ie: the world in
    which DDR and QDR have a meaning) includes both the data lines, and the
    control/address lines (different than a bus in the electrical world, which
    is usually just a collection of similarly functioning lines). For example,
    the EV6 bus scheme of the 21264/K7 has 72 bidirectional data lines (64 bits
    data bits + 8 ECC bits), and 26 unidirectional control/address lines, plus
    several other miscellaneous lines. The data lines "operate" at 2<x> or 4<x>
    MHz, but the control and address lines only "operate" at <x> MHz. The "bus"
    includes both data AND control/address lines. EVERY request across the bus
    requires the use of the control lines, so they are no less important than
    the data lines.

    A request across the bus can only be started through the use of the control
    lines. You can't start sending the data, then send the address later. So if
    a request comes in at time 0.25 on a QDR bus, you have to wait until time
    1.0 before you can start the transmission, even if nothing was sent at time
    0.

    For example, sending 32 bytes across a <x> MHz 64-bit QDR bus goes as
    follows (simplified):
    time 0.00: Bus sits idle
    time 0.25: Bus sits idle, request is sendable but cannot be sent
    time 0.50: Bus sits idle, request is sendable but cannot be sent
    time 0.75: Bus sits idle, request is sendable but cannot be sent
    time 1.00: Request sent
    time 1.25: Request data continues
    time 1.50: Request data continues
    time 1.75: Request data continues
    time 2.00: Bus sits idle, ready for next request
    etc etc

    In a <x*4>MHz 64-bit SDR bus, it would look like:
    time 0.00: Bus sits idle
    time 0.25: Request sent
    time 0.50: Request data continues
    time 0.75: Request data continues
    time 1.00: Request data continues
    time 1.25: Bus sits idle, ready for next request
    etc etc

    On a <x> MHz 256-bit SDR bus:
    time 0.00: Bus sits idle
    time 1.00: Request sent (all 32 bytes in a single cycle)
    time 2.00: Bus sits idle, ready for next request

    Which brings me back to the original point that an <x> MHz <y> bit QDR bus
    is equavalent in performance to a <x> MHz <4*y> bit SDR bus, and slower than
    an <4*x> MHz <y> bit SDR bus.

    I know you dislike bringing memory into it, but the exact same thing applies
    to DDR memory. Requests can only be sent on integer cycles, but data can be
    sent on both integer and half-integer cycles. This is why DDR400 chips have
    a 5ns access time, not 2.5ns.

    David Maynard wrote:
    > Michael Brown wrote:
    >> David Maynard wrote:
    >>> Michael Brown wrote:
    >>>> David Maynard wrote:
    >>>>> BigBadger wrote:
    >>>>>> No it's not 333MHz, it's actually a 166 'MHz' FSB
    >>>>>> processor....333 is just AMD hype to sell the virtues of the DDR
    >>>>>> bus. Intel do the same trick but they multiply the real bus
    >>>>>> speed by 4x.
    >>>>>
    >>>>> Double and quad pumping the bus is not "hype." It's an engineering
    >>>>> technique for transferring data twice, or 4 times for quad, per
    >>>>> clock cycle.
    >>>>>
    >>>>> 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>>>> number from a performance standpoint.
    >>>>
    >>>> Oh dear, oh dear, here we go again ... :) It depends on whether you
    >>>> measure the control lines or the data lines for quoting the "bus
    >>>> speed" number.
    >>>
    >>> No it doesn't. It has to do with how many data transfer cycles there
    >>> are.
    >>
    >> This is exactly what I mean :) There are some lines on the bus that
    >> "operate" at <x> MHz, and some that "operate" at <4*x> MHz.
    >
    > It is irrelevant what "some lines" do. What's relevant is the data
    > rate.

    Why are the data lines more important than the signal lines when determining
    how many MHz the bus operates at? Without both, you don't have a bus, and
    there are arguments for adopting either of the two speeds.

    >> What, then, is the bus speed?
    >
    > The bus 'speed' is the data rate.

    <nitpick>
    Data rate is measured in bps, not MHz. Which is why I'm semi-comfortable
    with the DDR333/DDR400 terminology, but dislike people saying it's a 333MHz
    bus.
    </nitpick>

    What I *think* you mean is that the data signal characteristics are more
    important than the control signal characteristics. Again, there are
    arguments for both sides: the data signal characteristics are more important
    under streaming conditions (the norm for GPUs), control signal
    characteristics are more important under random access conditions (the norm
    for CPUs).

    [...]
    >>>> I actually think a more accurate way of representing it
    >>>> (performance-wise) is a 128-bit bus (DDR) or 256-bit bus (QDR),
    >>>> both running at 166MHz.
    >>>
    >>> Except it isn't '128 bits' or '256 bits' wide. It does, however,
    >>> transfer data at either 2, for dual pumped, or 4 times, for quad
    >>> pumped, the system clock rate.
    >>
    >> Hence why I explicitly said "performance-wise". The question I was
    >> answering was:
    >> Which closer represents the performance of a 64 bit <x> MHz QDR
    >> bus? (a) A 64-bit <4*x> MHz SDR bus
    >> (b) A 256-bit <x> MHz SDR bus
    >> The correct answer is (b).
    >
    > The correct answer is (a) because that is REALITY. (b) is a figment
    > of your imagination.

    Again, you miss the "performance-wise" part. See the bit at the top of the
    post for the reasoning behind this.

    [...]
    >>>> Say you have a 166MHz DDR system
    >>>> (aka DDR333), and a 100MHz QDR system (aka QDR400), and the CPU
    >>>> runs at 1GHz (6.0x for DDR, 10.0x for QDR). Excluding memory
    >>>> latencies, to fill a randomly-accessed 64-byte cache line would
    >>>> take: Waiting for bus strobe: 3.0 cycles (DDR system), 5.0 cycles
    >>>> (QDR system) Transferring data: 24 cycles (DDR), 20 cycles (QDR)
    >>>> Total: 27 cycles (DDR), 25 cycles (QDR)
    >>>>
    >>>> So DDR333 is, under random access conditions, only marginally
    >>>> slower than QDR400. The actual break-even point is 180MHz (actually
    >>>> slightly above due to memory latencies), but hopefully you get the
    >>>> idea. Of course, the QDR system will perform better under
    >>>> "streaming" type conditions, where the higher latency won't matter
    >>>> so much.
    >>>
    >>> No, you're analyzing the memory, not the processor bus.
    >>
    >> Errm, not at all. I specifically EXCLUDE any memory performance
    >> considerations from the analysis: see the third line of your quoted
    >> section.
    >
    > You claim to be excluding it but you embed it in your analysis
    > nonetheless.

    Please, tell me where in my analysis I bring memory performance into it
    (excluding the "slightly above" remark, of course). All of the numbers above
    are only influenced by the speed and signalling scheme of the bus in
    question. A few quotes below, I say that you can think of it as two
    processors exchanging a cache line. Another option is a write to an I/O
    port. This is even more dramatic, as these writes are not cached, and DDR333
    bus will annihilate a QDR400 bus: the DDR333 bus will do 166 million I/O's
    per second, whereas the QDR400 bus will only manage 100 million per second.

    > You also create artificial conditions in direct contrast to reality
    > by, for example, trying to limit the analysis to 'random access' on a
    > bus that is specifically designed for, optimized for, and RATED AT
    > it's synchronous stream transfer rate whether it be SDR, DDR, or QDR.

    Could you please provide a reference that states that the EV6 bus was
    "specifically designed for" streaming data transfers. I'm not holding my
    breath.

    And limiting the analysis to non-streaming applications is creating
    artifical conditions? Excluding applications such as media encoding/decoding
    and large matix computations, much of the traffic that flows across the bus
    is random-access for the purpose of analysis. To get into the streaming
    case, you need to be running a bus-bandwidth limited task. Believe it or
    not, just about everything except media encoding/decoding or large matrix
    operations are CPU limited, not bus limited (which is why you don't get a
    50% increase in performance moving from 133x15 to 200x10).

    Certainly, the P4 is designed and tweaked for streaming, but that doesn't
    mean that ALL DDR/QDR busses are designed/tweaked for that purpose. The main
    reason why DDR/QDR was implemented is that it's easier to use a <x> bit bus
    at <2*y> MHz, as opposed to running a <2*x> bit bus at <y> MHz due to signal
    skew problems. Sorta similar reasons as to why it's cheaper to use a USB2
    interface than a EPP interface.

    > Heck, the names you (properly) use explain it even as you're denying
    > it: SRD - Single DATA RATE, DDR - Double DATA RATE, QDR - Quad DATA
    > RATE.

    Please provide a quote where I say that the data lines are running at the
    same speeds as the control lines. They are most certainly typo's and I'd
    like to correct them. What I HAVE said is that the performance of a DDR bus
    running at 166MHz (control signal clock) is identical in performance to a
    SDR bus that is twice as wide running at 166MHz. It is NOT equavalent in
    performance to a SDR bus (running at the same bus width as the DDR bus)
    running at 333MHz.

    I use the names DDR333, QDR400, etc (note the lack of MHz) simply because
    these have become the "standard" names for the particular busses. I would
    NOT call a DDR333 a 333MHz DDR bus though. To me, this says that the bus
    runs at 333MHz, with the data lines running at double this (ie: 667MHz).
    Also, I wouldn't I call it a 333MHz bus or a 166MHz bus, as this fails to
    specify the scheme used. I *would* call it a 166MHz DDR bus.

    >> I'm solely analysing how long it would take to fill (or write out) a
    >> processor cache line over a DDR/QDR bus, which is pretty much all the
    >> processor bus is used for.
    >> The exact same argument applies to the
    >> point-to-point DDR busses in a K7 SMP system, if having memory in the
    >> picture makes things confusing for you.
    >
    > You can wag imaginative theories and pick artificial 'conditions' all
    > you want.

    So, analysing the typical use for a bus is an artificial condition?
    Riiiiggghhhttt ...

    > I'm telling you how it works.

    I know EXACTLY how the EV6 bus works, and know fairly well how the DDR
    memory bus and the AGTL+ busses work. I wrote, pretty much from scratch, a
    VHDL program to log transfers across a EV6 bus (and also played with, but
    never got very far with, a DDR memory bus logger). Granted, it probably
    wouldn't actually work correctly because of signal purity issues if it was
    actually hooked into a bus, and that it was designed from the 21264 specs,
    but I do know the theory behind it quite well. The EV6 isn't a great example
    of a DDR bus for several reasons, but it still operates in much the same
    manner as I described above.

    >>>> Incidentally, this issue is exasparated by the P4's 128-byte cache
    >>>> line, as opposed to the 64-byte cache line of the K7.
    >>>
    >>> Processor (L2) cache has nothing to do with bus speed.
    >>
    >> Hence my "incidentally" (spot the recurring theme here: I don't
    >> usually put in words for no reason). The processor cache line size
    >> (note: cache LINE size, not cache size or anything else) and bus
    >> performance characteristics are quite interlinked for the
    >> performance of a processor. The larger cache line size improves
    >> streaming performance and decreases random-access performance, which
    >> is exactly the same characteristics as a QDR bus. My point was that
    >> the P4 has been heavily tweaked towards streaming computations, as
    >> opposed to having fast random-access times.
    >
    > We aren't talking about the "performance of a processor." We're
    > talking about the bus data rate.

    <sigh>

    Will you PLEASE go and read back over what you quoted. It was simply a
    comment about how the cache line size and bus type are interlinked with
    respect to the performance of a processor. If you think it's off topic for
    the thread, then just snip it instead of trying to make a great big issue
    over it.

    >>> Btw, what don't you call a 3.4 Gig P4 a 200Mhz P4 because the 'real
    >>> clock' (sic) is 200 Mhz. That 3.4 Gig number is just 'hype'.
    >>
    >>
    >> Why don't you call it a 6.8GHz P4? :P
    >
    > Because the reality of it is that it's operating at 3.4 GHz.

    Not all of it ... the ALUs and some parts of the scheduler are operating at
    6.8GHz, and numerous other bits are operating at all sorts of different
    speeds..

    [snip further P4 stuff, as this is really getting off-topic for a discussion
    on busses]

    --
    Michael Brown
    www.emboss.co.nz : OOS/RSI software and more :)
    Add michael@ to emboss.co.nz - My inbox is always open
  27. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Michael Brown wrote:

    > You seem to have a misconception about how DDR/QDR busses operate, or
    > possibly busses in general.

    I understand how the busses operate just fine, but thanks anyway.

    > A "bus" in the computer world (ie: the world in
    > which DDR and QDR have a meaning) includes both the data lines, and the
    > control/address lines (different than a bus in the electrical world, which
    > is usually just a collection of similarly functioning lines). For example,
    > the EV6 bus scheme of the 21264/K7 has 72 bidirectional data lines (64 bits
    > data bits + 8 ECC bits), and 26 unidirectional control/address lines, plus
    > several other miscellaneous lines. The data lines "operate" at 2<x> or4<x>
    > MHz, but the control and address lines only "operate" at <x> MHz. The "bus"
    > includes both data AND control/address lines. EVERY request across the bus
    > requires the use of the control lines, so they are no less important than
    > the data lines.
    >
    > A request across the bus can only be started through the use of the control
    > lines. You can't start sending the data, then send the address later. So if
    > a request comes in at time 0.25 on a QDR bus, you have to wait until time
    > 1.0 before you can start the transmission, even if nothing was sent at time
    > 0.
    >
    > For example, sending 32 bytes across a <x> MHz 64-bit QDR bus goes as
    > follows (simplified):
    > time 0.00: Bus sits idle
    > time 0.25: Bus sits idle, request is sendable but cannot be sent
    > time 0.50: Bus sits idle, request is sendable but cannot be sent
    > time 0.75: Bus sits idle, request is sendable but cannot be sent
    > time 1.00: Request sent
    > time 1.25: Request data continues
    > time 1.50: Request data continues
    > time 1.75: Request data continues
    > time 2.00: Bus sits idle, ready for next request
    > etc etc
    >
    > In a <x*4>MHz 64-bit SDR bus, it would look like:
    > time 0.00: Bus sits idle
    > time 0.25: Request sent
    > time 0.50: Request data continues
    > time 0.75: Request data continues
    > time 1.00: Request data continues
    > time 1.25: Bus sits idle, ready for next request
    > etc etc
    >
    > On a <x> MHz 256-bit SDR bus:
    > time 0.00: Bus sits idle
    > time 1.00: Request sent (all 32 bytes in a single cycle)
    > time 2.00: Bus sits idle, ready for next request
    >
    > Which brings me back to the original point that an <x> MHz <y> bit QDR bus
    > is equavalent in performance to a <x> MHz <4*y> bit SDR bus, and slowerthan
    > an <4*x> MHz <y> bit SDR bus.

    The issue is not in comparing various bus speeds to each other, nor is it
    bus latency, nor is it inventing analogous models. The issue is the data
    rate and it's current designation in how many data transfers per second it
    is capable of.


    > I know you dislike bringing memory into it, but the exact same thing applies
    > to DDR memory. Requests can only be sent on integer cycles, but data can be
    > sent on both integer and half-integer cycles. This is why DDR400 chips have
    > a 5ns access time, not 2.5ns.

    Which is again irrelevant to the bus stream rate.

    You are so intent on playing with bit timings that you have completely lost
    track of what the issue was: Whether the 333MHz rating of a 166.6Mhz
    clocked DDR bus was "hype" (subtitled: it's 'really' [sic] a 166.6Mhz bus)
    and then, secondly, whether Mhz even applied to the number. And I've
    answered both: No, it is not just 'hype' and yes, MHz is perfectly appropriate.

    We can wax eloquent all day long about when request signals can, or cannot,
    be sent with a particular bus implementation, which would be fine if the
    topic were bus latency, but the fact of the matter is that the data is NOT
    streaming at 166.6 MHz; it is streaming at 333 Mhz, even if it has to wait
    till the cows come home to start doing it.

    Now, if you want to introduce "The Brown Formula" for how bus speeds should
    be designated, and get that accepted as a new standard, then have at it and
    best wishes. But, until then, it's useful for people to know what the
    333MHz means in this context since that's the one in common usage. And, to
    that end, it is referring to the bus data stream rate.


    > David Maynard wrote:
    >
    >>Michael Brown wrote:
    >>
    >>>David Maynard wrote:
    >>>
    >>>>Michael Brown wrote:
    >>>>
    >>>>>David Maynard wrote:
    >>>>>
    >>>>>>BigBadger wrote:
    >>>>>>
    >>>>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB
    >>>>>>>processor....333 is just AMD hype to sell the virtues of the DDR
    >>>>>>>bus. Intel do the same trick but they multiply the real bus
    >>>>>>>speed by 4x.
    >>>>>>
    >>>>>>Double and quad pumping the bus is not "hype." It's an engineering
    >>>>>>technique for transferring data twice, or 4 times for quad, per
    >>>>>>clock cycle.
    >>>>>>
    >>>>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >>>>>>number from a performance standpoint.
    >>>>>
    >>>>>Oh dear, oh dear, here we go again ... :) It depends on whether you
    >>>>>measure the control lines or the data lines for quoting the "bus
    >>>>>speed" number.
    >>>>
    >>>>No it doesn't. It has to do with how many data transfer cycles there
    >>>>are.
    >>>
    >>>This is exactly what I mean :) There are some lines on the bus that
    >>>"operate" at <x> MHz, and some that "operate" at <4*x> MHz.
    >>
    >>It is irrelevant what "some lines" do. What's relevant is the data
    >>rate.
    >
    >
    > Why are the data lines more important than the signal lines when determining
    > how many MHz the bus operates at? Without both, you don't have a bus, and
    > there are arguments for adopting either of the two speeds.

    Because the 'speed' designation we are discussing is the data rate and not
    how fast any of the bus lines go up and down.


    >>>What, then, is the bus speed?
    >>
    >>The bus 'speed' is the data rate.
    >
    >
    > <nitpick>
    > Data rate is measured in bps, not MHz. Which is why I'm semi-comfortable
    > with the DDR333/DDR400 terminology, but dislike people saying it's a 333MHz
    > bus.
    > </nitpick>

    bps is fine for a bit wide serial stream but it don't work worth spit fora
    bus.


    > What I *think* you mean is that the data signal characteristics are more
    > important than the control signal characteristics. Again, there are
    > arguments for both sides: the data signal characteristics are more important
    > under streaming conditions (the norm for GPUs), control signal
    > characteristics are more important under random access conditions (the norm
    > for CPUs).

    No, we are not talking about (electrical) 'signal characteristics'. The
    number is the data rate.

    And, btw, "random access" is not "the norm for CPUs" (and especially not on
    the cpu/memory bus that is typically stream filling cache.)


    > [...]
    >
    >>>>>I actually think a more accurate way of representing it
    >>>>>(performance-wise) is a 128-bit bus (DDR) or 256-bit bus (QDR),
    >>>>>both running at 166MHz.
    >>>>
    >>>>Except it isn't '128 bits' or '256 bits' wide. It does, however,
    >>>>transfer data at either 2, for dual pumped, or 4 times, for quad
    >>>>pumped, the system clock rate.
    >>>
    >>>Hence why I explicitly said "performance-wise". The question I was
    >>>answering was:
    >>> Which closer represents the performance of a 64 bit <x> MHz QDR
    >>> bus? (a) A 64-bit <4*x> MHz SDR bus
    >>> (b) A 256-bit <x> MHz SDR bus
    >>>The correct answer is (b).
    >>
    >>The correct answer is (a) because that is REALITY. (b) is a figment
    >>of your imagination.
    >
    >
    > Again, you miss the "performance-wise" part. See the bit at the top of the
    > post for the reasoning behind this.

    I didn't miss it at all. It's simply not relevant to the matter because the
    issue is not what the 'best' kind of bus would be or which is 'more
    efficient' or which would have lower latency. The issue is what the heck
    333MHz means in this context.

    With all due respect, it is you who have read more into my comment about it
    being a 'performance' number than was there. I simply meant that it has
    nothing to do with 'clocks' or any other type of 'circuit' description;
    That the number refers to the data rate in a (simple) 'performance'
    context, not that it encompasses every aspect of performance.


    > [...]
    >
    >>>>>Say you have a 166MHz DDR system
    >>>>>(aka DDR333), and a 100MHz QDR system (aka QDR400), and the CPU
    >>>>>runs at 1GHz (6.0x for DDR, 10.0x for QDR). Excluding memory
    >>>>>latencies, to fill a randomly-accessed 64-byte cache line would
    >>>>> take: Waiting for bus strobe: 3.0 cycles (DDR system), 5.0 cycles
    >>>>> (QDR system) Transferring data: 24 cycles (DDR), 20 cycles (QDR)
    >>>>> Total: 27 cycles (DDR), 25 cycles (QDR)
    >>>>>
    >>>>>So DDR333 is, under random access conditions, only marginally
    >>>>>slower than QDR400. The actual break-even point is 180MHz (actually
    >>>>>slightly above due to memory latencies), but hopefully you get the
    >>>>>idea. Of course, the QDR system will perform better under
    >>>>>"streaming" type conditions, where the higher latency won't matter
    >>>>>so much.
    >>>>
    >>>>No, you're analyzing the memory, not the processor bus.
    >>>
    >>>Errm, not at all. I specifically EXCLUDE any memory performance
    >>>considerations from the analysis: see the third line of your quoted
    >>>section.
    >>
    >>You claim to be excluding it but you embed it in your analysis
    >>nonetheless.
    >
    >
    > Please, tell me where in my analysis I bring memory performance into it
    > (excluding the "slightly above" remark, of course). All of the numbers above
    > are only influenced by the speed and signalling scheme of the bus in
    > question. A few quotes below, I say that you can think of it as two
    > processors exchanging a cache line. Another option is a write to an I/O
    > port. This is even more dramatic, as these writes are not cached, and DDR333
    > bus will annihilate a QDR400 bus: the DDR333 bus will do 166 million I/O's
    > per second, whereas the QDR400 bus will only manage 100 million per second.

    Whatever you want to claim here is fine with me and I should have ignored
    it the first time because it's irrelevant.


    >>You also create artificial conditions in direct contrast to reality
    >>by, for example, trying to limit the analysis to 'random access' on a
    >>bus that is specifically designed for, optimized for, and RATED AT
    >>it's synchronous stream transfer rate whether it be SDR, DDR, or QDR.
    >
    >
    > Could you please provide a reference that states that the EV6 bus was
    > "specifically designed for" streaming data transfers. I'm not holding my
    > breath.

    Fine. It's a synchronous bus where data streaming is an accident.

    http://www.ul.ie/~flanagan/ce4518/readings/AMD-Athlon.pdf

    "The Industry’s First 200-MHz System Bus for x86 Platforms

    The 200MHz AMD Athlon processor system bus—the fastest front-side bus
    implementation for x86 platforms—leverages the high-performance Alpha EV6
    system interface technology to significantly boost system performance and
    provide ample headroom for today’s and tomorrow’s applications...

    The flexible AMD Athlon processor system bus provides advanced features,
    such as... packet-based transfers for maximum transaction pipelining, large
    64-byte burst data transfers,...

    The 200MHz system bus implemented in the AMD Athlon processor is capable of
    delivering a peak data transfer rate of 1.6 Gbytes/sec—... AMD’s 200MHz
    system bus also provides 64-byte burst transfers,..."


    <snip>

    Not that the rest isn't interesting but it's irrelevant to the issue and
    now you're just arguing to be arguing.
  28. Archived from groups: alt.comp.hardware.overclocking (More info?)

    CPU bus != system bus

    "David Maynard" <dNOTmayn@ev1.net> wrote in message
    news:107a2lp7v48lta7@corp.supernews.com...
    > BigBadger wrote:
    >
    > > No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    just
    > > AMD hype to sell the virtues of the DDR bus. Intel do the same trick but
    > > they multiply the real bus speed by 4x.
    >
    > Double and quad pumping the bus is not "hype." It's an engineering
    > technique for transferring data twice, or 4 times for quad, per clock
    cycle.
    >
    > 333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant number
    > from a performance standpoint.
    >
    >
    > > The maximum that the processor will run at depends on many things. If
    it's
    > > un-locked you would be able to lower the multiplier and run it on a
    200MHz
    > > FSB, however if its one of the more recent locked models the maximum FSB
    > > would be in the region of 175-190MHz, depending on how overclockable the
    cpu
    > > is, how good your cooling is etc.
    > >
    >
    > He didn't ask what speed he might be able to push it to. He asked "What is
    > the maximum that the Athlon XP 2800+ supports?" and the "Maximum System
    Bus
    > Speed" that the processor "supports" is the bus speed it's rated for.
    >
  29. Archived from groups: alt.comp.hardware.overclocking (More info?)

    The basic issue is given a bus that has two different parts operating at two
    different frequencies, what is the "correct" number to use when referring to
    the bus as an "<x>MHz bus"? Like I've said numerous times, there's arguments
    for using either of the numbers; the number is undefined if you want to look
    at it mathematically. My personal view is that it should be called, for the
    DDR333 example, a "166MHz bus with a double data rate" or in a shorter form,
    "166MHz DDR bus", but not just a "166MHz bus" or a "333MHz bus" (which IMO
    implies SDR), nor a "333MHz DDR bus" (which IMO implies that the data lines
    operate at double the 333MHz speed). You obviously have a different view,
    and I don't think any amount of discussion is going to change that.

    That said, I don't think it's worth commenting on anything else apart from
    clarifying one point:
    David Maynard wrote:
    [...]
    > And, btw, "random access" is not "the norm for CPUs" (and especially
    > not on the cpu/memory bus that is typically stream filling cache.)

    In hindsight, the term "random access" was probably not well chosen. What I
    was referring to was the time between requests (each request being a 64-byte
    or 128-byte request to read/write a cache line) sent over the bus. In most
    applications (excluding the afore-mentioned streaming applications), the
    time between requests is largely random, and the bus is not used to
    capacity. If the bus is fully used, then the controller doesn't have to wait
    to send information over the address/control lines. However, if the bus is
    not fully utilised (as in the case in most current CPU/system designs), then
    the times of the requests can be treated as random, and this was the basis
    for the previous analysis.

    [...]
    > and now you're just arguing to be arguing.

    Funnily enough, I was coming to the same conclusion about you with your
    repeated ignoring of the "performance-wise" part ...

    --
    Michael Brown
    www.emboss.co.nz : OOS/RSI software and more :)
    Add michael@ to emboss.co.nz - My inbox is always open
  30. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Michael Brown wrote:

    > The basic issue is given a bus that has two different parts operating at two
    > different frequencies, what is the "correct" number to use when referring to
    > the bus as an "<x>MHz bus"? Like I've said numerous times, there's arguments
    > for using either of the numbers; the number is undefined if you want to look
    > at it mathematically.

    And as I have told you numerous times the number does not refer to any
    particular electrical 'part' of the bus so, no, the 'issue' is not what
    speeds various 'parts' of the bus operate at. It refers to the stream data
    rate, not 'this clock' or 'that clock' or whatever strobe signal someone
    may think is of particular interest (and very well might be in another
    context).


    > My personal view is that it should be called, for the
    > DDR333 example, a "166MHz bus with a double data rate" or in a shorter form,
    > "166MHz DDR bus", but not just a "166MHz bus" or a "333MHz bus" (which IMO
    > implies SDR), nor a "333MHz DDR bus" (which IMO implies that the data lines
    > operate at double the 333MHz speed). You obviously have a different view,
    > and I don't think any amount of discussion is going to change that.

    What things in the world would be called if you or I were linguistic
    dictators doesn't really matter much since we aren't.

    Where my 'different view' comes from is in simply acknowledging what the
    numbers in use already mean.

    But I could make the same 'complaints' in reverse as you make. That "166MHz
    DDR bus" is 'confusing' since it's data rate is 333. Explaining it's data
    rate comes from being DDR is nice information, assuming one is technically
    inclined, but it doesn't alter the fact that it streams at 333 so why not
    call a spade a spade? I.E. it's a 333MHz DDR bus: a bus which uses the
    technology of DDR, for the techies, to operate with a data stream rate of
    333Mhz. It's simply a matter of 'emphasis'. You think 'the clock' is 'god'
    (well, multiple gods with DDR and QDR, which causes some of the 'debate' of
    which 'god' to worship in the title) and my version of the 'complaint'
    focuses on the data stream rate as the item of interest.

    In my opinion, both complaints are 'picky', from a technical standpoint,
    and simply a personal 'feeling'. Both can be 'understood' if you simply
    accept the terminology and while one might 'prefer' their version that
    doesn't make the other 'wrong'. (E.g. "Hey Bill, when they say 333DDR have
    they already multiplied it out or does the reader have to do that themselves?")

    I think it should be rather clear, however, that when presenting the
    information to the typical buyer that the matter of which 'clock' is used,
    and even DDR, QDR and other such 'consumer obtuse' terms, is much less
    obvious than 333 being 'faster' than 200.


    > That said, I don't think it's worth commenting on anything else apart from
    > clarifying one point:
    > David Maynard wrote:
    > [...]
    >
    >>And, btw, "random access" is not "the norm for CPUs" (and especially
    >>not on the cpu/memory bus that is typically stream filling cache.)
    >
    >
    > In hindsight, the term "random access" was probably not well chosen. What I
    > was referring to was the time between requests (each request being a 64-byte
    > or 128-byte request to read/write a cache line) sent over the bus. In most
    > applications (excluding the afore-mentioned streaming applications), the
    > time between requests is largely random, and the bus is not used to
    > capacity. If the bus is fully used, then the controller doesn't have to wait
    > to send information over the address/control lines. However, if the bus is
    > not fully utilised (as in the case in most current CPU/system designs), then
    > the times of the requests can be treated as random, and this was the basis
    > for the previous analysis.

    OK.


    > [...]
    >
    >>and now you're just arguing to be arguing.
    >
    >
    > Funnily enough, I was coming to the same conclusion about you with your
    > repeated ignoring of the "performance-wise" part ...

    You took that from me and I explained what it meant. In particular, it was
    simply to distinguish from the 'technical' aspect. The data streaming
    number is an overall performance 'type' of number, not that it is expected
    to answer every aspect of the system's performance you might decide to take
    issue with. That's what spec sheets are for, not 'ratings'.

    E.g. Does PC100 memory send all of it's data within 10ns of the request?
    No, that's the maximum burst rate. Does a 166.6MHz SDR bus send all data
    without interruption or delay at 166.6MHz? No, that's the maximum burst
    rate. Is it even true that all 1 Gig processors are 'equally fast'? No. And
    so on.


    > --
    > Michael Brown
    > www.emboss.co.nz : OOS/RSI software and more :)
    > Add michael@ to emboss.co.nz - My inbox is always open
    >
    >
  31. Archived from groups: alt.comp.hardware.overclocking (More info?)

    NuT CrAcKeR wrote:
    > CPU bus != system bus

    I take it you think there's a salient point in there somewhere.

    > "David Maynard" <dNOTmayn@ev1.net> wrote in message
    > news:107a2lp7v48lta7@corp.supernews.com...
    >
    >>BigBadger wrote:
    >>
    >>
    >>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    >
    > just
    >
    >>>AMD hype to sell the virtues of the DDR bus. Intel do the same trick but
    >>>they multiply the real bus speed by 4x.
    >>
    >>Double and quad pumping the bus is not "hype." It's an engineering
    >>technique for transferring data twice, or 4 times for quad, per clock
    >
    > cycle.
    >
    >>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant number
    >>from a performance standpoint.
    >>
    >>
    >>
    >>>The maximum that the processor will run at depends on many things. If
    >
    > it's
    >
    >>>un-locked you would be able to lower the multiplier and run it on a
    >
    > 200MHz
    >
    >>>FSB, however if its one of the more recent locked models the maximum FSB
    >>>would be in the region of 175-190MHz, depending on how overclockable the
    >
    > cpu
    >
    >>>is, how good your cooling is etc.
    >>>
    >>
    >>He didn't ask what speed he might be able to push it to. He asked "What is
    >>the maximum that the Athlon XP 2800+ supports?" and the "Maximum System
    >
    > Bus
    >
    >>Speed" that the processor "supports" is the bus speed it's rated for.
    >>
    >
    >
    >
  32. Archived from groups: alt.comp.hardware.overclocking (More info?)

    I said the same thing as the post that I responded to, just in not so many
    words.

    NuTs

    "David Maynard" <dNOTmayn@ev1.net> wrote in message
    news:107jksrjpk8uf7a@corp.supernews.com...
    > NuT CrAcKeR wrote:
    > > CPU bus != system bus
    >
    > I take it you think there's a salient point in there somewhere.
    >
    > > "David Maynard" <dNOTmayn@ev1.net> wrote in message
    > > news:107a2lp7v48lta7@corp.supernews.com...
    > >
    > >>BigBadger wrote:
    > >>
    > >>
    > >>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    > >
    > > just
    > >
    > >>>AMD hype to sell the virtues of the DDR bus. Intel do the same trick
    but
    > >>>they multiply the real bus speed by 4x.
    > >>
    > >>Double and quad pumping the bus is not "hype." It's an engineering
    > >>technique for transferring data twice, or 4 times for quad, per clock
    > >
    > > cycle.
    > >
    > >>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant number
    > >>from a performance standpoint.
    > >>
    > >>
    > >>
    > >>>The maximum that the processor will run at depends on many things. If
    > >
    > > it's
    > >
    > >>>un-locked you would be able to lower the multiplier and run it on a
    > >
    > > 200MHz
    > >
    > >>>FSB, however if its one of the more recent locked models the maximum
    FSB
    > >>>would be in the region of 175-190MHz, depending on how overclockable
    the
    > >
    > > cpu
    > >
    > >>>is, how good your cooling is etc.
    > >>>
    > >>
    > >>He didn't ask what speed he might be able to push it to. He asked "What
    is
    > >>the maximum that the Athlon XP 2800+ supports?" and the "Maximum System
    > >
    > > Bus
    > >
    > >>Speed" that the processor "supports" is the bus speed it's rated for.
    > >>
    > >
    > >
    > >
    >
  33. Archived from groups: alt.comp.hardware.overclocking (More info?)

    NuT CrAcKeR wrote:

    > I said the same thing as the post that I responded to, just in not so many
    > words.

    I wrote the post you responded to and your reply doesn't even address the
    point, much less say the same thing.

    > NuTs
    >
    > "David Maynard" <dNOTmayn@ev1.net> wrote in message
    > news:107jksrjpk8uf7a@corp.supernews.com...
    >
    >>NuT CrAcKeR wrote:
    >>
    >>>CPU bus != system bus
    >>
    >>I take it you think there's a salient point in there somewhere.
    >>
    >>
    >>>"David Maynard" <dNOTmayn@ev1.net> wrote in message
    >>>news:107a2lp7v48lta7@corp.supernews.com...
    >>>
    >>>
    >>>>BigBadger wrote:
    >>>>
    >>>>
    >>>>
    >>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    >>>
    >>>just
    >>>
    >>>
    >>>>>AMD hype to sell the virtues of the DDR bus. Intel do the same trick
    >
    > but
    >
    >>>>>they multiply the real bus speed by 4x.
    >>>>
    >>>>Double and quad pumping the bus is not "hype." It's an engineering
    >>>>technique for transferring data twice, or 4 times for quad, per clock
    >>>
    >>>cycle.
    >>>
    >>>
    >>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant number
    >>>
    >>>>from a performance standpoint.
    >>>
    >>>>
    >>>>
    >>>>>The maximum that the processor will run at depends on many things. If
    >>>
    >>>it's
    >>>
    >>>
    >>>>>un-locked you would be able to lower the multiplier and run it on a
    >>>
    >>>200MHz
    >>>
    >>>
    >>>>>FSB, however if its one of the more recent locked models the maximum
    >
    > FSB
    >
    >>>>>would be in the region of 175-190MHz, depending on how overclockable
    >
    > the
    >
    >>>cpu
    >>>
    >>>
    >>>>>is, how good your cooling is etc.
    >>>>>
    >>>>
    >>>>He didn't ask what speed he might be able to push it to. He asked "What
    >
    > is
    >
    >>>>the maximum that the Athlon XP 2800+ supports?" and the "Maximum System
    >>>
    >>>Bus
    >>>
    >>>
    >>>>Speed" that the processor "supports" is the bus speed it's rated for.
    >>>>
    >>>
    >>>
    >>>
    >
    >
  34. Archived from groups: alt.comp.hardware.overclocking (More info?)

    cpu bus = 333

    fsb = 166

    333 != 166

    != means "not equal to"

    NuTs

    "David Maynard" <dNOTmayn@ev1.net> wrote in message
    news:107ovje137dbpc7@corp.supernews.com...
    > NuT CrAcKeR wrote:
    >
    > > I said the same thing as the post that I responded to, just in not so
    many
    > > words.
    >
    > I wrote the post you responded to and your reply doesn't even address the
    > point, much less say the same thing.
    >
    > > NuTs
    > >
    > > "David Maynard" <dNOTmayn@ev1.net> wrote in message
    > > news:107jksrjpk8uf7a@corp.supernews.com...
    > >
    > >>NuT CrAcKeR wrote:
    > >>
    > >>>CPU bus != system bus
    > >>
    > >>I take it you think there's a salient point in there somewhere.
    > >>
    > >>
    > >>>"David Maynard" <dNOTmayn@ev1.net> wrote in message
    > >>>news:107a2lp7v48lta7@corp.supernews.com...
    > >>>
    > >>>
    > >>>>BigBadger wrote:
    > >>>>
    > >>>>
    > >>>>
    > >>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    > >>>
    > >>>just
    > >>>
    > >>>
    > >>>>>AMD hype to sell the virtues of the DDR bus. Intel do the same trick
    > >
    > > but
    > >
    > >>>>>they multiply the real bus speed by 4x.
    > >>>>
    > >>>>Double and quad pumping the bus is not "hype." It's an engineering
    > >>>>technique for transferring data twice, or 4 times for quad, per clock
    > >>>
    > >>>cycle.
    > >>>
    > >>>
    > >>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    number
    > >>>
    > >>>>from a performance standpoint.
    > >>>
    > >>>>
    > >>>>
    > >>>>>The maximum that the processor will run at depends on many things. If
    > >>>
    > >>>it's
    > >>>
    > >>>
    > >>>>>un-locked you would be able to lower the multiplier and run it on a
    > >>>
    > >>>200MHz
    > >>>
    > >>>
    > >>>>>FSB, however if its one of the more recent locked models the maximum
    > >
    > > FSB
    > >
    > >>>>>would be in the region of 175-190MHz, depending on how overclockable
    > >
    > > the
    > >
    > >>>cpu
    > >>>
    > >>>
    > >>>>>is, how good your cooling is etc.
    > >>>>>
    > >>>>
    > >>>>He didn't ask what speed he might be able to push it to. He asked
    "What
    > >
    > > is
    > >
    > >>>>the maximum that the Athlon XP 2800+ supports?" and the "Maximum
    System
    > >>>
    > >>>Bus
    > >>>
    > >>>
    > >>>>Speed" that the processor "supports" is the bus speed it's rated for.
    > >>>>
    > >>>
    > >>>
    > >>>
    > >
    > >
    >
  35. Archived from groups: alt.comp.hardware.overclocking (More info?)

    NuT CrAcKeR wrote:

    > cpu bus = 333
    >
    > fsb = 166
    >
    > 333 != 166
    >
    > != means "not equal to"

    According to your 'logic', the two won't even work with each other.

    In reality, both ends operate the same way, I.E. are = (in that sense), so
    your equation makes no sense.


    > NuTs
    >
    > "David Maynard" <dNOTmayn@ev1.net> wrote in message
    > news:107ovje137dbpc7@corp.supernews.com...
    >
    >>NuT CrAcKeR wrote:
    >>
    >>
    >>>I said the same thing as the post that I responded to, just in not so
    >
    > many
    >
    >>>words.
    >>
    >>I wrote the post you responded to and your reply doesn't even address the
    >>point, much less say the same thing.
    >>
    >>
    >>>NuTs
    >>>
    >>>"David Maynard" <dNOTmayn@ev1.net> wrote in message
    >>>news:107jksrjpk8uf7a@corp.supernews.com...
    >>>
    >>>
    >>>>NuT CrAcKeR wrote:
    >>>>
    >>>>
    >>>>>CPU bus != system bus
    >>>>
    >>>>I take it you think there's a salient point in there somewhere.
    >>>>
    >>>>
    >>>>
    >>>>>"David Maynard" <dNOTmayn@ev1.net> wrote in message
    >>>>>news:107a2lp7v48lta7@corp.supernews.com...
    >>>>>
    >>>>>
    >>>>>
    >>>>>>BigBadger wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>No it's not 333MHz, it's actually a 166 'MHz' FSB processor....333 is
    >>>>>
    >>>>>just
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>AMD hype to sell the virtues of the DDR bus. Intel do the same trick
    >>>
    >>>but
    >>>
    >>>
    >>>>>>>they multiply the real bus speed by 4x.
    >>>>>>
    >>>>>>Double and quad pumping the bus is not "hype." It's an engineering
    >>>>>>technique for transferring data twice, or 4 times for quad, per clock
    >>>>>
    >>>>>cycle.
    >>>>>
    >>>>>
    >>>>>
    >>>>>>333 is the bus cycle rate, e.g. "Bus Speed," and is the relevant
    >
    > number
    >
    >>>>>>from a performance standpoint.
    >>>>>
    >>>>>
    >>>>>>
    >>>>>>>The maximum that the processor will run at depends on many things. If
    >>>>>
    >>>>>it's
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>un-locked you would be able to lower the multiplier and run it on a
    >>>>>
    >>>>>200MHz
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>FSB, however if its one of the more recent locked models the maximum
    >>>
    >>>FSB
    >>>
    >>>
    >>>>>>>would be in the region of 175-190MHz, depending on how overclockable
    >>>
    >>>the
    >>>
    >>>
    >>>>>cpu
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>is, how good your cooling is etc.
    >>>>>>>
    >>>>>>
    >>>>>>He didn't ask what speed he might be able to push it to. He asked
    >
    > "What
    >
    >>>is
    >>>
    >>>
    >>>>>>the maximum that the Athlon XP 2800+ supports?" and the "Maximum
    >
    > System
    >
    >>>>>Bus
    >>>>>
    >>>>>
    >>>>>
    >>>>>>Speed" that the processor "supports" is the bus speed it's rated for.
    >>>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>
    >
    >
  36. Archived from groups: alt.comp.hardware.overclocking (More info?)

    Get a live! Both og you!!
Ask a new question

Read More

Overclocking Hardware Bus Speed Windows XP