Originally Posted by radams01
Sorry wrong group.... I said I was new.. :-)

Originally Posted by radams01
I am new to this site. Unfortunately I only found it when I too started having a problem with my IBM 40 Gig. I have a HPT370 raid controller with Raid-0 stiping with my two Deskstar 40gigs. Well after 10 months of working fine, one drive starts the \"click of death\". It broke my stripe and only one drive appeared in my Raid controller bios. Well after a thorough beating... I was able to get it to revive (for now). It shows up as an active drive again in the raid bios but the stripe is still broken (I guess) as it will not boot. I tried running a Highpoint repair utility (raidrb) that is supposed to \"repair raid-0 and raid-0 +1 broken stripes.
Didn\'t work.
So my question is, before I loose all my data, anyone have any words of wisdom for repairing a broken raid-0 stripe config???

I sent a message to Highpoint tech support but I fear I will not get a timely response - if any at all!
Thanks for any help!

=================
Anonymous Gerbil said;

I have two questions.

1) Exactly how do we know that SIS, ALi and nVidia did a better job on the PCI bus than VIA ? I've only seen tests on VIA and Intel chipsets.

2) Didn't anyone ever try gigabit ethernet on a VIA machine ?!

If you didn't notice this before, and yet you're now swearing off VIA chipsets, then you're an idiot.

Have a nice day !
==================

As far as question one goes; by experience.

I edit video using Matrox's new RT.X100 realtime editing board. This thing can *REALLLY* push the bits through the PCI bus when using multiple video/graphic/effects layers, to the tune of 100 mb/s or even slightly more.

Using a SiS chipped mainboard this is no problem whatsoever. This is reflected by the fact that the ECS K7S5A (SiS 735), K7S6A (SiS 745) Athlon boards and some SiS 645 boards for the P4 are on its *recommended hardware* list. Myself and the other RT.X100 betas found them very easy to configure for the RT.X100 and VERY stable.

OTOH Matrox has blackballed VIA chipsets from their RT.X100 *recommended hardware* list entirely because their limited PCI bandwidth does not allow the RT.X100 to perform many of its most advanced features (realtime MPEG/DV export to HDD or realtime export to IEEE-1394 for example).

I myself tried a Gigabyte GA-7VRX (KT333) board with the RT.X100 and it indeed had these problems.....in mass quantities.

Pretty sad when an el Cheapo mainboard like the K7S5A can beat the living hell out of a VIA based board that costs 3-4 times as much as its paltry $50 USD....

'nuff said.

DocM

Originally Posted by curtdusoleil
I recently upgraded my system with a Soyo Dragon Plus MB, Athlon XP1800+ processor, 512 DDR RAM. The rest of my peripherals are: CD-RW, CD-ROM, Wacom tablet, USB scanner, Voodoo 3 2000 and a second SiS video card, an 80 gig RAID stripe array, 1394 PCI card, and floppy drive. I initially had a 350watt power supply…

Everything was fine until I plugged in my DV camera to the firewire and turned it on. One of a few things happened, but basically it just shuts down the computer. I feel like I’ve tried every possible solution and nothing works. Here’s what I’ve tried…

I swapped the RAM. I tried my RAM on someone else’s computer with the same hardware setup (MB/processor/RAID, etc.) and it worked fine. I swapped the firewire card. I swapped the entire MB/Processor with another of the same. I swapped the HD’s. I reinstalled WinXP clean. I did it with and without the latest MB drivers. I swapped with another 350 watt power supply and finally swapped with a 400 watt power supply. I unplugged the scanner, tablet, and the RAID array. I still get the same problem. Now the camera comes on and is recognized but after about a minute the computer shuts off.

Any ideas because I’m at a loss!

I\'ve been reading some of the posts and if someone could just distill it down for me...what should I do?! The weirdest thing about it is the fact that my friend\'s computer that I built with the Same Soyo Dragon Plus MB with all the same stuff works just fine!

I noticed it quite a while ago -- I even wrote an IBM developerWorks article on how to tweak PCI latency settings in order to solve the problem. I thought it was a problem caused by me turning AGP off, but it was actually due to VIA's flaky PCI implementation: http://www-106.ibm.com/developerworks/library/l-hw2.html

I originally wrote this article in Jan-Feb 2001, so I've been experiencing various problems and known about them for over a year.

--Daniel Robbins
drobbins@gentoo.org

In case nobody has seen this yet, John Gatt from Via Tech Support said on viaarena (http://forums.viaarena.com/messageview.cfm?start=41& catid=6&threadid=5402) that a second patch is on its way.

I guess we will see how comprehensive it is.

-Airbus

--------------------------------------------------------------------------
Wednesday, January 23, 2002 10:51 PM (NEW!)

Re exodious "Is Via working on the issue, will there be a fix? "

We have fixed this and are just testing the 2nd patch.

-------------------------
John Gatt
Web Media Liaison &
Technical Support
VIA Technologies, Inc.
john.gatt@viaarena.com

Ryu did his homework. U the man.

"During a memory read multiple operation, a PCI master will read more than one complete cache line from memory. In this situation, the MCH pre-fetches information from memory in order to provide optimal performance. However, the MCH cannot provide information to the PCI master fast enough. Therefore, the Intel® 82801BA terminates the read cycle early to free up the PCI bus for other PCI masters to claim."

To be exceptionally clearer.

"During a memory read multiple operation"

When a PCI master reads MULTIPLE memory addresses the bandwidth is then and ONLY then limited to 90MB/s. This does not affect writes nor does it affect devices that read a SINGLE memory address (MR).

To take this a step further the errata is detailed as Sustained PCI bandwidth and the reason is this:

http://developer.apple.com/techpubs/hardware/DeviceManagers/pci_srv...

MRM:

"The PCI Memory Read Line or Memory Read Multiple commands perform an eight-beat transaction if the address is aligned to an address less than or equal to 8-bytes less than the next 32-byte boundary. The PCI Memory Read Line and Memory Read Multiple commands are treated the same by the IB chip, in either command case the IB chip disconnects after an eight-beat transaction, which is one 32-byte cache line."

"As mentioned earlier, 132 Mbytes/sec is the maximum theoretical bandwidth across a 32-bit PCI bus at 33 Mhz. Table 1-5 and Table 1-6 show the maximum achievable bandwidth that can be expected, depending on the type of PCI transaction performed. The values shown are not guaranteed, but are realistic ranges that have been measured moving large buffers (many thousands of bytes) to average out PCI arbitration PCI wait states across a Power Macintosh Computer's PCI bus."

PCI master
Read from memory
Bytes per transaction: 32
PCI bandwidth, MB/s: 30
PCI Command: Mem Read line multiple

As you can see what happens is that the MCH proves too slow to provide more than 3 MRM commands in a row to the PCI bus within the ICH. Thus resulting in the PCI bus just saying, "Nevermind. I have other devices that need use of the bus now."

This is a far cry different than the broken PCI arbiter of the VIA chipset, which sends out REQ# every 24 packets. A action which disrupts every current operation on the bus. The VIA bus is not only bandwidth crippled, but too stupid to properly manage it's hosts.

This Intel errata could impact PCI or SCSI controllers, but only on writes, and only if 90MB/s is not enough. That scenario is quite unlikely though.

http://www.tecchannel.de/hardware/817/1.html

You'll notice their IDE test consisted of all reads (writing to memory).

http://www.tecchannel.de/hardware/817/5.html

You'll notice that their SCSI test (which was the real bandwidth beast of the test) consisted of reads and writes. The writes scores (reads from memory) only manages ~32.7MB/s. That's about the value of a single MRM operation.

There is a reason Intel apparently decided to leave this errata un-repaired in later steppings of the i850 and i860; it appears to have no real world impact.

[q]Yeah, too bad Mike was apparently too busy to read the specification sheet. That report is filled with inaccuracies.[/q] "Filled with inaccuracies" how? He gets the major point right - and I'll quote from Intel's doc on the 82850 MCH (the 82860 document reads identically) [i](italics added)[/i]: ftp://download.intel.com/design/chipsets/specupdt/29824704.pdf [q][b]5. Sustained PCI Bandwidth
Problem:[/b] During a memory read multiple operation, a PCI master will read more than one complete cache line from memory. In this situation, the MCH pre-fetches information from memory in order to provide optimal performance. However, the MCH cannot provide information to the PCI master fast enough. Therefore, the Intel® 82801BA terminates the read cycle early to free up the PCI bus for other PCI masters to claim.
[i][b]Implication:[/b] The early termination limits the maximum bandwidth to ~90 MB/s.[/i]
[b]Workaround:[/b] None
[b]Status:[/b] There are no plans to fix this erratum.[/q] Now if you read the other errata, you'll note that the "Implication" line always describes the special circumstances under which the erratum exists. But in this case, it's a very general statement: [b]"The early termination limits the maximum bandwidth to ~90 MB/s."[/b] This will occur every time the PCI bus attempts to transfer multiple cache lines - a common high performance bus master command which Intel recommends using for equal-to or larger-than cacheline reads, or transfers that aren't cacheline-aligned and cross the cacheline boundary (see http://developer.intel.com/design/chipsets/applnots/29222401.pdf). "Memory read multiple" is a very common command and is often aliased to the memory read cycle.

In short, it's a problem that shouldn't be minimized by Intel fanboys.

Just for clarification, IF you have all your IDE devices on the
built-in IDE controller of a KT266A motherboard, will you be
affected with problems copying large files or doing audio/video
playback and editing?

Also, regarding the AMD761 with 686B, does the 686B have
any negative effects? If so, what would they be? From what I've been reading on these threads, the PCI Latency problem
does not affect this combination, but are there other problems
since it uses the VIA 686B?

RYU said: Given the above document and seeing how an arbiter is supposed to work, it's somewhat obvious that one should not have to disable the PCI arbiter in order to improve performance. It's whole point IS to improve performance.

Its not disabling the arbiter, but modifing the arbitration so that the CPU does not get forced the PCI bus. The north bridge has a setting which forces the PCI bus to the CPU, which isn't fair.

[q]I guess I should now run George's test and then try the Promise patch?[/q]

Yeah, I'd grab his HD benchmark utility and try the VIA PRPP. I'd also try George's 0.19 or 0.19a patch. It should also be possible to mix the PRPP with either of George's patches.

PRPP + 0.19

or

PRPP + 0.19a

Albeit mixing that last one (PRPP + 0.19a) would be tricky. As VIA increases the timer of the arbiter and George disables the arbiter. So the order of initialization would have a big effect as to the behavior of the arbiter (off or on).

Since you are on Windows XP and stand a chance of having your drives formatted in NTFS I would suggest making an ERD or a backup (such as a Ghost image) of your install before trying any of the above patches.

And here is my system config prior to swapping controller connections:

Specs: Graphics Workstation
ASUS A7V266-E Rev 1.07 (BIOS 1005e 004).
Athlon XP1800+ @ 1.53GHz
3*256MB TwinMos DDR2100 CL2, 2T command, 4 Bank Int
Creative TNT2 Ultra (2D graphics, no games)
Philips Rythmic Edge on PCI4 (Running on separate IRQ 10)
On standard IDE: (Boot Disk on 0, other 2 on 1)
2*IBM 60GB DeskStar60GXP + IBM 45GB 75GXP
On Promise IDE: (1 on each)
Pioneer 106s DVD/ Creative CDRW
Enermax 350W PSU.
Belkin 4 port USB on PCI 5 (shared with onboard USB IRQ)
Lava Parallel Dual port PCI on PCI 3
Windows XP Professional with all updates
Via 4in1 4.37
Detonator 22.50
PCI Latency 0

Yes, I too have bought a new sound card assuming Creative's SBLive was to blame (and was about to replace the TNT2 thinking it caused my infinite loops - now gone with my current set up).

One thing that's been my salvation in all this is ConfigSafe from www.imaginelan.com . It allows me to view the registry and file changes after installing drivers and then lets me roll back the registry to prior working states, great for recovering from flaky drivers. Without it I would certainly have had to rebuild my system on more than one occasion.

Brian

Ryu

Thanks for the speedy answers.

It appears that many users like myself have been unable to get their boot drives to work at DMA 5 on the Via controllers (always showing as PIO mode instead despite being recognised by the BIOS).

Here are the unscientific scores on the Via setup:

Copy times for 106MB of files are:
IDE0 Master Boot: 100, 30 then 60 secs (with pauses during transfer)
IDE1 Master (UDMA5): 14 secs
IDE1 Slave (UDMA4): 20 secs

and now on the Promise:

Copy times for 106MB of files are:
Promise0 Master Boot: 12 secs
Promies1 Master (UDMA5): 12 secs
Promise1 Slave (UDMA4): 18 secs

PLUS: My sound problems have gone away. It used to stutter as I was logging in to my profile (due to PCI/ disk problems I'd assumed)

I've finally given up and moved all the drives back to the Promise controllers which is why I'm especially sad to hear that the arbiter problem wouldn't have affected me on the Via controllers if I could ever have got them to work.

I guess I should now run George's test and then try the Promise patch?

Thanks
Brian

[q]Is VIA the only one with a flawed PCI implementation? Read this...[/q]

Yeah, too bad Mike was apparently too busy to read the specification sheet. That report is filled with inaccuracies. Me telling you that the sky is actually pink would adequately parallel the truth within his "report."

[q]So here's a simple question which I hope someone can help with:

What will give me the best IDE performance on my Asus A7V266e with onboard Promise RAID:

a) Using the Via IDE or the onboard Promise IDE?
b) Using Via Miniport IDE, George's patch or Via's Promise patch or a combination?[/q]

You would have to test that for yourself. George offers a free HD testing too. It's real small and it's a single .exe.

[q]Does the Promise patch work for single IDE usage on onbaord controllers?[/q]

Single IDE usage on the Promise controllers, yes. Single IDE usage on the on-board VIA IDE controllers, no. In fact that latter use VLink and so are not hampered by the broken PCI arbiter.

[q]I'm using 3 drives (2 UDMA100, 1 UDMA66), but currently my master drive (on VIA IDE0 on its own) is running like a dog in PIO mode even though the other drives are recognised as DMA 4 and 5 on IDE1.[/q]

Sounds like you have all your hard drives on the VIA IDE controllers. The broken PCI arbiter will not impact your performance.

[q]Thank/q]

Welcome.

So here's a simple question which I hope someone can help with:

What will give me the best IDE performance on my Asus A7V266e with onboard Promise RAID:

a) Using the Via IDE or the onboard Promise IDE?
b) Using Via Miniport IDE, George's patch or Via's Promise patch or a combination?

Does the Promise patch work for single IDE usage on onbaord controllers?

I'm using 3 drives (2 UDMA100, 1 UDMA66), but currently my master drive (on VIA IDE0 on its own) is running like a dog in PIO mode even though the other drives are recognised as DMA 4 and 5 on IDE1.

(i'm running XP with 4in1 4.37)

Thanks

<a href="http://www.theinquirer.net/17010203.htm">Is VIA the only one with a flawed PCI implementation? Read this...</A>

[q]Would this patch apply to an Asus A7M266 board with a Promise Raid card?[/q]

No. The AMD 761 Northbridge controls the PCI bus. All the 686B provides is APM, I/O, and Legacy support.

Originally Posted by TomT
Would this patch apply to an Asus A7M266 board with a Promise Raid card? This is a hybrid chipset board, and it gets confusing as to which via patches/drivers to use.

Thanks

it would be interesting to see a test to check the PCI implementation on the SIS735-based motherboards such
as the K7S5A to confirm whether or not it too has such a problem.

I don't get what this arguing goes for, but there is only one fact that is absolute. VIA boards have problems with their PCI bus, REGARDLESS of their board manufacturers. Only some are more focused on the design so that their customers at the end face less problems.

Just because of problems with PCI and AGP buses, I have changed a sound card and a graphic card, spending $s that do not rain from heaven but earned by hard work.

Imagine, you are a rookie and do not know anything about hardware. Just because you had a pentium computer in the past, you know how to use windows and dos. What do you expect from a new computer? You expect your computer to work efficiently, right?
Then you realize there is a performance problem in your pc, also your SB live card that you have spent lots of dollars results in an audio quality failure. You change the soundcard with a new one, and buy a new graphic card because of the AGP port and color problems, and at the end you realize that all was because of your via board.
When you finally believe that you have solved all of your problems, you wonder on your overall performance and apply a benchmark. You realize that your memory performance is awful related to the same branch intel products and your UDMA settings do not work well. Spending days and nights, by applying many patches, changing configurations you become an experienced user from a rookie one, at the cost of some sleep, and hair loss because of stress.
Im sick of manuals, forums, hardware settings, hours spent on trial and error configuration settings.
Well, i do not care if it is the pci arbitration or pci latency. This goddamn thing is not working! How can one have UDMA 33 performance better than UDMA 66 performance? With the money i have spent on AGP card and the new sound card, i could have changed the board, but i was not aware that they were board problems. Everyone had blamed creative, so did I.

Why do the VIA poduce these boards if only experienced users will be able to use them? I purchased it for home use. This is not rocket science, but it seems that i better should have studied it in order to solve my configuration problems.

#81

check out the multitude of linx ryu provided :)

Personally, when moving from a PIII abit bh6 mobo (intel bx chipset) I was NOT ready to deal with via's problems. Yes, they ARE problems. I read a ton about mobo solutions and the ECS k7s5a (sis 735) is by FAR the best solution out there. It is only LESS than 5% slower than the 266a and it has absolutely NO problems with the pci bus (or otherwise, for that matter...now. :) ).

The one thing that will put SiS chipsets over the top with hardcore users is companies like abit, asus, etc putting out mobo's with all the overclocking features that the 266a boards out there have (pci/ram/proc fsb separation, 1 mhz fsb increments, etc etc). If they don't do that, yes people are going to settle for a buggy via solution, and that's a shame. Someone mentioned that via was 0/8 with their mobo's and I think they are right.

On another note, I'm using a herc fortissimo II sound card, because though the via thing isn't creative's problem, they have problems of their own. (driver updates, anyone? ;) )

I have two questions.

1) Exactly how do we know that SIS, ALi and nVidia did a better job on the PCI bus than VIA ? I've only seen tests on VIA and Intel chipsets.

2) Didn't anyone ever try gigabit ethernet on a VIA machine ?!

If you didn't notice this before, and yet you're now swearing off VIA chipsets, then you're an idiot.

Have a nice day !

Ehh.. Ryu.. i mean of course

One of the things we can do is make informed opinions by the sources we have to go on.. but absolute proof is very hard to come buy. If youre trying to be against another persons informed opinion you should at least have some informed opposites of why.

Its sound very much like the PCI arbiter is broken by what we have to go on, and it also depends how you define broken. But yes,,, it doesnt work as it should is what seems to be the case.

If you want absolute proof server on a plate.. go elsewhere
If you want to try to think for yourselves, stay if you want to.

cheers

ps. damn ruy, that was really longwinded.. not that it wasnt needed or good. ;) ds.

Originally Posted by kamwai
hi, i have benchmarked my RAID 0 array using 2 x 40 GB Maxtor D740X on my MSI K7T266 Pro RU motherboard

if you are interested, take a look at http://www.reviewmakers.com/showdoc.php?article=6&pg=1

for my benchmark results, there is a significant improvement after the patch.

#75, I'm in agreement with you, except nowhere did I state that I thought Ryu was right, I was just saying that everyone has a right to their own opinion and they should not be criticized if their opinion does not match with another person's.

It seems people read way too much into the posts on this board!

http://www.viahardware.com

[q]Oh - and while I'm typing, George Breese let me know he's beta testing a new patch addressing the problems with poor RAID performance on VIA chipsets. This patch disables the PCI Arbitration Timer and you can get it at George's site. Report what it does for you in the comments for this news post - don't forget to mention your motherboard and the impact the patch has on other peripherals such as sound cards.[/q]

Just read about what an arbiter does.

http://www.actel.com/docs/datasheets/arbiter.pdf

Based on Sergui's explanation of the PCI's bus behavior, the assumption that the arbiter is broken is very likely fact.

Document:

[q]At any given time, more than one PCI bus initiator (Master)
device may request use of the PCI bus by asserting its specific request signal (REQn).[/q]

[q]The Arbiter determines which PCI bus initiator controls the PCI bus by asserting that device’s specific grant signal (GNTn).[/q]

Serguei:

[q][i]And one more remark... While reading article at German site, I have noticed that on many graphs from PCI analyzer short bursts were not interrupted by STOP# signal, they were stopped my master, i.e. by PCI card itself. It seems that main reason for this is deasserted GNT# signal.

On one graph from Intel chipset it is clearly visible that GNT# is asserted all the time, so PCI master will not interrupt transaction even if its latency timer expires. In contrast, on VIA chipset the GNT# signal is very short, so the card terminates the transaction when its latency timer expires, according to PCI specifications. I observed the same behavior on my Soyo Dragon Plus motherboard using just simple oscilloscope when trying to capture video with PCI card.

So, it seems that motherboard or VIA chips have something sending request signal REQ# all the time! Well, at least, it looks like that...[/q][/i]

I suppose since he has to use a oscilliscope as- opposed to watching the die, to determine what is happening on the bus one might like to wash it away as coincidence. George's recent performance results with his beta patch with the arbiter disabled would seem to confirm that by removing the arbiter from the equation the bus performs and behaves as it should. Given the above document and seeing how an arbiter is supposed to work, it's somewhat obvious that one should not have to disable the PCI arbiter in order to improve performance. It's whole point IS to improve performance.

#72,
Ryu didn't prove anything at all, all he did was to form a conclusion based on comments in another forum. And if we evaluate this comments then we may form other conclusions, such as: VIA's pci implementation is different, but not out of spec, and other manufacturers' been using Intel's implementation as reference. The best Ryu did point out was that the pci lantency may be set too low.

To be honest, the most credible source Ryu linked to is George Breese's, and he say the pci arbitor MAY be broken.

There is a lot of inference going on here, and Ryu may turn out to be right, but to say he is definitely right I can not agree with.

CingKrab.

Rumor holds that the Sis 745 is going to be a hit. Expect to see boards from big names like Asus and Abit.
---
Excellent; just the kind of names I was after. MSI and Gigabyte wouldn't hurt too :) *rubs hands*