Good reasons to consider 64bit PCI slots on your next Motherboard purchase......

[Slipknot]

Before you guys light into my rear with the negatives of this approach, take a look at the article. I know you really only find 64bit slots on Dual motherboards, but I made this thread to provoke thought not to debate how to get the slots. Either way, take a look and enjoy, I was suprised by the amount 64bit PCI slots improved performance.


http://www.hardwaretech.info/guides/64_bit_workstation.php

[otheos]

UNBELIEVABLE!!!

These people have ABSOLUTELY NO IDEA what they're talking about. Other than the short copy/paste IDE/SCSI comparison, their test are as confused as they are.

First and most importantly (and they admit it themselves). What is Sandra doing in a review of storage subsystems? It's useless, confussing and definitely not objective.

Second, they know nothing about 64/66 and 32/33 PCI busses. They plug a 33Mhz card on a 64/66 slot having no idea of the consequences of that. The whole bus will run at 33Mhz! Period. And they talk about "overclocking" the card at 66Mhz??? And not only that, the North/Southbridge link will run at 33Mhz too! All their test show numbers that are different within 10%, I doubt they rerun to verify a real difference or a random error in them!

Their "why is it faster on 66Mhz bus" theory is outrageous. They take a card that nealry saturates the 32/33 bus at full STR, and use it on a buss with 2x the bandwidth and they get better results and they wonder??? The card has a whole 266MB/s to burst (it's a 32/66 card) freely (and Sandra uses burst speed as a performance weighting and this is why it's misleading) and they think it's the way it "talks to the CPU"??

Even their ATTO benchmarks are wrong. How on earth can a pair of Deskstars give 100MB/s writes when each drive cannot do more than 36MB/s anyway. The SCSI ATTO benchmark is so wrong as it' is obvious that it uses the cache (4MB chunks are known to give wrong results in ATTO). 140MB/s out or two 55MB/s capable drives?????

They are so confused and ignorant, they can't tell bursting from STR and completely ommit the importance of access times.

Don't even bother to read it, you'll go away knowing less, and definitely confused.

UNBELIEVABLE!!

EDIT: oh. and 64bit has nothing to do here, all the cards they use are 32bit.

[jmichna]

Bravo, Otheos!!!!

[Slipknot]

Well said otheos. I should have been more specific in what parts of the article I was refering to. I was only interested in the 2 charts below on the first page and the explanation on the second page. The rest of the article is very confusing and useless as Otheos pointed out.

A couple things are funny though. Just from the practice of OCing your FSB, everyone knows that you can't get a normal 33MHz PCI card to run much faster then 41Mhz. Maybe they didn't look at the data sheet of the product to well, because the card isn't overclocked at all. It runs at a TRUE 66Mhz by design. I wonder how they missed that when it is one of the biggest selling points of the card.

I was still quiet impressed with the ***benchmarks*** they obtained. Of course, I would love to see some real world test, because as everyone knows, normal users don't get too much if an gain from using Raid 0. Either way, thanks again for giving a reason for the performance gain otheos.

Card at 33Mhz
http://www.hardwaretech.info/guides/images/2_filesystem_1.gif

Card at 66Mhz
http://www.hardwaretech.info/guides/images/2_filesystem_2.gif

[Jim Tripp]

It's me, the hopelessly confused and ignorant author! :t

I deserve most of the blistering attack on my knowledge; I am ignorant, but I am also intelligent so visiting forums where my article is being criticized is how I am trying to improve. I also deserve a world-class ***-chewing for not having someone who knows more than me review my article, especially the theory about why the 32/66 card showed higher SiSoft numbers when moved from a 33MHz slot to a 66MHz slot.

Still, I will respond to some of the points in the hope of shedding some light and maybe getting some from you folks.

1. SiSoft.

The SiSoft thing was a carry over from the previous week's article: as a fun project we tried to hit 50,000 on it when building a "dream system" for a buddy. We didn't quite make it to 50,000 and we got our asses blistered all over the 'net for using SiSoft. We now know about ATTO, which is a glorified SiSoft, and we know about IOmeter, which is the real deal. Of course access times and I/Os per second are hugely important. We are not yet equipped or trained to run IOmeter tests, but ATTO was easy and free. A SCSI proponent who blistered our asses let us use his ATTO benchmarks. We ran the defaults just like the guy who gave us his benchmarks and did our best to interpret from there. Along the way we said goodbye to SiSoft with a salute to our 50,000 number.

2. 66/64 and 33/32 Ignorance.

It was true that we plugged the RAID card into the 66/64 slot a couple of weeks ago because a vague statement in the user's guide said that the card was "compatible with 66MHz" and was capable of "doubling throughput" from 133MB/s to 266MB/s when used in 66/64 bit slots. Since we were sustaining only 35MB/s in the 32/33 slot, and our drives were only capable of bursting at 100MB/s, I predicted no advantage to moving to 66/64. I was wrong. We got nearly 50MB/s. When we did, I was convinced that the reason was faster communication between the software RAID card and the CPU. If I may impose upon otheos or someone else as knowledgeable, I still don't understand the explanation that otheos gave: he says that the 33/66 RAID card can burst at 266 instead of 133 when running in the 64 slot, but if the drives are limited to 100 how does this help you? If you can make it so that I can understand it, I would like to print it as a correction on our site.

3. "Overclocking" a network card.

I realize that "overclocking" is the wrong word and I should have used it in quotes. What I meant is simply that the network card runs consistently faster in the 64 slot instead of 32. Yes, the difference is less than 10%, 7.6% to be exact, but the speculation that we never retested or considered random error is wrong. We ran dozens of tests in the 32 slot and got 9484 every single time. We ran dozens of tests in the 64 slot and got 10660 every time. This time we were not surprised because 9484MB/s gives 75872Mb/s. Knowing that we were on 100000Mb/s Ethernet, we saw some room if the card could run at 66. It apparently can run at 66 so it gets you closer to the 100000Mb/s limit, but there is some other kind of overhead there. Again, if someone can correct or amplify I would appreciate it.

4. Only an idiot would use 4MB chunks for ATTO.

Someone else enlightened me about this today. The explanation is nothing more than 4MB is the default and 4MB was what our SCSI proponent used in his benchmarks. Who were we to question his wisdom? We were ignorant idiots, it is true.

5. Don't bother to read it, you will go away knowing less and definitely confused.

Here I must differ. Do bother to read it; if you are more knowledgeable than me you can laugh at the parts where I show my ignorance and you might pick up something useful like the fact that 64 bit slots are good for something. That was my main point. Many people don't know that they can use 64 bit slots today which I think is why this thread was started here.

Also, pages 5 and 6 are pretty funny.

Thanks very much. Best wishes to all at this forum.

Jim Tripp

[Slipknot]

Nice to meet you Jim. Hats off for joining our discusion. It's great to see you take the time to come over to someone elses forum and give your 2 cents why you did certain things. Good luck with your future articles.

[Jim Tripp]

Thank you most kindly. Uncritical sites (overclockers and gamers) have responded positively to my two articles and have not seriously challenged anything I've said. This site and Storage Review were very critical. The Storage Review moderator pretty much told me to go away and not come back until I had read all their forum threads, so I did not ask for clarification of his criticisms, I just apologized for wasting his time. Can anyone help me with these criticisms from Frank Russo at Storage Review? I think they are different from the others raised earlier. In the meantime, I will dig through the Storage Review forum as Mr. Russo suggested.

1: The TX 2000 is 32x66, which lowers your SBridge to NBridge TR's to 266MB/sec. This lowers overall system performance. You sacrafice 1/2 the system throughput for a better RAID score.

2: Placing the 32x33 nic into the 64/66 slot drops the SB to NB throughput to 133MB/sec. This will result in a 75% decrease in throughput.

He spelled sacrifice wrong, not me.

He also said that I should use 32MB for ATTO because 4MB fits in cache, and that in his personal opinion my last two pages were not funny. We've touched on these two points. My theory is that he just couldn't see the humor because all he could think about while he was reading it was how stupid I am. If you spent enough time in Catholic school or a fundamentalist church so that you know how to spell sacrifice, I'll guran-****-tee you it's funny.

Thanks all,
Jim Tripp

[otheos]

Thanks for dropping by, I must say you made feel bad for beeing so harsh on you. I wanted to come to your forums and chat with you but you see especially when it comes to storage, for some weird reason most sites mess things up good in reviews.

I mean people can't read access times off hdtach and tell the difference between access times and seek times, and when you tell them and ask them to correct a public site, they just get defensive. So I stopped bothering.

But since you came here and you're really interesting, I'll be glad to discuss it with you.

First let me see if I can explain why the TX2 gives higher benchmarks on the 66Mhz bus, and then we'll come the the NIC.

The TX2 is a 32/66Mhz card, that means it can use up to 266MB/s of bandwidth. Now you have two ATA100 drives one on each cable, and each has 100MB/s available to it from the controller. When the drives burst, they can use up to 80-90MB/s of that 100MB/s and if you add it up (these are two busses remember) you get 160MB/s. Now on a 32/33 bus, there is no room for 160MB/s, even if the TX2 was the only pci devices on the bus. On the 32/66 (actually 64/66) pci bus of the MPX you have 533MB/s. These are also used for the southbridge-northbridge connection. With the southbridge connection carrying the 32/33 bus, 133MB/s out of these 533MB/s can be used for that. So effectively you have at least 400MB/s for the 64/66 bus, and thus the 266MB/s the TX2 asks for are all there to be used, and hence the 160MB/s the drives are bursting at, are available.

So the TX2 breaths fine on the 32/66 bus, and with sandra taking so much notice of burst speed, scores go up.

Now the NIC has a serious disadvantage, it's NOT 66Mhz compatible, and this means, that if you plug it on the 64/66 slots you force the whole bus to run at 33Mhz (64 bit are not affected, but this card is not supporting that either). So from 533MB/s on the 64/66 you've gone down to 266MB/s. Still you need 133MB/s from the southbridge, so you're left with at least 133MB/s free for the card to breath. Now, this means that the card has a full 133MB/s available for itself to burst its 3-6kb cache, and hence you get the higher benchmarks. On the 32/33 it has to share the 133MB/s with other devices (usb, audio, IDE, rtc, input devices, isa bus etc) As for repeating the test and getting identical numbers, Sandra's NIC benchmarks are known to give the same number again and again and I seriously doubt it's the high level of consistensy (down to the last byte/sec), but can't really tell why it does it. I can tell though that I don't trust it.

Oh and some corrections:

1: The TX 2000 is 32x66, which lowers your SBridge to NBridge TR's to 266MB/sec. This lowers overall system performance. You sacrafice 1/2 the system throughput for a better RAID score.

No, the 64/66 bus is not affected. It's the clock speed that counts (66Mhz). It can't switch speed, so if a card runs at 33Mhz, the whole bus will stick to 33MHz. The data width is not affected, a 32bit card will only use 32bits out of the 64 available. So the TX2 does NOT affect the 64/66 bus speed.

2: Placing the 32x33 nic into the 64/66 slot drops the SB to NB throughput to 133MB/sec. This will result in a 75% decrease in throughput.

Having said the above, it's the 32/33 card that drops the bus to 266MB/s. There is no way to limit the 64/66 bus to 133MB/s.

Now, I'm glad you did your reading at storagereview, as they are knowledgable enough to understand that objective testing of storage systems is trully very very hard. As for ATTO, it's really nice, but it has the tendency to pick caches, and you might end with faulse results like you have. And if it's not the drives buffer, it can be the OS cache (in which case I could argue that a 10 year old Conner bobcat bursts the sam as a Fujitsu MAM). So it's tricky again.

You should start with a raw performance measurement, so tha you know what the subsystem is capable off beyond the OS. Try hdtach, it has it's issues but it can give you a first picture. Don't think of it as a benchmark, more like wcpuid for strorage. This way you'll know what the system can physically achieve and you will be able to spot the problem of 100MB/s writes of a RAID0 with two deskstars immediately.

While it won't give you rates with different data sizes (which is very important), it will give you an accurate measurement of thte drives access times. And access times are extremely important in drive performance, to the level that the IDE RAID0 vs SCSI argument is brought to it's knees and is thrown out the window. However this is not a reason to bash RAID0, if you consider the purpose of RAID0's existence.

RAID0 is designed for two reasons: High sustainable rates, and large storage. These are necesitated by various uses. Capturing uncompressed avi real time for instance where you need ~60MB/s minimum (throughout the platters) and huge capacities. Access times is not important, as the drives write sequentially (the way ATTO and hdtach work). Now this is a common mistake:

You see an hdtach plot and you notice that at the 11GB position of the platter (cylinder) the drive is say capable of 25MB/s reads, while at the 36thGB is only capable of 19MB/s. People don't realise that these figures are only valid if the drive is reading sequentially. A random read will be much much lower, and is subject to data size requested (see ATTO's importance), cache size, OS cacheing etc. Now sequential operation is not very common in a home users pc, because his data is typically small files. On top of that there is fragmentation. Take a RAID0 and use it for that and you have absolutely no benefit. Putting the OS on a RAID0 is typical of "enthusisasts" that buy overpriced hardware to make it fast with RAID0, whithout realising what it's all about. True, game files 200-300MBs in size will load faster and you can see a speed imporovement there.

However, RAID0, designed as such, takes no consideration in access times. After all there's nothing that can be done for the "slow" IDE drives' access times. But RAID0 has overhead, and latency. Even a true hardware controller adds latency. Ideally for max STR you'd need the smallest block size for the array so that you get maximum stripping. However you notice that bellow a point performance goes down, and this is definitely latency related (controller and mechanical inertia). This latency may be tuned out of the STR and reach a nice almost 2x STR out of the array, however it adds up in the access times. And if you have access related performance needs (such as running an operating system has), RAID0 comes very very disappointing. No wonder, it was not designed for this. You try increase the block size for better access times and multitasking, but STR goes down.

And since I mentioned multitasting, RAID0 is not really able to multitast for the same reason singel a large hard drive is slower that two smaller ones when accessed by more than one users, or used to fetch data by many points at once. Take this for example to stick in a single user environment. OS and Program files on a single drive (or RAID0, same principles). The drive has to move the heads back and forth to read the Programs executable and it's libraries and at the same time the OS's libraries or other files. Now put the Program files on a second (different channel) disk. One disk reads the program's files the other the OS's. Get my point?

So, taking all practical considerations out (cheap winRAID controllers, hard drive failure rates etc) RAID0 cannot be compared with a SCSI subsystem as they are completly different. Chosing between the two for your home box though, as most people do, is confusing and you might end up with the wrong choice, lured by the low cost, a lot of hype (and marketing from motherboard manufacturers) and availability (most new mobos have onboard "raid").

And this comes without even touching the i/os per sec and SCSI/IDE intrinsic differences some of which you mentioned in your review. Or the drive's differences in terms of electronics, media and mechanics.

[Peter M]

Let's get a few things sorted, folks.

32-bit cards in 64-bit slots do not kick the other devices back to 32-bit. 64-bit transfer width is negotiated for every single transaction.

33-MHz cards in 66-MHz slots DO kick the other devices back to 33 MHz. PCI clock must be the same for all devices on the same bus.

AMD's 768 south bridge is a 66-MHz 32-bit device.

Even at 33 MHz, the same card in a primary (64-bit) bus slot will be somewhat faster than on the secondary (32-bit) bus simply because data moving to and fro the 32-bit bus have to hop a PCI bridge (embedded in AMD 768), which introduces some latency. Yet still, plugging a 33-MHz card into a primary bus slot is to be avoided because this halves the potential bandwidth of this bus - harming the south bridge and all other 66-MHz devices.

There's two reasons why 64-bit/66-MHz PCI systems should have a second, slow PCI bus - firstly, 66-MHz PCI doesn't allow more than two slots electrically, secondly, users need a place to stick their old cards in without harming the performance of their high throughput stuff.

regards, Peter

[Ankerson]

Correct, that is the reason most server boards (Xeon) have both 32 and 64 bit PCI slots, and some have an AGP slot.

Supermicro boards are real nice.:) (Xeon CPU's)

[Jim Tripp]

It will take me some time to read and absorb these responses, but I wanted to immediately thank otheos for his extended post. This is extremely valuable information and a tremendous courtesy for which I am very grateful. When I get to the point that I can print a retraction and clarification, I will ask permission to use this information and give full and complete credit to everyone who helped me.

Thank you once again! :cool:

[Peter M]

Ankerson, I'd like to push your favorite button by telling you that Supermicro is an ECS Elitegroup subsidiary.

Really. Not kidding.

Intel's server chipsets have a slightly different arrangement of busses. They use a proprietary bus for the connection of the north and south bridge plus one or two additional PCI-64 hubs. This gets you the same number of bridge hops for 32-bit PCI as on AMD 762MPX, but one bridge hop more than on the AMD for 64-bit PCI. The AGP bus is directly from the north bridge on either.

regards, Peter

[Ankerson]

Peter Missel,

I didn't know that.:)

You learn something new every day.:D

[getafix]

Originally posted by otheos

...stuff deleted.

However, RAID0, designed as such, takes no consideration in access times. After all there's nothing that can be done for the "slow" IDE drives' access times. But RAID0 has overhead, and latency. Even a true hardware controller adds latency. Ideally for max STR you'd need the smallest block size for the array so that you get maximum stripping. However you notice that bellow a point performance goes down, and this is definitely latency related (controller and mechanical inertia). This latency may be tuned out of the STR and reach a nice almost 2x STR out of the array, however it adds up in the access times. And if you have access related performance needs (such as running an operating system has), RAID0 comes very very disappointing. No wonder, it was not designed for this. You try increase the block size for better access times and multitasking, but STR goes down.

And since I mentioned multitasting, RAID0 is not really able to multitast for the same reason singel a large hard drive is slower that two smaller ones when accessed by more than one users, or used to fetch data by many points at once. Take this for example to stick in a single user environment. OS and Program files on a single drive (or RAID0, same principles). The drive has to move the heads back and forth to read the Programs executable and it's libraries and at the same time the OS's libraries or other files. Now put the Program files on a second (different channel) disk. One disk reads the program's files the other the OS's. Get my point?

So, taking all practical considerations out (cheap winRAID controllers, hard drive failure rates etc) RAID0 cannot be compared with a SCSI subsystem as they are completly different. Chosing between the two for your home box though, as most people do, is confusing and you might end up with the wrong choice, lured by the low cost, a lot of hype (and marketing from motherboard manufacturers) and availability (most new mobos have onboard "raid").

And this comes without even touching the i/os per sec and SCSI/IDE intrinsic differences some of which you mentioned in your review. Or the drive's differences in terms of electronics, media and mechanics.

Can I ask you for your comments on some analysis I put together on the above agrument? I put the analysis together based on a comprehensive review that Storage Review did on IDE RAID controllers.

The analysis can be seen here http://forums.storagereview.net/viewtopic.php?t=3645

Thanks!

[Jim Tripp]

Otheos, I completely understand your explanation of the RAID card: two 100MB/s RAID drives want to burst at 200MB/s if they can. In a 32/33 slot they can't (133MB/s limit) while running at 32/66 they can (233MB/s limit).

Peter, I like your explanation of the NIC card increase: a little less latency because the primary PCI runs straight off the NB/SB interconnect while the secondardy PCI runs off the SB. I looked at a diagram of the 762/768 chipset and it all made sense.

I also completely understand why you all disagree with the two points Mr. Russo made: he appeared to be thinking, "since the primary PCI is connected directly to the NB/SB interconnect, cards in the primary PCI will limit the data width and speed of the interconnect." It's the only way to explain why he would say that a 32/66 card in a 64/32/66 slot will drop the interconnect from 533MB/s to 266MB/s (half) while a 32/33 in the same slot will drop it from 533MB/s all the way back to 133MB/s (one quarter). I've made a posting to him and we'll see what he has to say.

At the same time, I've absorbed all the points Otheos made about RAID being something of a two-edged sword and why access time probably outweighs all other factors in normal individual PC use. Thank you once again for spending all that time on me. Believe me, I spent hours on it and will spend more on related material. I'll also use some of the other tools for measuring hard drive performance and increase my experience as well as my knowledge. Also, I'll read what getafix had to say. I haven't gotten there yet.

Thanks all, again.

[Peter M]

Jim, the AMD768 SB is a 32-bit 66 MHz device. Thus the NB-SB interconnect is no faster than 266 MB/s anyway! Note that this does not keep cards on the primary bus from being 64/66.

As I said already, the only thing you should not be doing is plug a 33 MHz card into a 66-MHz-capable slot.

regards, Peter

[Jim Tripp]

Peter,

I trust what you say that the Southbridge is 32x66 and so it cannot demand more than 266MB/s from the interconnect, but this diagram (http://www.lostcircuits.com/motherboard/amd_mpx/2.shtml) of the 762/768 chipset (the lower one on the page, not the upper one) clearly shows that the interconnect is 64x66 for a bandwidth of 533MB/s. Since the primary PCI runs off the interconnect and the Southbridge does too, that tells me that when the Southbridge is saturated and pulling 266MB/s via 32x66 calls to the Northbridge over the interconnect, there is still 266 left over on the interconnect for the primary PCI to use. Am I wrong?

Jim

[Peter M]

Wrong. Think about it. The primary PCI bus is 64/66, but the 768 is 32/66. When a 32/66 device pumps its maximum 266 MB/s, then it uses up all the available bus time. Nothing left for others.

[Jim Tripp]

OK, I got it: there are only 66 clock cycles per second and if the Southbridge is calling for a 32 bit transfer on each clock cycle, there are no clock cycles left for anything else. Looking at the diagram I mentioned above, I was stupid enough to wonder if the Northbridge was smart enough to take a 32 bit request from the 64/32/66 ("wide") PCI bus and a 32 bit request from the Southbridge and service both of them on the same clock cycle. Your answer is no, and it makes sense to me.

So how do the devices on the "wide" PCI bus and the devices on the 32/66 Southbridge compete for bandwidth on the same interconnect, labelled as 64/66 (533MB/s) on the diagram I referenced above? If the "wide" PCI bus is running at 33MHz because a lunkhead like me puts a 33MHz nic card in there, does the interconnect slow down to 33MHz and feed both the "wide" PCI bus and the Southbridge at 33MHz? This would reduce the Southbridge to a 32/33 device, which is what I hear Mr. Russo saying: he said my nic card chopped the throughput back to 133MB/s (32/33). I know you disagree with his math that this is a 25% reduction because you say that the Southbridge can only take data at 266MB/s. So worst case it cuts back 50%, not 25%. But I also hear you saying that the Southbridge is 32/66, period. Does that mean that you are saying the interconnect to the Southbridge never drops back to 32/33, even if there is a 33MHz nic card in one of the "wide" PCI slots? In other words, do you say a 33MHz nic card in the wide PCI bus will cut the interconnect to the Southbridge by 0% or by 50%? I only know that you disagree with 25%.

I realize I am taking up your time and perhaps trying your patience. Thanks in advance. This is getting interesting.

[jad1097]

Jim Tripp, welcome to sysopt. It’s not often someone like you come around. I have to admire your honesty and willingness to learn.

[Peter M]

Jim, you need to sit down and get your brain sorted :)

The SB is a 32/66 capable device, but if you put it on a 33 MHz bus, it'll do 32/33 of course.

PCI works like this: A device arbitrates for the bus, wins it, announces 64-bit or 32-bit transfers, and then keeps bus ownership until the transfer completes. While owning the bus, 64-bit devices pump twice as much data as 32-bit ones do.

regards, Peter

[Jim Tripp]

Sorry to drop out for three days, but I am moving from DC to Pittsburgh and had not a moment to spare.

Peter, I think you only read my first paragraph and you addressed that well. I'm 100% educated on PCI with respect to negotiating for control and width of transaction. But what about speed?

That is the question I ask in paragraph two: what controls the Northbridge to Southbridge interconnect speed?

a. It runs at 66MHz all the time, regardless of the devices installed; the Southbridge clocks back to 33 when talking to 33MHz devices attached to it.
b. It decides at boot-up whether it will run at 66 or 33 throughout that session, depending on the speed of the devices in the 64/32/66 slots during bootup.
c. Speed over the interconnect is negotiated for each transaction, just like 32-bit or 64-bit width. (It's hard for me to believe this one).
d. It is decided some other way I can't imagine yet.

Thanks.

Jim

P.S. Thanks for the warm welcome, jad.

[Peter M]

The clock for a 66 MHz capable PCI bus is determined during power-on reset sequence. There is a 66-MHz-detect line on all the PCI connectors, which would be driven Negated by any 33-MHz-only device inserted in such a slot. The clock PLL in the chip where this PCI bus originates (the AMD 762 north bridge in this case) then locks to the appropriate frequency and stays that way.

That's the point - transfer width is negotiable from single byte to 64-bit on every single transfer, but the clock cannot be altered once started.

regards, Peter

[Jim Tripp]

Peter, a million thanks; that makes perfect sense. The fact that each PCI connect has "66 MHz detect" seals the deal. The Northbridge is going to fall back to 33MHz during power up the minute it sees a 33MHz device anywhere on the 64/32/66 bus.

May I use your name in a follow-up to my article, or would you prefer anonymity? Another option is to refer me to some industry-standard article that will confirm everything you said. I will be looking for one anyway just to have a reference and to avoid bugging you any more with ignorant questions. Thanks.

Jim

P.S. I can look it up, but what does PLL stand for?

[Jim Tripp]

Peter, there is only one clock in the Northbridge, right? If it talks to the 64 bit PCI bus at 33MHz because there is a 33MHz card in one of the 64 bit slots, it also talks to the Southbridge at 33MHz?

[Jim Tripp]

Peter,

Everything you said is completely backed up in the AMD technical documentation I found at AMD.com. Everything.

Also, it answered all my other questions.

The AMD-762 system controller requires the following clocks...AGPCLK, 66MHz, [is] used for clocking the AGP and PCI internal logic. This feeds the PCI 66MHz PLL in 66/33 PCI mode...The AMD-762 system controller provides the three 66-MHz clocks required for the Southbridge and the two PCI bus slots in [66/33] mode. If a 33-MHz-only card is inserted in one of the 66-MHz PCI slots, then the M66EN (66MHz enable) signal is deasserted, which causes the AMD-762 system controller to drive 33MHz on the [three 66-MHz clocks just referred to].

I also found out that PLL stands for "phase-locked loop" and means that it has an oscillator that is constantly adjusted to match the phase of an incoming signal. As it says above, the 66Mhz AGPCLK feeds the PCI 66MHz PLL, providing a reference signal.

Thanks for your patience. I had tried to read the AMD technical documentation before talking to you, but could not make great sense of it. Now it makes much more sense, and it confirms everything that you said. I will reference it in my article since it carries "ultimate authority" from AMD, but I will acknowledge your help.

Jim

[Peter M]

You're welcome ... and of course you're welcome to put my name in your sequel article, why not. Just make sure you keep the facts straight, I have a name to lose here :)

regards, Peter

[Jim Tripp]

Peter, please check your private messages regarding this thread. Thanks.

Jim

[otheos]

Very nice article!

[Jim Tripp]

Thanks for the thumbs up, Otheos! The article is in final stages of editing and has not been officially released. Otheos and Peter Missel were kind enough to give me a review before the official release to help ensure that I don't embarrass myself again. We are making a couple of edits at Peter's request, but they aren't substantive.

Thanks again, Otheos.

[otheos]

Link removed, sorry for jumping the gun (what's the matter with me).

[Jim Tripp]

It's official. The new article on primary and secondary PCI performance for the MPX chipset is up here. (http://www.hardwaretech.info/guides/pci_bus_performance.php)

I think I'll try to get a link on the news page here. Thank you all for your support and interest.

Jim Tripp