Asus crippled ICH10 performance on their X58 boards.

[mikeyakame]

So how many PCI-E lanes does the ICH10 have on a P45 board?

ICH9/10 have 6 PCI-E v1.1 lanes for shared onbard device bus' and low bandwidth PCIE v1.1 slots, ie 1x or 4x.

You should also note when you overclock the system on the Host Bus side, you'll improve data going out (read burst) due to additional Host Bus bandwidth and cycles but on the other hand you are also creating a queue on the data coming in because Host Bus can push more data faster than DMI bus bandwidth is there. Raising PCIE frequency helps stabilize the spikes in IO reads, and improves IO write bandwidth because DMI clock is generated by clock generator PCIE dividers. Raising PCIE frequency beyond design can introduce signal integrity degradation from unshielded external EMI or cross chatter from selecting a similar reference frequency to a vendors own unique reference frequency, and then all hell breaks loose on your system

X38/X48/X58 have 36 PCIE v2.0 lanes. 32 lanes for PCIE slot allocation. 4 lanes for DMI (direct media interface, which is a dedicated two way point to point link on PCIE v2.0 4x bus) interconnect host link between PCH (x58) / MCH (x38/48) and IOH (ICHx).

P35/P45/etc have 20 PCIE v2.0 lanes. 16 for PCIE slot, 4 lanes for DMI.

ICH has always been on DMI, which behaves similarly to PCI while at the same time behaving like PCIE with VC (virtual channels) layer for QoS and transaction scheduling / interleaving for all IOH root bridge outgoing transactions with TAD (target address decode) destination beyond IOH scope or incoming bus transactions from MCH with TAD lying inside IOH.

ICH is given priority on DMI VC's and allowed to request priority transactions for dedicated 1-2 PCIE lanes. 300MB/sec is probably just the amount of DMI transaction bandwidth the ICH is limited to, because there are important LPC and SMBUS devices also living on the IOH and lest we forget all the routing management, strobe requests, priority transactions, and so on.

Both your lack of understanding and failure to take the time to go to Intels website and find the ICH datasheet for your model to get a better idea of "how Asus is screwing you over", you might have realized that Asus while many things still has to stick to Intel specifications for board chipset mechanical and electrical design, and on top of that you might have saved the Internet from the wild fires that you started in PC news gossip columns.

You should try and understand something or at least ask somebody who does understand it, to get a clearer picture on what actually happens. Even if it doesn't mean much to you to understand something, doing so is the key to not looking like a fool on the Internet or being sued for defamation outside the Internet.

Wild claims cost companies lost business, they lose enough they'll sick their lawyers on you to seek damages.

[Chosen.]

Very interesting info, do we know if Asus stuck to the X58 whitepapers? How much can the board manufacturer deviate from the original plans?

I just connected the ANS-9010 on my Gigabyte mATX G33 board (ICH9) and it works just fine at 370 & 300 Mb/sec....

I'm running out of ideas for things to check...

[Spoiler]

Both your lack of understanding and failure to take the time to go to Intels website and find the ICH datasheet for your model to get a better idea of "how Asus is screwing you over", you might have realized that Asus while many things still has to stick to Intel specifications for board chipset mechanical and electrical design, and on top of that you might have saved the Internet from the wild fires that you started in PC news gossip columns.

You should try and understand something or at least ask somebody who does understand it, to get a clearer picture on what actually happens. Even if it doesn't mean much to you to understand something, doing so is the key to not looking like a fool on the Internet or being sued for defamation outside the Internet.

Wild claims cost companies lost business, they lose enough they'll sick their lawyers on you to seek damages.

I thought that was Chosen's main goal here...to understand why the difference of performance. Can't these forums be used as such? Whitepapers are good and all, but feedback here can be explained much better.

I agree..putting any blame soley on Asus is not the right way of doing things, but I really just took his post as wanting some answers.

Anyway, here are some more questions:

So when you talk about DMI and the 300MB/s limit, you are refering to the link between the northbridge and southbridge for the ICH controller..correct?

So what is up with the PCI reference for the ICH9/10 Raid controller in Everest?

Given the 300MB limit..how do people like Chosen and others explain higher seq read numbers. Overlocking? Something doesn't sound right.

[Chosen.]

ICH9/10 have 6 PCI-E v1.1 lanes for shared onbard device bus' and low bandwidth PCIE v1.1 slots, ie 1x or 4x.

You should also note when you overclock the system on the Host Bus side, you'll improve data going out (read burst) due to additional Host Bus bandwidth and cycles but on the other hand you are also creating a queue on the data coming in because Host Bus can push more data faster than DMI bus bandwidth is there. Raising PCIE frequency helps stabilize the spikes in IO reads, and improves IO write bandwidth because DMI clock is generated by clock generator PCIE dividers. Raising PCIE frequency beyond design can introduce signal integrity degradation from unshielded external EMI or cross chatter from selecting a similar reference frequency to a vendors own unique reference frequency, and then all hell breaks loose on your system

X38/X48/X58 have 36 PCIE v2.0 lanes. 32 lanes for PCIE slot allocation. 4 lanes for DMI (direct media interface, which is a dedicated two way point to point link on PCIE v2.0 4x bus) interconnect host link between PCH (x58) / MCH (x38/48) and IOH (ICHx).

P35/P45/etc have 20 PCIE v2.0 lanes. 16 for PCIE slot, 4 lanes for DMI.

ICH has always been on DMI, which behaves similarly to PCI while at the same time behaving like PCIE with VC (virtual channels) layer for QoS and transaction scheduling / interleaving for all IOH root bridge outgoing transactions with TAD (target address decode) destination beyond IOH scope or incoming bus transactions from MCH with TAD lying inside IOH.

Very interesting information, I have spent the last 48 hours trying to figure out how things work inside my motherboard.
Not because I have to (somebody who spends $300 for a new motherboard expects steps forwards, not backwards), but because I spend my time in my pc more than just playing games.

ICH is given priority on DMI VC's and allowed to request priority transactions for dedicated 1-2 PCIE lanes. 300MB/sec is probably just the amount of DMI transaction bandwidth the ICH is limited to, because there are important LPC and SMBUS devices also living on the IOH and lest we forget all the routing management, strobe requests, priority transactions, and so on.

I don't know about this, I have seen higher transfer rates on the ICH family, like for example the half Gb/sec that a pair of X25-E's can achieve:


Also, through practice, it has been found that the actual (practical) cap of the ICH10 is ~660Mb/sec, as stated earlier in the thread. For example, three X25-M's that could in theory perform 3*250Mb/sec=750Mb/sec, are capped at:

Both your lack of understanding and failure to take the time to go to Intels website and find the ICH datasheet for your model to get a better idea of "how Asus is screwing you over", you might have realized that Asus while many things still has to stick to Intel specifications for board chipset mechanical and electrical design, and on top of that you might have saved the Internet from the wild fires that you started in PC news gossip columns.

A) And who told you that I haven't been in the Intel site researching? Hence my question earlier, on "how much does a motherboard manufacturer have to stick to the reference design of the chipset manufacturer?".
B) I couldn't care less about Asus' reputation at this point. If this was the subject of my thesis, I would be sending polite emails to Asus and I would be patiently awaiting for their feedback. However, there is a $300-thin line between "asking" and "demanding/being entitled to".
I had problems with Asus motherboards in the past, and all I did was to send an email to their product support team and wait forever for a dry answer like "We don't support RAID controllers on the PCI-E x16 slots" and the solution so far was always simple yet expensive: get rid of it and buy/try a new board.

Wild claims cost companies lost business, they lose enough they'll sick their lawyers on you to seek damages.

And bad products cost consumers lost money, what is your point? That I should shut up and don't dare accuse the mega-company for a product with a major flaw? This is not how it works mate.
The root-cause behind this performance degradation is unknown to me, and I am making assumptions based on all the information that I come across; the performance degradation of the "new and improved" product though, is a fact whether they (Asus) like it or not (I certainly don't).

Back on the subject now, I will assume that your criticism had good intentions and you were not just trying to contrast your expertise against my very basic knowledge on the subject, but the fact remains that in theory it all works lovely and in an identical way between the P45's and the X58's implementations of the ICH10, but in practice there is a performance drop between 40% (transfer rates) and 500% (small reads/writes) and I think that all involved stakeholders should be aware of it, both Asus and the consumers who spend their money hoping on an "upgrade".
Any objections on that?

[XS Janus]

MAN if this pans out as a definite problem... we need a new thread detailing, what RAID controller is on what on all x58 boards!

[Brahmzy]

Very interesting. I came from a P45 to the x58 I have now. I never though to bench the differences. I still have both boards and I think I'm going to do some serious testing on the two...

[Mechromancer]

This post has garnered enough attention to be put in the TechReport.com Tuesday Shortbread. Wow.

[headala]

I think the original thread title could have been a bit less incendiary, since "Asus crippled" sounds like a willfully hurtful intent, and I don't think we can prove that at all here. This *could* be fixed by a bios update, or it *could* be an X58 chipset issue, right?

I've seen a lot of Asus reps replying to poor ratings on Newegg, maybe you should go there and explain the situation and give it a 1-star. That would probably get more attention than this thread would.

[Halk]

On my board (M3A79-T Deluxe) Everest reports the SATA controller (and IDE) are on 66Mhz PCI controllers. At a guess that would limit them to under 250MB/sec. Everest does state the soutbridge is an SB700, when I know it should be an SB750 though, so I'm not prepared to say I'm 100% convinced by the results.

As for a BIOS update 'fixing' issues like this I'm less than convinced that's possible. Is this problem not more likely to be due to the way the PCB is traced rather than the way the BIOS works? I'm asking because I don't know...

[Brahmzy]

So, here's my 2 TITAN's on my ASUS P6T WS Pro's ICH10R (x58). I guess I'm not sure if I'm having this issue or not.

[mikeyakame]

Very interesting information, I have spent the last 48 hours trying to figure out how things work inside my motherboard.
Not because I have to (somebody who spends $300 for a new motherboard expects steps forwards, not backwards), but because I spend my time in my pc more than just playing games.


I don't know about this, I have seen higher transfer rates on the ICH family, like for example the half Gb/sec that a pair of X25-E's can achieve:


Also, through practice, it has been found that the actual (practical) cap of the ICH10 is ~660Mb/sec, as stated earlier in the thread. For example, three X25-M's that could in theory perform 3*250Mb/sec=750Mb/sec, are capped at:



A) And who told you that I haven't been in the Intel site researching? Hence my question earlier, on "how much does a motherboard manufacturer have to stick to the reference design of the chipset manufacturer?".
B) I couldn't care less about Asus' reputation at this point. If this was the subject of my thesis, I would be sending polite emails to Asus and I would be patiently awaiting for their feedback. However, there is a $300-thin line between "asking" and "demanding/being entitled to".
I had problems with Asus motherboards in the past, and all I did was to send an email to their product support team and wait forever for a dry answer like "We don't support RAID controllers on the PCI-E x16 slots" and the solution so far was always simple yet expensive: get rid of it and buy/try a new board.


And bad products cost consumers lost money, what is your point? That I should shut up and don't dare accuse the mega-company for a product with a major flaw? This is not how it works mate.
The root-cause behind this performance degradation is unknown to me, and I am making assumptions based on all the information that I come across; the performance degradation of the "new and improved" product though, is a fact whether they (Asus) like it or not (I certainly don't).

Back on the subject now, I will assume that your criticism had good intentions and you were not just trying to contrast your expertise against my very basic knowledge on the subject, but the fact remains that in theory it all works lovely and in an identical way between the P45's and the X58's implementations of the ICH10, but in practice there is a performance drop between 40% (transfer rates) and 500% (small reads/writes) and I think that all involved stakeholders should be aware of it, both Asus and the consumers who spend their money hoping on an "upgrade".
Any objections on that?

I apologize for coming across so harsh, the intention of my post was supposed to come across as helpful! It was pretty late when I wrote it after all. All I meant to say was the topic of the original post was that it might come across as Asus did it in on purpose to hurt the customer, when actually they didn't and it's a problem they aren't sure of or know what they did wrong to cause it. On the other hand too, there are many wildfires spread around Internet forums by guys who assume because they see something that doesn't seem right, those "experts" don't bother researching and just throw accusations and rumours around which hurt companies if they are false. As long as you did your research I respect that, just need to be a little more what would you call it, "diplomatic" about such a thread title

I agree there is a performance drop but what attributes to it is beyond me. I've seen similar on all Asus boards where the ICH is capped to bandwidth, and read/writes are up and down. Some vendors have solid performance on their boards, and there is no explanation really.

There are two reasons that come to mind that could be the cause of it.

1) Design problem they overlooked when they were too busy making the boards overclock for WRs.

2) Bios problem either on part of American Megatrends (AMI) or Asus. Now this seems more likely to be a problem. PCI / Port routing is controlled by bios code, also IRQ allocation. If the shared IRQ the ICH is on somehow restricts its performance because the other device/s on same IRQ hinder it by hammering out too many requests on the port its through routed through that could be fixed by routing tables in bios. There is also the case of MSI/MSI-X (messaged signal interrupts) which is a higher level protocol allowing overlap and bus scheduling on shared interrupt ports, typically an IRQ requests a lock on bus and no other devices can use the bus during this interrrupt, until the requesting device releases the lock, so not being made correctly or handled right can result in seriously degrading performance. I'd hate to think of all the other reasons that may cause this degradation too, it's painful!

I think Asus really need to sit down with AMI about the core bios code and figure this problem out, whether its software (bios) or their hardware design.

If it's AMI's fault then they can work together to resolve it, or if its Asus engineers misunderstanding of AMI core bios implementation I'm sure AMI would be happy to help them figure the problem out too. This is resolvable at least and would show good will to the customers if they really sorted it out, provided it's not hardware design level.

[Chosen.]

I apologize for coming across so harsh, the intention of my post was supposed to come across as helpful! It was pretty late when I wrote it after all. All I meant to say was the topic of the original post was that it might come across as Asus did it in on purpose to hurt the customer, when actually they didn't and it's a problem they aren't sure of or know what they did wrong to cause it. On the other hand too, there are many wildfires spread around Internet forums by guys who assume because they see something that doesn't seem right, those "experts" don't bother researching and just throw accusations and rumours around which hurt companies if they are false. As long as you did your research I respect that, just need to be a little more what would you call it, "diplomatic" about such a thread title

Makes much more sense when you put it this way, I have edited again (sigh) the thread title until further feedback from other X58+SSD owners flows in.

I think Asus really need to sit down with AMI about the core bios code and figure this problem out, whether its software (bios) or their hardware design.

If it's AMI's fault then they can work together to resolve it, or if its Asus engineers misunderstanding of AMI core bios implementation I'm sure AMI would be happy to help them figure the problem out too. This is resolvable at least and would show good will to the customers if they really sorted it out, provided it's not hardware design level.

I am almost convinced that the integrity of the whole SB structure was compromised/sacrificed in favour of the additional SLI capabilities, not native on the X58 by itself. There are many core differences between the P5Q and the P6T and one of my theories goes like this:
- In the P45 chipset the memory controller is located on the motherboard and possibly "closer" (in terms of electrical signals) to the SB, hence the 3.5-4Gb/sec burst speed (as system memory is used for caching by the ICHxR's).
- In the X58 the memory controller is located inside the processor, and might be further away from the SB (again, not talking about inches here), or that this PCI/PCI-e peculiarity that could be unaffected by the MC on the motherboard, finally takes the hit because of the IMC on the Nehalem architecture.

I keep feeling that I am getting closer but I keep getting a bit more lost, or if you prefer keep having to delve deeper within unknown territories to get an answer.

I've seen a lot of Asus reps replying to poor ratings on Newegg, maybe you should go there and explain the situation and give it a 1-star. That would probably get more attention than this thread would.

I thought about this yesterday, but exactly because my purpose is not to harm Asus as a company or their sales numbers, I didn't want to post such information in the egg, where the majority of users/buyers have no clue what the ICH is or what the HDTach numbers mean and would be happy to buy a new stable board; that would be pointless. It might have caused a more immediate reaction by Asus, in the likes of "Please contact our Tech Support team and blah-blah" but the damage done to the (theoritically unaffected by this issue) majority of the board's potential buyers/average Joes, would be disproportionate to the help that I would get from the PR-ish Asus rep who monitors the Newegg reviews
I think I have better chances of finding out what the story is, by asking here

[dctokyo]

Can everyone post your board spec?

My ASUS Maximus II Formula shows
Device Description Intel 82801HB/IB ICH8/ICH9 - SATA RAID Controller
Bus Type PCI

Device Features
66 MHz Operation Supported

[Chosen.]

I am not sure if this information alone can help us get to any conclusions, that's why I insisted on owners of fast SSD storage.
The idea behind this, is to post some numbers involving small reads/writes (where the difference is more obvious) along with your motherboard and storage specs and in combination with information from Everest (or any other program that provide such information).
This way we could cross reference the results with existing ones on the net and see whether your X58-based ICH10 offers similar or seriously degraded performance.

[BenchZowner]

I can only allocate two Mtron 3535 SSD's and 4 Samsung F1 1TB HDDs for testing immediately at this time, don't have the time required to backup my data to free more SSDs now.
For starters I've hit 550+ MB/s read/write rates on the ICH10R with the BloodRage

[Tony]

Gentlemen, if you are testing with Titan or Apex you are going to need 256k stripe which no boards ICH9/10 will offer (unless someone slipped it in..if so please tell me)
If you are using 4 standard SSD's you are probably going to need 256k stripe.
128K stripe is really only good over 2 standard (1 controller non internal raid) ssd's

[RealTelstar]

Gentlemen, if you are testing with Titan or Apex you are going to need 256k stripe which no boards ICH9/10 will offer (unless someone slipped it in..if so please tell me)
If you are using 4 standard SSD's you are probably going to need 256k stripe.
128K stripe is really only good over 2 standard (1 controller non internal raid) ssd's

Hi Tony,

Can you explain why?

[One_Hertz]

Hi Tony,

Can you explain why?

There is an explanation in the stickies on the OCZ forums.

[jmacari]

Can everyone post your board spec?

My ASUS Maximus II Formula shows
Device Description Intel 82801HB/IB ICH8/ICH9 - SATA RAID Controller
Bus Type PCI

Gigabyte GA-EP45-UD3P...same as above (ASUS).

At the moment, I am running 2 Velociraptors (raid0), so not noticing any of the throughput thresholds listed in thread.

[Brahmzy]

Was running a few quick tests last night...

FWIW I ran some benches at my 4.0GHz 920 OC, then at completely stock, nothing changed at all. Same exact good speeds from the ICH10R.

[pjkenned]

Although not an SSD owner, I'd bet this is an issue on the Gigabyte X58 Extreme board too. I'm running 1.5 TB Seagate drives on the ICH10R and with 5 drives in raid 5 I was maxing out in the mid 250MB/s range for reads. Since I am too afraid to do one huge partition, I keep everything in 1-2TB partitions and tried a Raid 0 partition across the 5 drives and still maxed out in the 250MB/s range.

Strange enough, this was the same as I had with 4 drives in the system, and I'm rebuilding the arrays with a 6th drive today. If I can't get 6x 7200.11's to put out more than 250MB/s tonight in Raid 0... I'd suspect this is the issue. I have two 8 channel HW raid cards coming so I'll test this also.

[kaskuli]

I thought that was Chosen's main goal here...to understand why the difference of performance. Can't these forums be used as such? Whitepapers are good and all, but feedback here can be explained much better.

I agree..putting any blame soley on Asus is not the right way of doing things, but I really just took his post as wanting some answers.

Anyway, here are some more questions:

So when you talk about DMI and the 300MB/s limit, you are refering to the link between the northbridge and southbridge for the ICH controller..correct?

So what is up with the PCI reference for the ICH9/10 Raid controller in Everest?

Given the 300MB limit..how do people like Chosen and others explain higher seq read numbers. Overlocking? Something doesn't sound right.

[WonderSausage]

On my board (M3A79-T Deluxe) Everest reports the SATA controller (and IDE) are on 66Mhz PCI controllers. At a guess that would limit them to under 250MB/sec.

Wrong... the "PCI bus" indication in Everest merely reflects that Intel had to assign some virtual bus to the DMI rather than inventing an entirely new type of bus classification. Read the thread carefully.

Once again people... the "PCI bus" thing in Everest is VIRTUAL, not material to the performance issue at hand.

[Halk]

Wrong... the "PCI bus" indication in Everest merely reflects that Intel had to assign some virtual bus to the DMI rather than inventing an entirely new type of bus classification. Read the thread carefully.

Once again people... the "PCI bus" thing in Everest is VIRTUAL, not material to the performance issue at hand.

I did say I wasn't convinced by the results :P

You said "once again" have you posted about this before?

[Ender17]

well if the PCI bus isn't the reason for decreased performance, any ideas on what is?