[q]whats with all this VIA defending?[/q]Well, Gerbil #55/56/57 (all the same Gerbil, from the timestamps), I'm not so much VIA-defending as pointing out that it's not just a VIA problem, and that the worst fault seems to fall on Creative instead.

All three VIA-chipset boxes I've built were without a hint of a problem; OTOH I had one Intel mobo which hung/BSOD'd on four different copies of a Creative card, and a replacement mobo did exactly the same thing. The Intel box ran stock, while one of the three VIA boxes was moderately overclocked. On one present Intel board (OC'd), my SB Live! absolutely sucks, while my other Intel mobo likes my old SB AWE 32 just fine.

I understand your frustration, but you have to realize that many VIA users don't have a problem, and many Intel (and other) chipset users do... which is what I keep pointing out.

"I think they're both at fault, but I have to put Creative more at fault than VIA. After all, the VIA chipsets have the problem with Creative soundcards, specifically the SB Live! series -- and not much else. If it were truly a "Darth VIA" issus, there'd be more problems than there are. "

no no no no no no my SB-16 does the same thing - on two different Via boards (fried the first on in desperation during Bios update (to try to ride the "crackle/pop"). The newer Via is better (about half the crack/pop), but still dismal. My old Intel TX? chipset (socket-7) was a real champ! - no "crackle/pop" sound at all.

#35 - "True, but the SBLive isn't some small potatoe card. This is a $300 professional audio card that runs in 24/96 and has nothing but coax, RCA, and TOS-Link connectors on the back. Shouldn't have VIA done better quality assurance with the SBLive! before releasing their product? "

Danm right they should have. Hell my SB-16 "snap/crackles/pops" two VIA boards later!! ;-(. I just "live with it"

"Bare minimum if they didn't want to fix the problem they could have included a warning. "

F^&kin A they should have - thats why I will NEVER buy Via agian - regardless of how "great" this new kx266 chipset is. I'm going Sis-735 or similar. Bye-bye Via !!!!!!!!! ;-)

#34 "This alone seems to remove it from a pure-VIA-hardware issue, doesn't it? The drivers (which are rolled into WinXP) are critical here...

Further: This problem can sometimes be fixed by "George's Latency Fix," by removing ACPI, by increasing core or I/O voltage, and by replacing the IDE controller -- in addition to updating the 4-in-1 drivers or implementing the VIA beta fix. There are also Northbridge register fixes, some of which are included in "George's" fix. All of these point to a PCI timing/latency issue! The fact that sometimes all it took was a sharing or ACPI change supports this. "

Gee thats sure sounds like an easy patch. I cant wait to go buy myself another VIA board and do those 10? easy "patches" "toubleshooting" crap. ;-(.

no thanks - I'll buy a board that works - out of the box. no "patches" to fix stuff that shouldn't need fixing in the first place!

As for OSes: I dont want XP and don't intend to ever use it, so with the VIA I'm forced to use this OS, since a bugfix (which has no bussness to even exist) is not offerd under Linux/win98??

whats with all this VIA defending?

#17 - Invar mask grill??? is that like shadowmask? non-trinitron. I.E. dots not bars??? if so I agree - CAD is alot better in this type of tude.

Originally Posted by LocalYokel
I used to be a SCSI bigot. All it left me with was puny disks, and several hundred more dollars out of my pocket, not to mention that it wasn\'t \"future proof\". Two years ago, there wasn\'t a new UW-SCSI disk to be found -- the world had switched to Ultra2, and I was locked out. When it came time to upgrade, IDE had changed. The disk space limitations had lifted, UDMA was in effek, and the price gap between IDE and SCSI had shot well up over the 1/2.5 I was willing to deal with.
...

sync for Win32 is available here:
http://www.sysinternals.com/ntw2k/source/misc.shtml#Sync

Originally Posted by Prototype II
LocalYokel #45,

ESR happens to be a software developer, and as such, the stresses his system gets are of the pattern exercised by a compiler. Compilers tend to build large in-memory data structures, and for a large software project, their libraries, objects and large symbol tables are loaded from disk, and are not likely to stay in disk buffers for long. Additionally, the essentially random accesses that a compile requests cannot be preftched efficiently, and so the cache\'s locality of reference assumption falls down, so caches aren\'t very useful in such a case, so low access times are quite important.

(I see this day in, day out at work. Our older machines came with SCSI drives which are now two generations old, but with processors that are about half as fast as the middle-of-the-road processors our newer machines use. Our newer machines come with 7200 rpm ATA drives instead of the 7200 rpm SCSI drives in the older ones.

During daily compiles of our project (approximately 300MB worth), the machines with the faster I/O subsystem easily win out. The amount of RAM is the same. The motherboards are similar (440BX-based). The processors are slower (but have more cache).

AG #48 - In Linux it's called 'sync'. Forces all buffers pending to be written to disk. Not foolproof, though, and I don't know what the NT equivilent is.

I've used high-perf SCSI and IDE drives from just about every manufacturer out there and I can tell you that SCSI is worth the extra bit of cash -- but it may not be worth it if you're not beating up on the file system all the time (as you would be if you're doing large image manipulation, serving, etc.)

Personally, I'd have nothing else. SCSI machines tend to be slightly more stable than IDE boxes. Plus, the build of the drives is usually better...as is the warranty, etc. You're getting a lot more for the money than you think.

---k (#43), I understand that. I'm not dissin' OCers; in fact, this box I'm writing on is a 133FSB BX dualie, with CuMines OCed from 600 to 800...

My point is that a problem related to a fast PCI bus will be made worse by running it overspeed (which you'll do with every mobo, until you hit the next divider) -- especially if the PCI implementation is less than robust to begin with. The fact that VIA isn't seeing the problem with the frequency it's being reported from the field suggests that there's something being added in the field, and we know for a fact that overclocking is one such added factor.

Forge, Is there a utility that can be used for "Flushing a bunch of cache down to disk..."? One thing that is really annoying about removable storage on WinNT is that NT never seems to be willing to let ZIP and MO disks be removed without complaining about lost buffers.

Mr Bill

Aye. Which is why I groan whenever my roommate shuts down her box with the 5400 rpm drive in it, only to turn it back on later. Loading programs is a #%@$& . . . I won't bore you with the stuff, you know it all.

Interesting thing is, I had a few extra sticks of ram lying around, so I dropped 'em in; everything is lightning fast as long as it doesn't touch the hard drive. Once I do, I can get a cup of coffee and the thing will still be cranking away.

Good question. I think it's because a lot of things change directly on the disc (I know the cache is bypassable from programspace), and quite a lot of people still regularly use programs that won't fit just in free ram. For example, I can run around all in disk cache, and never touch real I/O, as long as I don't do any big compiles and I don't fire up Quake3 or Tribes2. On the other hand, when I do those things, the system used to start panting, as I was: A. Loading Tribes2. and B. Flushing a bunch of cache down to disk to free the ram it was using.

It kinda makes sense. I would just trust that it does work that way, not get a headache trying to figure out why.

Originally Posted by LocalYokel
Actually, now that I\'m thinking about this...

Memory is still much faster than these disks, and you\'re supposed to get enough RAM that you mostly work out of the cache -- so what the hell is the point of a high performance I/O system that\'s going to be almost completely idle between startup and shutdown?

Originally Posted by LocalYokel
The buckling spring keyboards are also lest common because they\'re significantly more expensive to manufacture. It\'s much easier to lay a couple strips of bubble mesh than it is to lay >100 individual springs.

Originally Posted by ---k
Twofer, real overclockers test their systems thoroughly after tweaking. I would say that after all their stability tests and burns-ins, the overclocked systems will be as stable as a non-oc\'ed system. It\'s the amateurs that will settle with an unstable system just to eek out the last mhz.

[q]That's an odd statement, since virtually every one of the audio buffs I know (or have read, for that matter) think the Live! really sucks -- it's posing as a high-end card, but all the good parts are in things like coax and connectors... the meat of the card is still pretty low-end. And check your stats: the SB Live! is definitely not "24/96"![/q]

That was a typo. It should have read.

True, but the SBLive isn't some small potatoe card. This is [bot[/b] a $300 professional audio card that runs in 24/96 and has nothing but coax, RCA, and TOS-Link connectors on the back.

In short it is not a small niche market card. It (the SBLive) should have been the first in line to be tested.

[q]I think they're both at fault, but I have to put Creative more at fault than VIA. After all, the VIA chipsets have the problem with Creative soundcards, specifically the SB Live! series -- and not much else. If it were truly a "Darth VIA" issus, there'd be more problems than there are.[/q]

I think the problem is the VIA chipsets as they have the problem with the SBLive and no other chipsets share those issues (in this case data corruption). If it were truly the SBLive's fault it would happen on more chipsets and there would be more problems than there are.

:)

I think the point of it being gray is that you can't assign anymore blame one place than the other.

[q]Look also at Forge's post #39 -- I think much of the variance is also Creative's, and VIA could well have tested their stuff on a "good" card (most likely, if it were sent as an engineering sample). Forge also points out what I've heard from numerous sources: the Live! cards cause problems with many different chipsets.[/q]

And I have two VIA motherboards you could squeeze and get lemon juice out of. Marginal products exists.

[q]Also note that many of the people having problems are the overclockers, who by preference tend to use VIA boards and also do things which inarguably degrade stability; I think this also has a lot to do with the problem showing up on VIA chipsets -- it's selective data set, and not representative.[/q]

Hmm. Hmm. I don't feel I can really argue that one way or another. That feels really intangible. You make an interesting point, but I can't concede that as fact. It is an educated generalization at best.

[q]So whose more at fault? Creative for making noisy hardware or VIA for running too close to the edge?[/q] I think they're both at fault, but I have to put Creative more at fault than VIA. After all, the VIA chipsets have the problem with Creative soundcards, specifically the SB Live! series -- and not much else. If it were truly a "Darth VIA" issus, there'd be more problems than there are.

Look also at Forge's post #39 -- I think much of the variance is also Creative's, and VIA could well have tested their stuff on a "good" card (most likely, if it were sent as an engineering sample). Forge also points out what I've heard from numerous sources: the Live! cards cause problems with many different chipsets.

Also note that many of the people having problems are the overclockers, who by preference tend to use VIA boards and also do things which inarguably degrade stability; I think this also has a lot to do with the problem showing up on VIA chipsets -- it's selective data set, and not representative. [q]True, but the SBLive isn't some small potatoe card. This is a $300 professional audio card that runs in 24/96 and has nothing but coax, RCA, and TOS-Link connectors on the back.[/q] That's an odd statement, since virtually every one of the audio buffs I know (or have read, for that matter) think the Live! really sucks -- it's posing as a high-end card, but all the good parts are in things like coax and connectors... the meat of the card is still pretty low-end. And check your stats: the SB Live! is definitely [iot[/i] "24/96"!

TT #38 - I bought one for LAN use and had to return it. I couldn't work on it, there was almost *no* feedback. Imagine waving your fingers above a desk with keys drawn on it. YMMV, of course.

Wow. The ULB is creepily similar to my own machine, with the major subs. of IDE instead of SCSI, and my addition of a TV Tuner. I have 4 optical drives and no DDS, but the core system is like 90% the same. I think ESR got raped on the case, though. Mine was 250$ and is argueably one of the best on the market. WTX ownz, and stuff.

Worth noting:

I have an SBLive and a Live5.1 here that can run in my 760MP, my KT133, my KT133A, an Apollo 133A, and a BX with zero issues. I have another vanilla Live here that tanks *every single one* of the noted systems, in various vague, hard-to-reproduce ways. Based on the few dozen Lives I've had to work with, I'd say the problem is very much Creative's at heart, and it appears to be a combined design/QC issue. All Lives seem to be poor neighbors on the PCI bus, but some are good enough to run on any system, including several KT133As with 686bs, while others are bad enough to tank even a 440BX with disturbing regularity. Also worth noting is this: The 'bad apple' Live, which has crashed dozens of systems and has fried one mobo, was returned to me by Creative. Their verdict? 'the unit was tested and found to be in perfect working order. All tested noise margins and interference levels were within [Creative's] standards for this model'. Sounds like Creative either knows and doesn't care that their card is a bad neighbor, or maybe they just need to really tighten what an 'acceptable standard' is.

Originally Posted by Trident Troll
Anybody tried one of those floppy, foldable keyboards?
What are those like?
---

LONG LIVE TRIDENT!!!

--k: re: tactile keyboards: in a word, yes. While most wrist-related RSI are caused by improper posture, the finger-related RSI's are mainly caused by the shock of keystrokes (I know, I can't use the IBM keyboards for extended times). In addition, the amount of strength required to activate a heavy-click keyboard can aggrevate tendonitis in the fingers, the hands, and the wrists (actually, they're mostly the same tendons, just inflammations can happen at different points). That's about it, simplified.

Originally Posted by ---k
I\'m curious to know why tactile feedback keyboards have gone out of style. Could RSI be the cause?

[q]I'm talking about the data corruption and hardlock issue.

From WiNC's FAQ at http://www.viahardware.com/686bfaq.shtm , discussing the VIA 686b "data corruption" problem:
This fault has only been reported with the following OS’s – Windows 95, 98, 98SE, ME, NT, and 2000, and there are some reported cases of it happening with Linux based OS systems also, with a few reports about the same with FreeBSD. Windows XP is not known to have this issue.
This alone seems to remove it from a pure-VIA-hardware issue, doesn't it? The drivers (which are rolled into WinXP) are critical here...[/q]

No. As XP has been in development long enough for their driver fix to have been built into the OS.

[q]Further: This problem can sometimes be fixed by "George's Latency Fix," by removing ACPI, by increasing core or I/O voltage, and by replacing the IDE controller -- in addition to updating the 4-in-1 drivers or implementing the VIA beta fix. There are also Northbridge register fixes, some of which are included in "George's" fix. All of these point to a PCI timing/latency issue! The fact that sometimes all it took was a sharing or ACPI change supports this.[/q]

Aye, the very first WCUPID fix for the problem set it up where you disabled PCI 2.1 compliance among other things. As I've stated before the issue is not named correctly. It was a bug that existed between the PCI controller (the KT133A) and the 686B (which controls I/O functions including the onboard IDE).

Futzing with the KT133A northbridge or not using the IDE controllers in the SouthBridge would resolve the issue. This is why AMD760 + 686B users don't face the corruption issue.

I see your point and it is elegantly put, but we've already been down the path of conceeding the issue is gray. I'm not going to blame just Creative for the issue. Especially when it was the KT133A + 686B combo together, which exhibited the issue.

[q]I think the crackling/popping is just the leading edge of the problem, and that increased "abuse" of the bus will cause data corruption and/or hardlocks. And since each board is different, the level of the problem will be different on each board.[/q]

Reasonable conclusion. Going for the gray again, the popping and crackling and bus hogging show that Creative hasn't done something right. On the other hand Intel, AMD, SiS, ALI, and VIA have had more chipsets than I think I can count on my hands come out since the introduction of the SBLive. Only one company has had very serious issues. Perhaps two depending on how widespread this 760 hardlock issue is.

[q]That's not exactly what I said: what I'm proposing is that VIA runs a bit closer to the edge than some other chipset manufacturers -- either with their lowlevel drivers or with the hardware (or both) -- and therefore sees the problems early. Creative happens to be excellent at producing the problems, because their hardware is very noisy over the PCI bus.[/q]

Okay. So whose more at fault? Creative for making noisy hardware or VIA for running too close to the edge?

[q]But someone always has the bottom slot, and without the SB to bring them out I think very few people would have had problems with the VIA chipset.[/q]

True, but the SBLive isn't some small potatoe card. This is a $300 professional audio card that runs in 24/96 and has nothing but coax, RCA, and TOS-Link connectors on the back. Shouldn't have VIA done better quality assurance with the SBLive! before releasing their product?

Bare minimum if they didn't want to fix the problem they could have included a warning.

[q]VIA hasn't ignored this: see http://www.viaarena.com/?PageID=26 for some of what they've done.[/q]

Yes, I also noted they didn't test SoundFonts. Hmm, I wonder why. . . . .

And with the VIA support staff saying things like this:

http://www.viaarena.com/?PageID=3&faq=5&Search=NT

[q]Category:
AGP

Question:
Does VIA have an AGP driver that supports Win NT 4.0?

Answer:
No because Win NT 4.0 does not support AGP. AGP requires support for Direct X instructions and will only add this support into Win NT 5.0. An AGP card is functional on Win NT 4.0 but only in 2D mode.[/q]

I don't have a lot of faith in their technicians either. Can anybody else see the gross incorrectness of that statement?

[q]Note that the 4-in-1's have to be installed both before and after the Creative drivers -- I think this step is missed by many people who can't solve their problems.[/q]

Really? Why? This should only be necessary if the Creative drivers are overwriting the VIA ones.

[q]Also note that a true fix requires a BIOS update, which is apparently beyond the capabilities or desires of at least some mobo manufacturers.[/q]

As I interpeted the fix was not necessary in the BIOS. That was even stated in the article you just referenced.

[q]The engineers had to work out a way to filter this noise and released a patch to motherboard manufacturers which replicates a BIOS change. A roll on effect of things happened with some manufacturers incorporating the patch, or making the necessary change to their BIOS and VIA also released the patch as part of the 4in1 drivers. This patch only gets installed when it detects a Sound Blaster Live!, so many motherboard manufacturers have chosen not to fix the issue in BIOS, in order to get the best performance out of their BIOS, if you are not using a Sound Blaster Live!. Creative at this stage also fixed the issue with a new revision of the Sound Blaster Live! called the Sound Blaster Live! 5.1. So using a 5.1, I can go back to the original BIOS with no issues. All newer BIOS do require the 4in1 patch.[/q]

[q]And finally, note that some of Creative's bundleware still causes problems -- which I think isn't exactly VIA's fault.[/q]

Granted Creative software problems are Creative's fault.

[q]I'll be the first to admit that VIA has some problems, but I stop short at saying that they are the only ones, or that Creative doesn't deserve a large part of the blame.[/q]

I think we've been in agreement on that since square one.

I'm talking about the data corruption and hardlock issue.

From WiNC's FAQ at http://www.viahardware.com/686bfaq.shtm , discussing the VIA 686b "data corruption" problem:[q]This fault has only been reported with the following OS’s – Windows 95, 98, 98SE, ME, NT, and 2000, and there are some reported cases of it happening with Linux based OS systems also, with a few reports about the same with FreeBSD. Windows XP is not known to have this issue.[/q] This alone seems to remove it from a pure-VIA-hardware issue, doesn't it? The drivers (which are rolled into WinXP) are critical here...

Further: This problem can sometimes be fixed by "George's Latency Fix," by removing ACPI, by increasing core or I/O voltage, and by replacing the IDE controller -- in addition to updating the 4-in-1 drivers or implementing the VIA beta fix. There are also Northbridge register fixes, some of which are included in "George's" fix. All of these point to a PCI timing/latency issue! The fact that sometimes all it took [i]wa/i] a sharing or ACPI change supports this.

I think the crackling/popping is just the leading edge of the problem, and that increased "abuse" of the bus will cause data corruption and/or hardlocks. And since each board is different, the level of the problem will be different on each board.

[q]Are you proposing that VIA hasn't yet mastered how to allow the PCI bus and its specification to have some leeway?[/q] That's not exactly what I said: what I'm proposing is that VIA runs a bit closer to the edge than some other chipset manufacturers -- either with their lowlevel drivers or with the hardware (or both) -- and therefore sees the problems early. Creative happens to be excellent at producing the problems, because their hardware is very noisy over the PCI bus.

But [iomeon/i] always has the bottom slot, and without the SB to bring them out I think very few people would have had problems with the VIA chipset.

VIA hasn't ignored this: see http://www.viaarena.com/?PageID=26 for some of what they've done. Note that the 4-in-1's have to be installed both before and after the Creative drivers -- I think this step is missed by many people who can't solve their problems. Also note that a true fix requires a BIOS update, which is apparently beyond the capabilities or desires of at least some mobo manufacturers. And finally, note that some of Creative's bundleware still causes problems -- which I think isn't exactly VIA's fault.

I'll be the first to admit that VIA has some problems, but I stop short at saying that they are the only ones, or that Creative [ioesn't[/i] deserve a large part of the blame.

[q]They (VIA) are either too close to specification, not close enough, or not tolerant enough of devices that misbehave.[/q]

Uh, well, that pretty much covers it, doesn't it?

[qome can get rid of it by dicking with the PCI timing or sharing...[/q]

The popping and crackling or this hardlock issue?

[q]It sounds the same to me.[/q]

I think it depends on the severity. Disabling sharing or ACPI isn't exactly something that one should have to do, but it's a painless fix.

The 686B data corruption bug took more than that to correct. And this SoundFont issue still doesn't have an answer.

If this hardlock issue on the 760 series happens in Windows and Linux and can't always be fixed by disabling ACPI or PCI sharing though. Then I had best grab my down with Darth Creative sign and start picketing.

[q]The only reason why it's a greater problem with VIA chipsets is that they didn't raise their PCI bar quite as high -- and the Creative problems show up earlier/worse than with most other chipsets. The fact that the problem is sporadic points to the same thing: it's the natural variation in quality which takes some 'boards over the edge.[/q]

Are you proposing that VIA hasn't yet mastered how to allow the PCI bus and its specification to have some leeway?

As that's the impression I get. They (VIA) are either too close to specification, not close enough, or not tolerant enough of devices that misbehave.

Oops, lemme post the whole thing:

Ryu, explain how the VIA problem is different? Not everyone has it, and some can get rid of it by dicking with the PCI timing or sharing...

It sounds the same to me.

The only reason why it's a greater problem with VIA chipsets is that they didn't raise their PCI bar quite as high -- and the Creative problems show up earlier/worse than with most other chipsets. The fact that the problem is sporadic points to the same thing: it's the natural variation in quality which takes some 'boards over the edge.

some can get rid of it by dicking with the PCI timing or sharing...

It sounds the same to me.

The only reason why it's a greater problem with VIA chipsets is that they didn't raise their PCI bar quite as high -- and the Creative problems show up earlier/worse than with most other chipsets. The fact that the problem is sporadic points to the same thing: it's the natural variation in quality which takes some 'boards over the edge.

[q]It appears to be a PCI-bus issue (as I said), and it's clearly the same sort of beast on this AMD chipset as on the VIA chipset.

I'm waiting in line... ;)[/q]

They corrected the issue by removing PCI sharing. WiNC was able to get rid of popping and crackling by disabling ACPI.

It means the hardware is not very sharing friendly, but I know network adapters, video cards, and even other sound cards that exhibit the same poor behavior.

This further proves that Creative can't adhere to the PCI spec worth a damn. It doesn't explain VIA's difficulty though.