In defense of the ALi MAGiK 1 chipset, at least it doesn't have the PCI bus problems that VIA does. I own an Iwill XP-333 motherboard, and I can soundly say that it is by far the best, most stable and compatible motherboard I have every owned, and I think it performs quite well. In fact, it's "inferior" memory controller spanks my friend's ECS K7S5A (SiS 735 chipset) using the same processor and RAM. The "C" revision of the ALi chipset in the Iwill motherboard is a lot better than the original version, which is what most people refer to when they speak negatively of ALi (either that or they remember the Super Socket-7 days and the AGP problems with the Aladdin V chipset).
So, in short, the Iwill XP-333 is a highly recommended non-VIA motherboard that doesn't cost too much. The ECS K7S5A is a nice board as well, but I prefer the Iwill, mainly because it's made of higher quality components, not to mention it overclocks like a dream.
By the way, if you do any music creation, I have found that the ALi chipset works beautifully with Creative Labs sound cards--none of the crackling sound problems usually associated with VIA chipsets will be found here
So, in short, the Iwill XP-333 is a highly recommended non-VIA motherboard that doesn't cost too much. The ECS K7S5A is a nice board as well, but I prefer the Iwill, mainly because it's made of higher quality components, not to mention it overclocks like a dream.
By the way, if you do any music creation, I have found that the ALi chipset works beautifully with Creative Labs sound cards--none of the crackling sound problems usually associated with VIA chipsets will be found here
Well duh, here we go again ...
THERE IS NO SUCH THING AS A PCI PERFORMANCE PROBLEM IN VIA CHIPSET HARDWARE.
It's mainboard BIOSes that fail to set the VIA chipset registers up in a way that allows good PCI performance. It can be done, on any VIA chipset down to the very first ones, as demonstrated by various BIOSes out there, not to mention VIA's own "PCI performance patch" driver for those left alone by their BIOS makers.
And ever since the DDR RAM chipsets, VIA doesn't connect the south bridge on the PCI bus anymore.
ALi Magik-1 RAM controller being faster than SiS 735? Man, you really need to check on your spectacles. Rose tinted?
Creative sound cards "crackling"? That's a PCI bug IN THE SOUNDCARD. Tis an SB!Live, innit?
THERE IS NO SUCH THING AS A PCI PERFORMANCE PROBLEM IN VIA CHIPSET HARDWARE.
It's mainboard BIOSes that fail to set the VIA chipset registers up in a way that allows good PCI performance. It can be done, on any VIA chipset down to the very first ones, as demonstrated by various BIOSes out there, not to mention VIA's own "PCI performance patch" driver for those left alone by their BIOS makers.
And ever since the DDR RAM chipsets, VIA doesn't connect the south bridge on the PCI bus anymore.
ALi Magik-1 RAM controller being faster than SiS 735? Man, you really need to check on your spectacles. Rose tinted?
Creative sound cards "crackling"? That's a PCI bug IN THE SOUNDCARD. Tis an SB!Live, innit?
rbV5
Lifer
- Dec 10, 2000
- 12,632
- 0
- 0
He said that the southbridge is connected through the same PCI bus the slots are on, I understand that. I don't understand how that relates to a "Huge Bottleneck". In what way will that actually hamper my rigs performance? Where would I see it?
I agree that ALi could have a bit faster memory controller out of the box, but tweaking the registers with WPCREDIT and setting them with WPCSET gives me a respectable 2300 MB/s @ 178 FSB, definately comparable to about any AMD solution, and plenty of bandwidth to feed my TBred.
Do the math: The IDE channels in the southbridge alone require more bandwidth than the PCI bus has total. Now what if you have a PCI card that requires some serious bandwidth? You'll already see media streams disturbed by IDE activity when you're doing something simple like feeding from PCI TV card to AGP, or when using an advanced sound card.
What about the fact that VIA chipsets do not comply with Intel's recommendations regarding PCI bus parking, thereby reducing overall PCI bandwidth? What about the fact that swapping out a VIA board for an ALi board removed my sound crackles immediately, even though no other system components had changed? What about all the other people who have experienced the same problem?
This merely adjusts the PCI latency, which doesn't fix the root of the problem; it just masks it.
I understand this is a bottleneck; I'm not denying that. However, the benefits of the ALi chipset far outweigh the negatives for me.
Hmm... I wasn't wearing any glasses when I looked at the numbers in SiSoft Sandra 2002...
Iwill XP-333 (ALi MAGiK 1 rev. C): 1956/1787 MB/s
ECS K7S5A (SiS 735): 1676/1608 MB/s
On both boards, the RAM was set to "Ultra" timing mode, using CAS 2.5 latency, and the ECS board was set to use a fast slew rating for the RAM. Both boards are also equipped with one 256 MB stick of PC2100 DDR RAM, running an Athlon XP 1600+ at stock speeds (133 MHz FSB). The tests were run multiple times in both normal and safe mode using SiSoft Sandra 2002 on Windows 98SE.
I have tried both the SB-Live! and Audigy in this board without problems.
Just because a drive supports ATA133 does not mean it will achieve anywhere near that transfer rate. In fact, most drives can only transfer between 20 MB and 40 MB per second peak. If I'm recording a digital waveform to harddisk, it's only using a small fraction of that possible bandwidth. The reason that IDE activity interrupts other things has more to do with the design of the IDE controller than anything (try a SCSI device and you'll see). It's the same reason the floppy controller can bring the fastest system to a temporary standstill. The PC architecture is outdated in many ways.
rbV5
Lifer
- Dec 10, 2000
- 12,632
- 0
- 0
Exactly, check my rig specs:
*Promise FastTrak Ultra ATA PCI card, WD 200 GB and Maxtor 60 GB..in fact 6 IDE devices, all Masters on their own seperate Channel's including onboard RAID.
*MyHD HDTV PCI tuner/capture card
*SBlaster Live 5.1
*NIC
I capture full resolution ATSC High Defination 1080i streams without dropping frames
I capture full NTSC resolution AVI without dropping frames
I have no issues with my SBlaster
I can watch HDTV and NTSC TV simultaneous, in seperate windows, on my desktop
Sandra scores around 31000 with the WD, 25000 with the Maxtor and 47000 with the Maxtor RAID0 array, all NTFS (these are the highest scores on any rig I've had) They all 3 max HDtach and score high on PCMARK
Do the math all you want, the IWILL ALi implementation has excellent IDE and PCI throughoutput in "real use" on my rig, and has for over a year that I've used it. Let me know how to exploit its weaknesses, and I'll check it out, otherwise, I can't imagine how you would stress the PCI bus more than my rig does at times.
Always great fun ... now let's see if you can teach a BIOS engineer something new ...
>What about the fact that VIA chipsets do not comply with Intel's recommendations regarding PCI bus >parking, thereby reducing overall PCI bandwidth?
PCI isn't Intel's thing. There's a specification for it. Bus parking is an OPTIONAL feature. Implementing it gives and takes bandwidth. With parking you get zero or two clocks arbitration latency, depending on who requests the bus; w/o parking it's always one cycle. Many PCI bridge devices and less mainstream chipsets (as seen in servers mostly) don't implement it either. Not an issue if the PCI controller doesn't have it.
The problems seen here have actually been a PCI compliance issue in certain cards that couldn't cope with the Idle state of the PCI bus (which never happens when the chipset keeps the bus parked somewhere). Of course it was Creative again; their official statement was "We test with Intel chipsets, use those. We don't care whether it works elsewhere." (my synopsis)
Bus parking doesn't do anything for the overall throughput anyway. The key is balancing allowed burst length against arbitration fairness. This balance can be adjusted in VIA chipsets. And that's what VIA's PCI performance patch does - program the chipset's PCI controller to what VIA determined are the best performing settings (since for a long time, many BIOSes didn't). Not just ...
>This merely adjusts the PCI latency, which doesn't fix the root of the problem; it just masks it.
Which of course is plain wrong. Even more so because your guess about the root cause was wrong too ...
>Just because a drive supports ATA133 does not mean it will achieve anywhere near that transfer rate. >In fact, most drives can only transfer between 20 MB and 40 MB per second peak.
Current IDE drives reach up beyond 60 MB/s. One of them potentially eats half of your PCI bandwidth. The picture is no different with SCSI, just the interrupt load is lower.
>What about the fact that swapping out a VIA board for an ALi board removed my sound crackles immediately
That's because the PCI signal timing bug (not the bus parking bug) in the SB!Live shows with VIA and SiS chipsets, and doesn't with Intel or ALi. No news here.
You measure memory performance in Sandra? ROTFL. Boot to DOS to eliminate Windows from the equation, then use something to the iron, like CACHEMEM.EXE.
I'm bored now. Good night.
Peter
>What about the fact that VIA chipsets do not comply with Intel's recommendations regarding PCI bus >parking, thereby reducing overall PCI bandwidth?
PCI isn't Intel's thing. There's a specification for it. Bus parking is an OPTIONAL feature. Implementing it gives and takes bandwidth. With parking you get zero or two clocks arbitration latency, depending on who requests the bus; w/o parking it's always one cycle. Many PCI bridge devices and less mainstream chipsets (as seen in servers mostly) don't implement it either. Not an issue if the PCI controller doesn't have it.
The problems seen here have actually been a PCI compliance issue in certain cards that couldn't cope with the Idle state of the PCI bus (which never happens when the chipset keeps the bus parked somewhere). Of course it was Creative again; their official statement was "We test with Intel chipsets, use those. We don't care whether it works elsewhere." (my synopsis)
Bus parking doesn't do anything for the overall throughput anyway. The key is balancing allowed burst length against arbitration fairness. This balance can be adjusted in VIA chipsets. And that's what VIA's PCI performance patch does - program the chipset's PCI controller to what VIA determined are the best performing settings (since for a long time, many BIOSes didn't). Not just ...
>This merely adjusts the PCI latency, which doesn't fix the root of the problem; it just masks it.
Which of course is plain wrong. Even more so because your guess about the root cause was wrong too ...
>Just because a drive supports ATA133 does not mean it will achieve anywhere near that transfer rate. >In fact, most drives can only transfer between 20 MB and 40 MB per second peak.
Current IDE drives reach up beyond 60 MB/s. One of them potentially eats half of your PCI bandwidth. The picture is no different with SCSI, just the interrupt load is lower.
>What about the fact that swapping out a VIA board for an ALi board removed my sound crackles immediately
That's because the PCI signal timing bug (not the bus parking bug) in the SB!Live shows with VIA and SiS chipsets, and doesn't with Intel or ALi. No news here.
You measure memory performance in Sandra? ROTFL. Boot to DOS to eliminate Windows from the equation, then use something to the iron, like CACHEMEM.EXE.
I'm bored now. Good night.
Peter
Well, since I do all my work in Windows, not DOS, I am more concerned with how the memory performs in Windows. By the way, the best scores were achieved using safe mode, which eliminates most processes that could interfere with achieving an accurate reading.
Intel designed the PCI bus, didn't they? Regardless, I was basing my statements about PCI bus parking off of information that I had read before that seemed pretty credible. However, it is possible that this information was wrong.
Hmmm... interesting. I didn't know the problem existed with SiS chipsets too. The only time my friend had sound crackling problems with his ECS K7S5A was because he was using a PCI graphics card. It crackled with either the onboard sound, or a SB-Live! whenever there was heavy graphical activity (especially while playing a movie). Using an AGP graphics card solved the problem. I'm curious now; I should try that PCI graphics card in my system and see what happens.
This is not true. The ALi southbridge supports ATA-133. Maybe I'm just bad at math, but how does this exceed the PCI bus bandwidth of 133 MB/s? ATA-133 means that the controller can support up to 133 MB/s, not that each drive gets 133 MB/s (133 x 4 = 532 MB/s, far more than even VIA's V-Link can provide).
Ah, I see we're getting somewhere.
>Well, since I do all my work in Windows, not DOS, I am more concerned with how the memory performs in Windows.
You still got a multitasking OS interfering. If you really want to measure latencies and throughput and see accurate numbers, use DOS and CACHEMEM.
>Intel designed the PCI bus, didn't they?
Not really. They initiated its development, but multiple companies (the "Steering Group") were and still are actively developping the standard(s). www.pcisig.com is the place where it all happens.
>Regardless, I was basing my statements about PCI bus parking off of information that I had read before that seemed pretty credible. However, it is possible that this information was wrong.
Yes, there's been plenty inaccurate or even plain wrong guesswork in the press - most of it following VIA's announcement that they're going to implement bus parking to make those buggy cards work anyway. It's a niceness move from VIA to make users happy although the actual fault lies elsewhere, yet still it's been misinterpreted as VIA confessing that they've been lacking something important. Bashing VIA is just too darn tempting, it seems. (Same story as with the original SB!Live bug that still is widely attributed to the VIA 686B south bridge ...)
>Hmmm... interesting. I didn't know the problem existed with SiS chipsets too. The only time my friend had sound crackling problems with his ECS K7S5A was because he was using a PCI graphics card.
The latter problem is PCI bus bandwidth hitting the ceiling, not related to said SB!Live bug. What happens if you plug an SB!Live (original series, the 5.1 series had that fixed) into an SiS chipset mainboard, most of them will plain hang upon booting Windows. YMMV - it's a timing issue, actual results differ from mainboard to mainboard.
>This is not true. The ALi southbridge supports ATA-133. Maybe I'm just bad at math, but how does this exceed the PCI bus bandwidth of 133 MB/s?
Well you got two independent IDE channels there, that's 266 MB/s in my flavor of math ... besides, there's other stuff in the south bridge (USB, sound, power management, ISA bridge to frequently accessed legacy I/O like the system interrupt controller, system timers, keyboard, mouse, floppy, COM and LPT ports) that also needs some bandwidth. All taken together, there's much less left for PCI cards than on chipsets that don't have the south bridge on PCI.
VIA V-Link btw has been stepped up to 533 MB/s for the 8235 south bridge, SiS MuTIOL is at 1 GB/s already (963 south bridge). Basically everyone has made the move away from using 32-bit 33 MHz PCI as the system backbone, except ALi and ATi (mainly because they use ALi and older VIA south bridges). Intel uses their own HubLink, AMD uses twin PCI busses (66 MHz north-south, and 33 MHz behind the south) and will use HyperTransport on K8, NVidia uses HT already.
regards, Peter
>Well, since I do all my work in Windows, not DOS, I am more concerned with how the memory performs in Windows.
You still got a multitasking OS interfering. If you really want to measure latencies and throughput and see accurate numbers, use DOS and CACHEMEM.
>Intel designed the PCI bus, didn't they?
Not really. They initiated its development, but multiple companies (the "Steering Group") were and still are actively developping the standard(s). www.pcisig.com is the place where it all happens.
>Regardless, I was basing my statements about PCI bus parking off of information that I had read before that seemed pretty credible. However, it is possible that this information was wrong.
Yes, there's been plenty inaccurate or even plain wrong guesswork in the press - most of it following VIA's announcement that they're going to implement bus parking to make those buggy cards work anyway. It's a niceness move from VIA to make users happy although the actual fault lies elsewhere, yet still it's been misinterpreted as VIA confessing that they've been lacking something important. Bashing VIA is just too darn tempting, it seems. (Same story as with the original SB!Live bug that still is widely attributed to the VIA 686B south bridge ...)
>Hmmm... interesting. I didn't know the problem existed with SiS chipsets too. The only time my friend had sound crackling problems with his ECS K7S5A was because he was using a PCI graphics card.
The latter problem is PCI bus bandwidth hitting the ceiling, not related to said SB!Live bug. What happens if you plug an SB!Live (original series, the 5.1 series had that fixed) into an SiS chipset mainboard, most of them will plain hang upon booting Windows. YMMV - it's a timing issue, actual results differ from mainboard to mainboard.
>This is not true. The ALi southbridge supports ATA-133. Maybe I'm just bad at math, but how does this exceed the PCI bus bandwidth of 133 MB/s?
Well you got two independent IDE channels there, that's 266 MB/s in my flavor of math ... besides, there's other stuff in the south bridge (USB, sound, power management, ISA bridge to frequently accessed legacy I/O like the system interrupt controller, system timers, keyboard, mouse, floppy, COM and LPT ports) that also needs some bandwidth. All taken together, there's much less left for PCI cards than on chipsets that don't have the south bridge on PCI.
VIA V-Link btw has been stepped up to 533 MB/s for the 8235 south bridge, SiS MuTIOL is at 1 GB/s already (963 south bridge). Basically everyone has made the move away from using 32-bit 33 MHz PCI as the system backbone, except ALi and ATi (mainly because they use ALi and older VIA south bridges). Intel uses their own HubLink, AMD uses twin PCI busses (66 MHz north-south, and 33 MHz behind the south) and will use HyperTransport on K8, NVidia uses HT already.
regards, Peter
i need to steer this back in the right direction, how is the abit nf7-s? does it have optical out?
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter