If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
kinda.... i was really after whether or not the 200(MHz? : )) bus was safe
for the processor "David Maynard" wrote in message ... 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" wrote in message ... What is the maximum that the Athlon XP 2800+ supports? I use a Gigabyte GA-7N400 Pro2 by the way |
#32
|
|||
|
|||
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 2x or 4x 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*4MHz 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 he 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 |
#33
|
|||
|
|||
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, wh= ich is usually just a collection of similarly functioning lines). For examp= le, 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, p= lus several other miscellaneous lines. The data lines "operate" at 2x or= 4x 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 th= an the data lines. =20 A request across the bus can only be started through the use of the con= trol lines. You can't start sending the data, then send the address later. S= o if a request comes in at time 0.25 on a QDR bus, you have to wait until ti= me 1.0 before you can start the transmission, even if nothing was sent at = time 0. =20 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 =20 In a x*4MHz 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 =20 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 =20 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. 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 i= t is capable of. I know you dislike bringing memory into it, but the exact same thing ap= plies to DDR memory. Requests can only be sent on integer cycles, but data ca= n 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 lo= st 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 approp= riate. We can wax eloquent all day long about when request signals can, or canno= t, 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 NO= T streaming at 166.6 MHz; it is streaming at 333 Mhz, even if it has to wai= t till the cows come home to start doing it. Now, if you want to introduce "The Brown Formula" for how bus speeds shou= ld be designated, and get that accepted as a new standard, then have at it a= nd 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, t= o that end, it is referring to the bus data stream rate. David Maynard wrote: =20 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. =20 =20 Why are the data lines more important than the signal lines when determ= ining how many MHz the bus operates at? Without both, you don't have a bus, a= nd there are arguments for adopting either of the two speeds. Because the 'speed' designation we are discussing is the data rate and no= t how fast any of the bus lines go up and down. What, then, is the bus speed? The bus 'speed' is the data rate. =20 =20 nitpick Data rate is measured in bps, not MHz. Which is why I'm semi-comfortabl= e with the DDR333/DDR400 terminology, but dislike people saying it's a 33= 3MHz bus. /nitpick bps is fine for a bit wide serial stream but it don't work worth spit for= a bus. What I *think* you mean is that the data signal characteristics are mor= e important than the control signal characteristics. Again, there are arguments for both sides: the data signal characteristics are more impo= rtant 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.) [...] =20 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. =20 =20 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 t= he 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. [...] =20 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. =20 =20 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 D= DR333 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 sec= ond. 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. =20 =20 Could you please provide a reference that states that the EV6 bus was "specifically designed for" streaming data transfers. I'm not holding m= y breath. Fine. It's a synchronous bus where data streaming is an accident. http://www.ul.ie/~flanagan/ce4518/re...AMD-Athlon.pdf "The Industry=92s First 200-MHz System Bus for x86 Platforms The 200MHz AMD Athlon processor system bus=97the fastest front-side bus implementation for x86 platforms=97leverages the high-performance Alpha E= V6 system interface technology to significantly boost system performance and= provide ample headroom for today=92s and tomorrow=92s applications... The flexible AMD Athlon processor system bus provides advanced features, such as... packet-based transfers for maximum transaction pipelining, lar= ge 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=97... AMD=92s 200M= Hz 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. |
#34
|
|||
|
|||
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 "xMHz 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 |
#35
|
|||
|
|||
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 "xMHz 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. FWIW I agree with you Michael. Not wanting to be argumentative at all about it though, just a POV. -- ~misfit~ |
#36
|
|||
|
|||
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 "xMHz 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 |
#37
|
|||
|
|||
CPU bus != system bus
"David Maynard" wrote in message ... 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. |
#38
|
|||
|
|||
NuT CrAcKeR wrote:
CPU bus != system bus I take it you think there's a salient point in there somewhere. "David Maynard" wrote in message ... 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. |
#39
|
|||
|
|||
I said the same thing as the post that I responded to, just in not so many
words. NuTs "David Maynard" wrote in message ... NuT CrAcKeR wrote: CPU bus != system bus I take it you think there's a salient point in there somewhere. "David Maynard" wrote in message ... 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. |
#40
|
|||
|
|||
cpu bus = 333
fsb = 166 333 != 166 != means "not equal to" NuTs "David Maynard" wrote in message ... 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" wrote in message ... NuT CrAcKeR wrote: CPU bus != system bus I take it you think there's a salient point in there somewhere. "David Maynard" wrote in message ... 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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
On the brink of madness... | I.C. Koets | General | 18 | January 31st 05 10:49 PM |
Updrade PC | Guy Smith | General | 22 | August 15th 04 01:57 AM |
CPU Over clocking | redrider | Overclocking | 17 | March 15th 04 11:01 AM |
Multi-boot Windows XP without special software | Timothy Daniels | General | 11 | December 12th 03 05:38 AM |
how much can i overclock my computer en how | MiniDisc_2k2 | Overclocking | 2 | July 6th 03 12:58 AM |