Re: USB-2, NTFS, Audio, Reliability
- From: "Soundhaspriority" <nowhere@xxxxxxxxxxx>
- Date: Sun, 19 Apr 2009 23:40:48 -0400
"Frank Stearns" <franks.pacifier.com@xxxxxxxxxxxx> wrote in message
news:DeudnX0O8_57RnbUnZ2dnUVZ_hednZ2d@xxxxxxxxxxxxxxxxxxxxxxxxxx
As time goes by, and the terabytes mount up, I'm getting
rather suspicious of USB-2 and NTFS (windows) file systems.
Spread over three computers, dozens of drives (SATA for use
with the DAW; IDE for use with the recorder), a couple of
external USB-2 housings, I keep getting annoying, random
errors at random intervals... Things such as a very short
burst of white noise in a wav file that was clean
originally; another few corrupted wav or fade files that
cause Protools to choke upon load (but all was well six
months ago); the occasional CD Architech file that now
claims it's not a CD arch file when it used to work just
fine; etc.
This only happens with something probably less than 0.001%
of the total byte count of data that's stored here, and I
can normally recover from a backup somewhere, but this
seems ridiculous and annoying. I sure as hell don't
remember UNIX or VAX/VMS systems doing this kind of thing,
but maybe the data sets just weren't large enough.
The common denominator seems to be USB, as the corruptions
tend to show up in files that have been moved via USB from,
say, an active drive to an archive drive.
The general user experience does not suggest that USB is unreliable. All USB
packets are error checked by CRC (cyclical redundancy check). Unlike
Firewire, USB control is software based. The Windows drivers are very
stable, having been out there for years. However, a defective motherboard
southbridge could inject noise into a usb connection.
But I've alsoI see something a little odd on network accesses. I have been speculating it
seen NTFS misbehave and entire sets of files disappear then
reappear, sometimes on a refresh, sometimes only on a
reboot, and sometimes simply by moving through the folder
trees with explorer, even after multiple refreshes failed.
has something to do with the antivirus company I switched to, BitDefender.
On a network access, it can take more than a minute for an apparently empty
folder to display contents. There is never any data loss. It could also be
that the XP scheduler for more than two cores is not optimal. I have two
quad core machines here and two dual cores, and the dual cores actually seem
more responsive at the GUI level.
To copy files I generally use drag and drop via two XP
explorer windows; this supposedly automatically turns on
read-after-write verification,
I never heard of this feature. As far as I know, there is no automatic
read-after-write verification in XP, unless a command line utility is used.
Perhaps you are thinking of disc burning?
but perhaps I should onlyIt should be able to.
use xcopy in the CMD window after having manually set
verify to ON. Perhaps verify-after-write is disabled across
USB connections (Windows trying to be "helpful" by
"speeding up" operations across a slower disk connection.)
I occasionally do other things with the system during such
transfers, perhaps foolishly believing that a quad-core
machine running XP SP3 can walk and chew gum at the same
time.
Frank, it's obviously impossible to do more than speculate. However, I will
These are on fairly new, tweaked XP machines ("tweaked"
meaning they're not running a bunch of extraneous junk and
are favoring audio production).
I probably don't need to hear about Linux or the Mac; I'd run one of
the real UNIX machines running real UNIX if I could (and
did, once upon a time, in another life), but commodity
machines have put us where we are; that's the reality. I'm
looking for work-arounds.
tell you this is why I use only ECC memory in my machines. Since you are an
oldtimer, you are probably more aware than others that electrical noise in
computers follows a Gaussian model. Computers can't be divided
simplistically into machines that work, and machines that don't. In every
computer, there is a sea of noise sloshing around, as well as cosmic rays
that flip memory cells.
A company called Intel decided that servers had to have ECC memory, but
because the work of an individual was the loss of only one person, Intel
decreed that a consumer desktop doesn't need ECC. They took ECC support
completely out of the I7, requiring purchase of the Xeon 5500 equivalent at
6X the price if ECC is required. In marketing terms, this is Intel's
strategy for segmentation of the marketplace, something I disagree with,
because when my computer flips a bit, I don't give a damn about the other 99
people.
AMD has consistently made ECC available to the masses, so I chose slower AMD
processors, the Phenom II 940, and the peace of mind that my Asus 790FX
based motherboards actually have IBM's patented "chipkill feature", meaning
that even if a DRAM dies on the run, the machine just keeps going like
nothing happened.
But getting back to the issue of pure noise margins, the faster you go, the
higher the equivalent Gaussian noise power in the machine, and the greater
the chance of a freak wave flipping a bit. Underclock the machine, and the
reverse is true. "Speed kills" was never more true than with computers.
My experience with quad cores under XP is that they can behave oddly, but
never destructively. You may still have a bad component, a bad hard disk, or
a bad motherboard, or bad memory, yet the oddness of the way quad cores act
and feel may have obscured this to you. So I suggest, ignore the oddness,
and come to a certain conclusion about possible defective hardware. You may
wish to consider underclocking as a noise diagnostic.
Mostly curious about any patterns you've seen, assumingI'm happy with my AMD 790FX quadcores. Populated with relatively slow ECC
you've had similar problems.
Thanks in advance,
Frank Stearns
Mobile Audio
--
667 memory, they have inspired confidence. The only oddness I have noted is
a delay in proper display of network folders, but it always comes.
Good luck hunting,
Bob Morein
(310) 237-6511
.
- Follow-Ups:
- Re: USB-2, NTFS, Audio, Reliability
- From: Frank Stearns
- Re: USB-2, NTFS, Audio, Reliability
- References:
- USB-2, NTFS, Audio, Reliability
- From: Frank Stearns
- USB-2, NTFS, Audio, Reliability
- Prev by Date: USB-2, NTFS, Audio, Reliability
- Next by Date: Re: USB-2, NTFS, Audio, Reliability
- Previous by thread: USB-2, NTFS, Audio, Reliability
- Next by thread: Re: USB-2, NTFS, Audio, Reliability
- Index(es):