Evaluate this basic SCSI setup

[Al Shades]

LSI LOGIC LSI20160B-F PCI SCSI Controller Card - $95

http://www.newegg.com/Product/Product.aspx?Item=N82E16816118057

Fujitsu MAX3036NP 36.7GB 15,000 RPM 8MB Cache SCSI Ultra320 68pin Hard Drive - $150

http://www.newegg.com/Product/Product.aspx?Item=N82E16822116001

All I care about is performance in games and desktop-level browsing. Storage capacity is irrelevant. Will be used in a 650i Ultra mobo. Will also have X-Fi sound and NIC on the PCI bus (will this affect the bandwith with only 1 drive?).

 

[naro]

if u're using on a PCI slot, u'll be limited to the shared bandwidth of 133MB/s of the PCI slots.

So, its still okay if you're using only 1 SCSI drive. But once you do a Raid 0, the PCI bandwidth will bottleneck.

 

[Order]

That is a very good drive. I have the MAU in one of my other machines and it is very fast. Its a bit loud, though.

 

[MixManSC]

Like they said - only one drive you will be fine. If you go to more drives you might need to look into a PCIe controller for the additional bandwidth. Not sure about noise on the MAU drives. I have 4 of the MAX 15K (SAS) drives in my machine here and they are pretty much silent. They are connected tot he on-board SAS controller on a Dell Precision 690 though. I will say this - these drives are considerably faster than any desktop class drive I've ever used.

 

[Order]

Heh, MixMan I was just reading about your build over at XS.

 

[MixManSC]

Heh, MixMan I was just reading about your build over at XS.

I ended up really spending more than I planned to but.... damn. It's just fun finishing out a powerhouse of a machine. I'm really wanting to upgrade it already to dual quad core Xeons....

 

[Order]

I just snagged (4)15k.5s and a good Adaptec SAS controller the other day. I'm interested to see how they will score compared to the MAXs.

 

[MixManSC]

I would think it will be pretty close as they are both similar classed drives. It might be affected by the controllers though. I have no idea really how good the on board dell 5i controller is although I do believe it is connected to the system bus via PCIe but I have no idea how many lanes or if that really even matters. I know PCI controllers can become bus limited though. Post the results once you get them in and tested.

 

[Order]

Sounds like a project for this afternoon .
I'll make a new thread so I can stop hijacking this one hehe.

 

[unhappy_mage]

Your performance with that setup will be terrible.

Because you need a scsi cable, too The card doesn't include one and neither does the drive. Don't forget to order one.

Why is your NIC on the PCI bus? Onboard ethernet controllers are generally tied in with something faster than PCI, and adding extra junk on the bus won't make it faster.

 

[naro]

I think the best option is to look for a PCIe card so that there wont be a bottleneck by the PCI slots.

I dun htink i've see a PCIe U320 SCSI controller before. Best bet would be to go SAS.

 

[Order]

The Dell Perc4e is a PCI-E SCSI320 card. You can find them on Ebay for very low prices. They're the OEM version of an LSI card. I don't remember the exact model number.

 

[Al Shades]

Why is your NIC on the PCI bus? Onboard ethernet controllers are generally tied in with something faster than PCI, and adding extra junk on the bus won't make it faster.

I will eventually be getting a Killer NIC for gaming.

To use a PCI-E adapter would be kind of a pain because I would have to purchase an SLI board and use the second x16 slot for the SCSI controller. Unfortunately, they only seem to make them in x4 and above factors. Too bad we can't put those x1 slots on nForce mobos to use.

Does SATA use the PCI bus? So if I had 1 SATA drive for storage would that reduce the bandwith available to the SCSI or no?

 

[xenotype]

I will eventually be getting a Killer NIC for gaming.

why? because its PCI-X so you can keep all the PCI bandwidth for the SCSI controller card? the killer NIC really just is a placebo.

SATA will use the PCI bus if its a controller card on the PCI bus, if its on the motherboard, then no, its not affecting the PCI bandwidth.

 

[drizzt81]

why? because its PCI-X so you can keep all the PCI bandwidth for the SCSI controller card? the killer NIC really just is a placebo.

SATA will use the PCI bus if its a controller card on the PCI bus, if its on the motherboard, then no, its not affecting the PCI bandwidth.

The `normal' Killer NIC is a regular PCI card. Even if it were PCI-X, most desktop users do not have a PCI-X slot. PCIe is much more common.

 

[naro]

I will eventually be getting a Killer NIC for gaming.

To use a PCI-E adapter would be kind of a pain because I would have to purchase an SLI board and use the second x16 slot for the SCSI controller. Unfortunately, they only seem to make them in x4 and above factors. Too bad we can't put those x1 slots on nForce mobos to use.

Does SATA use the PCI bus? So if I had 1 SATA drive for storage would that reduce the bandwith available to the SCSI or no?

onboard Gigabit NIC are more than capable.

since u've already mentioned that all you care abt is performance, changing to an SLi board should'nt be a problem.

if you want to do SLi for your graphics, just get the 680i with a 3rd PCIe slot, which is configured to x8 lanes.

 

[UICompE02]

To use a PCI-E adapter would be kind of a pain because I would have to purchase an SLI board and use the second x16 slot for the SCSI controller. Unfortunately, they only seem to make them in x4 and above factors. Too bad we can't put those x1 slots on nForce mobos to use.

Being able to use the x1 slot for other things depends on how much you trust yourself with a Dremel or similar tool... It's possible to grind off the back of the PCI-E slot and then plug in a wider card. Sure, you'll still be limited to 250MB/s, but that's almost twice what a conventional PCI slot will give (almost 4x if you consider you have that bandwidth in both directions now, plus it's not shared with anything else...)

 

[defakto]

Don't get the killer nic. It is a waste of money and marketing at it's most genius.

 

[Al Shades]

onboard Gigabit NIC are more than capable.

since u've already mentioned that all you care abt is performance, changing to an SLi board should'nt be a problem.

if you want to do SLi for your graphics, just get the 680i with a 3rd PCIe slot, which is configured to x8 lanes.

I have no intention of doing SLI until they get their heads out of their asses and figure out a way to make it double the performance in every app. Anything less than a 100% performance increase is unacceptable given the technical ease of doubling the performance. All that's required is to force each GPU to draw only half the screen and viola, double performance. Simply instruct the card to paint half of the on-screen resolution. It takes 1 line of code. If they can have 2-4 CPU sockets on a high end server board, they can figure out how to do 2 GPU's. They don't even need to bridge them, they could be entirely seperate devices sharing the same bus, just like any other expansion cards.

Don't get the killer nic. It is a waste of money and marketing at it's most genius.

That's what you think, but I'm going to give it a shot. If, after 2 weeks I am not satisfied with the performance of the Killer NIC, then I will return it to Newegg for a refund. Simple. I happen to think it that it works and works well, particularly in MMO's. The company supports the product very well and they seem to care about their customers. Killer NIC keeps winning online awards and praise, yet random people continue to bash it for no apparent reason. It makes me feel sorry for the makers. They put out an original product that offers performance gains that can't be obtained anywhere else, and get plenty of shit for it. On the other hand people sheepishly support the motherboard manufacturers, for instance, when they put out a "premium" board that offers the exact same performance as it's entry-level counterpart at 2x the cost (680i AHEM). How many people on this board own an eVGA 680i SLI? Answer: A lot. And what performance gains are they getting over the soon-to-be-released $99 650i ultra? Answer: Zer0.

I used to play Asheron's Call (MMO) and I'd like to start up again. Both network and system lag often reared their ugly heads in the intense battle sequences of that game. On the system side, I've always wanted to do what one AC player supposedly did and run the game entirely off RAM. To that end, I've been looking at various RAM Disk apps and even considering peripherals such as Gigabyte's i-RAM card. I consider it a damn shame that this functionality is not yet widely available. This is something that, for all intents and purposes, could have been done with the release of XP. If MS wanted me to care about their shitty new OS, they should have integrated RAM-Disk capabilities into Vista from the start. If I can't run my games off RAM then I will settle for the next best thing, which would be the fastest, enterprise-class storage drive that money can buy. That's why I made this thread.

Being able to use the x1 slot for other things depends on how much you trust yourself with a Dremel or similar tool... It's possible to grind off the back of the PCI-E slot and then plug in a wider card. Sure, you'll still be limited to 250MB/s, but that's almost twice what a conventional PCI slot will give (almost 4x if you consider you have that bandwidth in both directions now, plus it's not shared with anything else...)

I know that a PCI-e card will run in any slot that is at least as large as it is. For instance, you could put a x4 card in an x8/x16 slot. So upwards compability is not a problem. Only downwards compability is. Wikipedia claims:

It is not possible to place a physically larger PCIe card (e.g. a 16x sized card) into a smaller slot, even though the two would be signal-compatible if it were possible.

For this reason, I take the view that every premium motherboard with onboard PCI-E should have only full-sized, x8/x16 expansion slots. In light of the backwards compability of x16 with smaller interface cards, there really is no legitimate reason for putting smaller slots onto a board. They have got to stop littering their boards with 2-3 of those utterly worthless x1 slots. Why every maker insists on doing this, I'll never know. They need to cut the crap and stick more usuable PCI slots on there. PCI has been used for expansion since the 90's, it still works fine despite all the hype about new interfaces. Additionally, they need to realize that enthusiasts are not running GeForce 3's and every high end video card is going to take up 2 slots. It is a reality of the hardware market and their board layouts should reflect it. Remember the "good old days" of socket 478 when you had 5-7 usuable PCI slots? It's too bad that I can't stick my 8800 GTS in a s478 mobo. Else, I'd do it in a heartbeat.

I just snagged (4)15k.5s and a good Adaptec SAS controller the other day. I'm interested to see how they will score compared to the MAXs.

How much did you pay for the controller? What do you think of my selection at the top of this thread?

 

[Al Shades]

I just looked up a few things in order to determine why SLI, in it's current iteration, sucks.

The entire problem can be traced to their insistence on using dynamic load balancing between the two cards. That is to say, they are not content with having one card painting half the screen at all times and the other card painting the other half and leave it at that. They want the workload to be equally distributed among both cards, and therefore, they dynamically assign a percentage of the screen to each card based on the real-time workload. Enabling a graphical overlay will even show you this process in action.

Unfortunately, in doing this, they are complicating something that would be a trivial technical matter (thus violating one of the basic laws of engineering).

http://techreport.com/reviews/2004q4/sli/index.x?pg=2

For the workload to be assigned dynamically, the graphics processor has to collect and analyze data about the image in real time. This unnecessary process creates additional overhead and lag time, as the GPU must constantly approximate the most efficient way of splitting up the screen and assign proportional amounts of the workload to each card.

From an engineering perspective, it can only be considered idiotic that they don't provide an option for SLI hardware acceleration through single frame rendering using static load balancing (50/50 screen rendering). Sure, the load balance wouldn't be even between the two cards, but that wouldn't matter unless and until one card was taxed to the limit of it's rendering ability. That would occur only under the most extreme, graphically-intensive apps. Under such circumstances, it's doubtful that dynamic load balancing would be beneficial at all, such both cards would likely be performing at or near the upper limit of their rendering ability.

Of course, if conventional split-screen, sky/ground rendering presents such a gross workload disparity between the two GPU's, they could always split it vertically rather than horizontally. That, too, would take only one line of code. But hey, what do I know, I'm just your average end-user. I've never coded anything, I just happen to be well versed in basic logical and engineering principles. And in this case, there's no question that I'm right.

http://en.wikipedia.org/wiki/Scalable_Link_Interface#Implementation

 

[naro]

so just use your other PCIe slot for a SAS controller card since you're saying that SLi can't provide you with 100% performance increase.

unless you're using some of the Asus workstation motherboards which have PCI-X slots on them.

 

[Order]

How much did you pay for the controller? What do you think of my selection at the top of this thread?

I got the controller for $350 used. It was a very good deal that you're probably not likely to find elsewhere as I've looked on Ebay and whatnot and its generally around $500+. Your idea about the MAU/MAX series is pretty good. I ran one in my old gaming system over the summer and it was quite responsive on a Dell Perc4e controller with 256MB cache. I've been reading, however, that the Raptor 150 is faster in most single user applications that don't require lower access times and queued I/O. That said, however, I'm not discouraging you at all from using the MAU/MAX because it truly was incredibly fast and made the system feel very snappy. Good luck.

 

[drizzt81]

I just looked up a few things in order to determine why SLI, in it's current iteration, sucks.

That is a rather bold statement.

From an engineering perspective, it can only be considered idiotic that they don't provide an option for SLI hardware acceleration through single frame rendering using static load balancing (50/50 screen rendering).

Well, I think that it would be a nice option to have, but I understand that engineers at nvidia have a limited amount of time available. As such they must choose which project they should undertake. While programming a 50/50 splits sounds easy at first, it is important to realize that it may not be trivial. Depending on which way the split is done -vertical vs. horizontal- the load may be distributed rather unequally. As such the card that has its image completed quicker will have to wait for the slower card to be done. Instead of adding an input lag -image analysis- we are adding an output lag -image reconstruction.

I'd love to see some comparisons between the two options, but I do not think we ever will. Independent of that, I think that calling nVidia's engineers `incompetent' is unfair.

Killer NIC keeps winning online awards and praise, yet random people continue to bash it for no apparent reason.

Well, according to the [H]ard|OCP review the Killer nic works well with WoW, but does little to nothing for CS or Q4. You can draw your own conclusions from that. I guess if WoW is your primary application this may be a good tool for you.

 

[unhappy_mage]

I have no intention of doing SLI until they get their heads out of their asses and figure out a way to make it double the performance in every app. Anything less than a 100% performance increase is unacceptable given the technical ease of doubling the performance. All that's required is to force each GPU to draw only half the screen and viola, double performance. Simply instruct the card to paint half of the on-screen resolution. It takes 1 line of code. If they can have 2-4 CPU sockets on a high end server board, they can figure out how to do 2 GPU's. They don't even need to bridge them, they could be entirely seperate devices sharing the same bus, just like any other expansion cards.

This is utterly wrong. Graphics is quite parallelizable, yes, but dividing the workload into "the top half of the screen" and "the bottom half of the screen" wouldn't lead to a 100% gain. Consider MMOs; when you're standing in town all the people are at the bottom of the screen. It'll take considerably longer to render the bottom half of the screen, where all the polygons are.

That's what you think, but I'm going to give it a shot. If, after 2 weeks I am not satisfied with the performance of the Killer NIC, then I will return it to Newegg for a refund. Simple.

Fair enough. But do some testing to isolate the NIC as the source of the benefits or downfalls of the card before trying something else.

For this reason, I take the view that every premium motherboard with onboard PCI-E should have only full-sized, x8/x16 expansion slots. In light of the backwards compability of x16 with smaller interface cards, there really is no legitimate reason for putting smaller slots onto a board.

I agree. It'd be nice to have a simpler standard - all the slots are x16 sized, and the card size varies.

 

[UICompE02]

I know that a PCI-e card will run in any slot that is at least as large as it is. For instance, you could put a x4 card in an x8/x16 slot. So upwards compability is not a problem. Only downwards compability is. Wikipedia claims:



For this reason, I take the view that every premium motherboard with onboard PCI-E should have only full-sized, x8/x16 expansion slots. In light of the backwards compability of x16 with smaller interface cards, there really is no legitimate reason for putting smaller slots onto a board. They have got to stop littering their boards with 2-3 of those utterly worthless x1 slots.

I think you may have misunderstood what I was saying. You can chop out the little piece of plastic at the end of a x1 PCI-E slot and stick any width card you want into it. Of course, it depends on how much you trust yourself with slicing part of the PCI-E socket out (also if your motherboard has components in that area that may get in the way of the longer edge connector). I have a server with a x4 slot that has the end missing (from the factory) so you can plug wider devices into it. But I also have some boards we modified manually to function this way.

 

[mikeblas]

I have no intention of doing SLI until they get their heads out of their asses and figure out a way to make it double the performance in every app. Anything less than a 100% performance increase is unacceptable given the technical ease of doubling the performance. All that's required is to force each GPU to draw only half the screen and viola, double performance.

You have a naive view of the problem.

 

[xenotype]

You have a naive view of the problem.

Indeed. What about the overhead required for the calculations needed in order for the two cards to "known" what portions of the screen to render? You will never get 2x the performance by doubling the videocards, this has LOOOOONG been known. 1.5x at best, mebbe 1.7x but you cant be serious with expecting a 200% boost in performance with 2 cards in SLi. Its practically the same thing with processors and threading. Pentium 4's famous HyperThreading doesnt exactly double your CPU's output, neither does dual processors. Blame the software engineers, i suppose.

 

[Al Shades]

Indeed. What about the overhead required for the calculations needed in order for the two cards to "known" what portions of the screen to render? You will never get 2x the performance by doubling the videocards, this has LOOOOONG been known. 1.5x at best, mebbe 1.7x but you cant be serious with expecting a 200% boost in performance with 2 cards in SLi.

There would be no realtime calculations if the screen sizes rendered by each card were pre-apportioned and static. That is, if you simply modified the display output code by putting parenthesis around the resolution and added a coefficient of 1/2. The ability to do something very similar on single GPU's has existed for years. In F.E.A.R. it is an option in the Performance/Video/Advanced configuration menu called Pixel Doubling. It renders the scene at half res then simply stretches out that render over the full physical display area. Telling a GPU to render a certain portion of the screen is quite possibly the simplest instruction you can give it. The only real challenge is hardware related, in incorporating 2 graphics adapters onto a single bus. With the bandwith offered by high-speed PCI-e that is no longer an issue. They are stll trying to bridge the cards and form a composite image which is completely unnecessary and adds miles of complications. Understand that the scenario I'm describing is extremely simple from a technical perspective. The current implementation of SLI may not be simple, but don't blame me for that, blame the fools who thought it up.

The reason it has thus far been "known" that 2x performance was impossible was due to the inherent limitations of previous iterations of SLI which had to utilize the limited bandwith of PCI and AGP. PCI-e was specifically designed to get around these bandwith limitations, so there is no longer any excuse. The old conventional wisdom about SLI is out. It is time for them to get off their asses, as I said before, and make this work the way it should. 200% performance or bust.

To those who think a big company would never be foolish enough to spend time and money on a complicated implementation of something that could be done very simply, think again. It absolutely happens all the time in this business.

nVidia already proved that they were lacking in brain cells when they stopped including their classic control panel in the 8 series driver updates. The old panel was replaced by it's horrible successor, with the result that people are now having to use registry hacks in order restore it. Including both panels in their driver releases (as they did prior to 8xxx) would have cost them absolutely nothing. Now, additional time and effort has to be spent, if not by them then by their end-users, just to obtain a functionality that was always available in the past. That is a net loss and the definition of an unsound engineering practice. http://forums.nvidia.com/index.php?showtopic=27559

This is utterly wrong. Graphics is quite parallelizable, yes, but dividing the workload into "the top half of the screen" and "the bottom half of the screen" wouldn't lead to a 100% gain. Consider MMOs; when you're standing in town all the people are at the bottom of the screen. It'll take considerably longer to render the bottom half of the screen, where all the polygons are.

No delay would exist unless one GPU was operating at the upper limit of it's rendering ability, as stated in my last post. Pacman and Quake 3 may have vastly different performance loads, but an 8800 GTX could still take them on at the same time with no output delay whatsoever. This is what I mean. With the rendering area split in half, the likelyhood of a GPU approaching it's max output is also cut in half. It's only when all of the available pipelines on a GPU are being used that a rendering delay takes place. How often would that happen on a processor that was only required to draw half the screen? In today's apps, very rarely. Only under the most extreme, ultra-high res conditions would either GPU approach the limit of it's rendering ability.

If you have an app whose workload is designed for dual GPU's, then you had very well better take that into account in your SLI implementation. Under those circumstances, you would certainly want to be utilizing every ounce of combined processing power at all times, and dynamic load distribution would make sense. But this is not the case with modern apps because all of them are designed to perform well on a single GPU.

If you want to further circumvent the "workload disparity problem" in the majority of games, then simply cut the screen vertically instead of horizontally as I wrote earlier. Now you no longer have the "empty sky, dense ground" problem or it's corresponding opposite.

So, ideally, dynamic load balancing (and the additional overhead it creates) should exist as an option for ultra-high res applications.
For running absolutely everything else, static load distribution would work far better. If your cards were individually capable of running at 1357x848 resolution with full AA/AF, then you would be able to run 2 cards in the same configuration at 1920x1200 with no performance loss (figures used above are exact, not approximated).

 

[unhappy_mage]

There would be no realtime calculations if the screen sizes rendered by each card were pre-apportioned and static.

And if the complexity of the work one card was required to do were more complex than the other one? What do you do then?

The only real challenge is hardware related, in incorporating 2 graphics adapters onto a single bus. With the bandwith offered by high-speed PCI-e that is no longer an issue. They are stll trying to bridge the cards and form a composite image which is completely unnecessary and adds miles of complications.

PCI Express is only 4GB/s to and from the host machine, compared to 10GB/s for the SLI bridge (from the figures I was able to find; feel free to contradict if you find better numbers). And adding the latency of going through the host switch could be the unacceptable part, not bandwidth.

Understand that the scenario I'm describing is extremely simple from a technical perspective. The current implementation of SLI may not be simple, but don't blame me for that, blame the fools who thought it up.

If one card finishes rendering before the other one does, in your scheme, what should it do? Stop working while it waits for the other card to finish? Display immediately and risk tearing? The current implementation takes a rough guess at how much time each card should spend rendering its part and then has them do the work. The reason this isn't a 100% increase is because one card can still finish before the other, so one card sits idle for a while. But your guess is even worse than the current implementation's.

 

[Al Shades]

I think you may have misunderstood what I was saying. You can chop out the little piece of plastic at the end of a x1 PCI-E slot and stick any width card you want into it. Of course, it depends on how much you trust yourself with slicing part of the PCI-E socket out (also if your motherboard has components in that area that may get in the way of the longer edge connector). I have a server with a x4 slot that has the end missing (from the factory) so you can plug wider devices into it. But I also have some boards we modified manually to function this way.

Wow, that's very insightful. I see what you're saying. Is there any performance loss in doing so? I don't understand why socket sizes smaller than full length exist in the first place. Does anyone know the reason? Is it purely due to spacing considerations on motherboards?

I think I'm going to purchase a Raptor for now and then make the upgrade to SCSI down the road.

From what I have read regarding the Raptor line-up, the performance decreases on the lower capacity drives as well as those with the see through window (or rather, it runs noticeably louder). So from this I take it that the WD1500ADFD model would be the fastest/best among them. Has anyone read, seen, or heard differently?

http://www.newegg.com/Product/Product.aspx?Item=N82E16822136012
http://www.newegg.com/Product/Product.aspx?Item=N82E16822136011

The Raptor X 150 GB sells for nearly the same price. I would buy it for to the aesthetics, but not at the cost of an ounce of performance (or additional noise).

 

[Al Shades]

And if the complexity of the work one card was required to do were more complex than the other one? What do you do then?

In most instances, you do nothing. The relative complexity of one card's load to the other is completely irrelevant to performance so long as there is no output delay from either card. Only the absolute complexity of the image as a percentage of either card's ability to render it is important. Allow me to provide a few examples:

Scenario 1:
======%max rendering capacity
Card 1: 50
Card 2: 50

No performance loss

Scenario 2:
======%max rendering capacity
Card 1: 75
Card 2: 20

No performance loss

Scenario 3:
======%max rendering capacity
Card 1: 99
Card 2: 1

No performance loss

Scenario 4:
======%max rendering capacity
Card 1: 101
Card 2: 99

Performance loss. Card 1's load is heavier than it can sustain, thus leading to an output delay. Card 2's load is slightly lighter than it can sustain, thus leading to the possibility of a performance improvement if dynamic load sharing is utilized.

PCI Express is only 4GB/s to and from the host machine, compared to 10GB/s for the SLI bridge (from the figures I was able to find; feel free to contradict if you find better numbers). And adding the latency of going through the host switch could be the unacceptable part, not bandwidth.

http://en.wikipedia.org/wiki/Pci-express

With a maximum of 32 lanes, PCIe allows for a total combined transfer rate of 8 GB/s in each direction.

With 8 GB/s available total, that would leave 4 GB/s for each device in SLI, so I believe your figure was correct. This is a huge increase over PCI and AGP. If that is still not enough then let them design another standard or improve the ICH. This is what "premium motherboards" should exist for, not to provide them with a reason for charging a $150 markup for 2 extra SATA ports and a black PCB .

If one card finishes rendering before the other one does, in your scheme, what should it do? Stop working while it waits for the other card to finish? Display immediately and risk tearing? The current implementation takes a rough guess at how much time each card should spend rendering its part and then has them do the work. The reason this isn't a 100% increase is because one card can still finish before the other, so one card sits idle for a while. But your guess is even worse than the current implementation's.

The second option, no doubt. They should display immediately since the risk of tearing would be practically non-existent at normal desktop resolutions. If that became a problem in an app, that's when you would know to switch modes to performance sharing.

 

[unhappy_mage]

Scenario 2:
======%max rendering capacity
Card 1: 75
Card 2: 20

So it takes three times as long for card 1 to do its portion of the work as card 2. After the time it takes for card 2 to render, what does it do? It could be sitting idle... or it could be doing useful work. If it's sitting idle, you aren't getting a 100% improvement. That simple.

With 8 GB/s available total, that would leave 4 GB/s for each device in SLI, so I believe your figure was correct.

If you're assuming 32-lane video cards (which don't exist yet, as far as I know) then my numbers would be wrong. But with 16-lane cards, each with their own bandwidth, it would indeed be 4 GB/s.

The second option, no doubt. They should display immediately since the risk of tearing would be practically non-existent at normal desktop resolutions. If that became a problem in an app, that's when you would know to switch modes to performance sharing.

Wrong. Suppose that one card is doing ten percent more work than the other one, it's a 55-45 split. Then after 45 time units (for example, to make the numbers round) the faster card finishes, and immediately displays to the screen. After 10 more, the slower card finishes and immediately displays. This pattern continues; at each frame the slower card falls behind 10 time units. If you think this won't cause tearing, I'd like to hear what you think will prevent that.

 

[Al Shades]

Sorry, you were right. My claims were based on a flawed understanding of graphics processors.

 

[Order]

Did you get the drive yet?