Would a dual core processor help me with this?

[Don]

Periodically I have to refresh a couple of databases by copying a
stack of DVDs to a harddrive. One susbscription consists of 10 DVDs
and the other 6, so there is no way this can be made to run at night.
The computer to which these DVDs are being copied has the following
specs: AMD Athlon 3000, 786 ram, IDE harddrives and DVD drive, DMA
enabled on all drives, Windows XP SP2. The hard drive to which the
data is copied is NOT the one from which the programs run. It is way
more than fast enough at all times except when this data is being
copied -- at which time it becomes so painfully slow as to be almost
useless. The programs I run are all business apps none of them
cutting edge enough to be written for a dual-core processor.

Would a dual-core (my choice in processors has always been AMD) setup
make:
1. A theoretical difference but not really noticeable to the user?
2. A noticeable difference?
3. A spectacular difference?

My concern is not so much to reduce the copy time as it is to be able
to keep using the box when UPS bring a stack of DVDs.

Don
www.donsautomotive.com

 

[Darren Bremner]

Seems the only reason for the machine to be slow is not enough RAM.

 

[yuenkitmun]

My guess is it's not a processor bottleneck.

Run Windows Performance monitor to see what is going on. Compar
before copying and during copying. Chec

- percentage processor tim
- percentage disk time for each hard disk (programs and DVD database
- page faults / secon

I don't have XP with me now but on win2k performance monitor is unde
control panel / administrative tools / performanc

 

[The little lost angel]

Would a dual-core (my choice in processors has always been AMD) setup
make:
1. A theoretical difference but not really noticeable to the user?
2. A noticeable difference?
3. A spectacular difference?

It would likely help based on my limited experience with
Hyperthreading (Intel's cheap version of dual core before dual core
came around). I get program stutters/freeze when large amount of data
is copied suddenly (i.e. when a large download completes and get
shifted from temp folder on one drive to final destination on other
drive). However, for a brief period of time I was on a HT P4 machine,
this did not affect the other programs. Once I went back to a
non-Hyperthreading single core A64, the problem came back again.

While I've not empirically investigated this issue, I'm highly
inclined to believe that having a second virtual core helped as one
core is stalled on the disk transfer, the other can still do work.
I've no idea why this happens since in theory, DMA is supposed to use
very little CPU power.

 

[George Macdonald]

Periodically I have to refresh a couple of databases by copying a
stack of DVDs to a harddrive. One susbscription consists of 10 DVDs
and the other 6, so there is no way this can be made to run at night.
The computer to which these DVDs are being copied has the following
specs: AMD Athlon 3000, 786 ram, IDE harddrives and DVD drive, DMA
enabled on all drives, Windows XP SP2. The hard drive to which the
data is copied is NOT the one from which the programs run. It is way
more than fast enough at all times except when this data is being
copied -- at which time it becomes so painfully slow as to be almost
useless. The programs I run are all business apps none of them
cutting edge enough to be written for a dual-core processor.

Would a dual-core (my choice in processors has always been AMD) setup
make:
1. A theoretical difference but not really noticeable to the user?
2. A noticeable difference?
3. A spectacular difference?

My concern is not so much to reduce the copy time as it is to be able
to keep using the box when UPS bring a stack of DVDs.

If you're about to buy a new system anyway, a dual CPU is definitely the
way to go for general computing work load; if that's an Athlon64 you have
and the mbrd supports dual CPU, then you have a decision to make. I'm
not sure it's going to make a huge improvement with your problem here
though. Have you run any diags to see what is going on?... get Process
Explorer from www.sysinternals.com to check on CPU usage and other activity
during the job; use HDTach from
http://www.simplisoftware.com/Public/index.php to check HD speed and CPU
usage during HD I/O.

Have you checked in device manager that the HD and DVD really are connected
in the fastest, low CPU usage, UDMA mode? Once Windows decides that UDMA
has glitched it drops out of that mode... *permanently*. Check the cluster
size on your HDD - AFAIK a "convert" to NTFS makes it 512 bytes which is
just awful for what you are doing; the recommended size is 2048 bytes IIRC.
Is the HDD clean and defragged before you start the copy? When folders and
files are being deleted/recreated, Windows makes a real mess of directory
structures very quickly so a large copy like that will tend to bog down as
it progresses.

It's not clear what generation of system you have, but the newer systems
bypass the PCI Bus for transfers to/from the DVD and HDDs so that might be
enough to mitigate your problem, dual CPU or no... but I'd get the dual
anyway.

 

[Tony Hill]

Periodically I have to refresh a couple of databases by copying a
stack of DVDs to a harddrive. One susbscription consists of 10 DVDs
and the other 6, so there is no way this can be made to run at night.
The computer to which these DVDs are being copied has the following
specs: AMD Athlon 3000, 786 ram, IDE harddrives and DVD drive, DMA
enabled on all drives, Windows XP SP2. The hard drive to which the
data is copied is NOT the one from which the programs run. It is way
more than fast enough at all times except when this data is being
copied -- at which time it becomes so painfully slow as to be almost
useless. The programs I run are all business apps none of them
cutting edge enough to be written for a dual-core processor.

Would a dual-core (my choice in processors has always been AMD) setup
make:
1. A theoretical difference but not really noticeable to the user?
2. A noticeable difference?
3. A spectacular difference?

My concern is not so much to reduce the copy time as it is to be able
to keep using the box when UPS bring a stack of DVDs.

I would throw out a guess that you would probably be at about the
"noticeable difference" level if you were to go from an Athlon64 3000+
to something like an Athlon64 X2 3800+. Dual core should definitely
help keep the system more responsive and usable when copying these
DVDs. That being said though, you're probably also going to be
running into some memory limitations in addition to processor
limitations, hence the reason why you probably wouldn't see a really
spectacular difference.

Of course, if you've currently got an AthlonXP 3000+ instead of the
newer Athlon64 3000+, then the difference may well be spectacular.
Going from the AthlonXP up to an Athlon64 X2 not only would get you
dual cores, but also each core would be faster individually AND you
would be getting more memory bandwidth and lower latency. Even going
from a Socket 754 Athlon64 3000+ to a Socket 939 Athlon64 X2 3800+
should help on the memory front, though not by nearly as much as the
jump from an AthlonXP chip.

 

[Don]

I would throw out a guess that you would probably be at about the
"noticeable difference" level if you were to go from an Athlon64 3000+
to something like an Athlon64 X2 3800+.

That's what I am looking at. It seems by far the best value. I can
get one at Fry's as a combo with a probably worthless MB for $289.00
at one of their periodic promotions. Ironically it is hard to find it
that cheap without the crap ECS MB.

Dual core should definitely
help keep the system more responsive and usable when copying these
DVDs. That being said though, you're probably also going to be
running into some memory limitations in addition to processor
limitations, hence the reason why you probably wouldn't see a really
spectacular difference.

Of course, if you've currently got an AthlonXP 3000+

That's what it is -- obsolete 32 bit! And its 100% adquate for
Quickbooks, Word, Excel, e-mail, web access and my auto repair
databases -- which are AllData and Mitchell. Just sucks when UPS
brings the quarterly AllData or Mitchell DVD packages. It would be
interesting to see what dual-core does for the computer when remote
controlled with NetOp, but that's actually surprisingly brisk already.

instead of the newer Athlon64 3000+, then the difference may well be spectacular.

Talked me into it! Thanks for what sounds like a very knowledgable
reply.

Don
www.donsautomotive.com

 

[nobody]

Periodically I have to refresh a couple of databases by copying a
stack of DVDs to a harddrive. One susbscription consists of 10 DVDs
and the other 6, so there is no way this can be made to run at night.
The computer to which these DVDs are being copied has the following
specs: AMD Athlon 3000, 786 ram, IDE harddrives and DVD drive, DMA
enabled on all drives, Windows XP SP2. The hard drive to which the
data is copied is NOT the one from which the programs run. It is way
more than fast enough at all times except when this data is being
copied -- at which time it becomes so painfully slow as to be almost
useless. The programs I run are all business apps none of them
cutting edge enough to be written for a dual-core processor.

Would a dual-core (my choice in processors has always been AMD) setup
make:
1. A theoretical difference but not really noticeable to the user?
2. A noticeable difference?
3. A spectacular difference?

My concern is not so much to reduce the copy time as it is to be able
to keep using the box when UPS bring a stack of DVDs.

Don
www.donsautomotive.com

Dual core will make a noticeable difference, but probably somewhat
short of spectacular. Some heavy HDD activities slow down my dual
Opteron rig noticeably, even though CPU load stays fairly low. SCSI
drive(s) probably will make an impact as big as A64X2, if not even
bigger (for the task). Ever thought why servers with heavy I/O load
such as database are all SCSI? It's up to you though to decide if
this investment makes sense to you because SCSI, especially a RAID
config (RAID controller + 3 drives min. for data + separate system
drive) will cost you more than A64X2, even high end one.

NNN

 

[George Macdonald]

Dual core will make a noticeable difference, but probably somewhat
short of spectacular. Some heavy HDD activities slow down my dual
Opteron rig noticeably, even though CPU load stays fairly low. SCSI
drive(s) probably will make an impact as big as A64X2, if not even
bigger (for the task). Ever thought why servers with heavy I/O load
such as database are all SCSI? It's up to you though to decide if
this investment makes sense to you because SCSI, especially a RAID
config (RAID controller + 3 drives min. for data + separate system
drive) will cost you more than A64X2, even high end one.

Is this SCSI advantage still true vs. a modern SATA-II system? I'm talking
about comparable spin & platter speeds for the drives - not the 15000rpm
SCSI jobs. In fact if the SCSI has to run off a PCI Bus card, vs. a PCI-X
one, I'd think the SATA-II, which usually has the controller integrated
into the chipset internal paths, thus bypassing PCI, would be a hands down
winner.

 

[nobody]

Is this SCSI advantage still true vs. a modern SATA-II system? I'm talking
about comparable spin & platter speeds for the drives - not the 15000rpm
SCSI jobs. In fact if the SCSI has to run off a PCI Bus card, vs. a PCI-X
one, I'd think the SATA-II, which usually has the controller integrated
into the chipset internal paths, thus bypassing PCI, would be a hands down
winner.

One of the cases when my system loses most of its responsiveness is
when Symantec antivirus (10 Corp.) loads the def update. The Task
Manager CPU load icon goes only a hair above idle (not a surprise - it
is a dual Opteron after all!), and there are hundreds of megs of free
RAM available. The only heavy activity is HDD - SATA (not II though)
7200rpm 8mb cache Hitachi. Maybe it's because VIA SATA controller
sucks, or just because such are all non-SCSI drives. But since such
moments are very few and far between, and usually last only a few
seconds, I see no justification to go SCSI. If something regularly
slowed down my system for hours every time, as it is the case with OP,
I'd give SCSI a serious consideration, even though my motherboard is
not equipped with PCI-X or even PCIe, and as you mentioned PCI based
SCSI controllers take away a good part of SCSI advantage.

NNN

 

[George Macdonald]

One of the cases when my system loses most of its responsiveness is
when Symantec antivirus (10 Corp.) loads the def update. The Task
Manager CPU load icon goes only a hair above idle (not a surprise - it
is a dual Opteron after all!), and there are hundreds of megs of free
RAM available. The only heavy activity is HDD - SATA (not II though)
7200rpm 8mb cache Hitachi. Maybe it's because VIA SATA controller
sucks, or just because such are all non-SCSI drives. But since such
moments are very few and far between, and usually last only a few
seconds, I see no justification to go SCSI. If something regularly
slowed down my system for hours every time, as it is the case with OP,
I'd give SCSI a serious consideration, even though my motherboard is
not equipped with PCI-X or even PCIe, and as you mentioned PCI based
SCSI controllers take away a good part of SCSI advantage.

So what is it about SCSI that is better which makes it the choice? I tend
to think blame for your unreponsiveness during Symantec AV update is shared
mainly between M$ and Symantec. Try a full system scan with Symantec AV
and you won't see the same unreponsive behavior if you have the default
(low) priority set for the scan. Of course it could be that Symantec sees
AV defn update as an urgent, necessarily higher priority task. Personally
I'm in utter digust with Symantec and they will not see one more single red
cent from me.:-(

 

[nobody]

So what is it about SCSI that is better which makes it the choice? I tend
to think blame for your unreponsiveness during Symantec AV update is shared
mainly between M$ and Symantec. Try a full system scan with Symantec AV
and you won't see the same unreponsive behavior if you have the default
(low) priority set for the scan. Of course it could be that Symantec sees
AV defn update as an urgent, necessarily higher priority task. Personally
I'm in utter digust with Symantec and they will not see one more single red
cent from me.:-(

Not being an expert in the theory of computer architecture, I know
that when the hard drive becomes the main bottleneck the solution is
SCSI (or one of SCSI RAID configs). As for Symantec AV, I usually
install whatever is required by my current employer to VPN in. Most
of the time it is Symantec Corporate AV (whatever release is current -
went from 7 to 10). Only once it was McAfee. But hey, it was
provided to me for free, and it does its job, so a few seconds of low
responsiveness is not that bad a price. And the corporate version
seems to never expire - updates keep coming for free.

NNN

 

[Tony Hill]

Is this SCSI advantage still true vs. a modern SATA-II system? I'm talking
about comparable spin & platter speeds for the drives - not the 15000rpm
SCSI jobs. In fact if the SCSI has to run off a PCI Bus card, vs. a PCI-X
one, I'd think the SATA-II, which usually has the controller integrated
into the chipset internal paths, thus bypassing PCI, would be a hands down
winner.

As usual, it depends. The performance characteristics of SCSI vs.
SATA drives are somewhat different, and not just because of the
interface used. SCSI drives tend to be designed and tuned for
different types of disk access relative to SATA drives. As a result,
some things will be faster on a comparable SCSI drive and some things
will be slower. Generally speaking, lots of small and random accesses
will favor SCSI, lots of larger linear accesses will favor SATA.

In the case of the original poster, he's going to be doing mostly
large linear disk access, so SCSI would be a total waste of money.
Chances are that it would end up being slower than bog-standard SATA
disks unless you go for a 15Krpm RAID array, and even then the
difference will be rather unimpressive.

A much better speedup could probably occur simply by having a second
SATA drive and using that for the data files while loading the OS and
all program files and basically everything that is NOT related to the
disk backup onto the first drive. Actually I can't remember now, but
I think the original poster might have said that he already has such a
setup.


FWIW if you're interested in a more in-depth comparison of IDE vs.
SCSI, check out www.storagereview.com. They have research this sort
of stuff numerous times over the year and have got a fairly good
handle on where one does better than the other.

 

[George Macdonald]

Not being an expert in the theory of computer architecture, I know
that when the hard drive becomes the main bottleneck the solution is
SCSI (or one of SCSI RAID configs).

In a server or workstation with multiple simultaneous tasks that was
generally the case - it may still be if you count the 15,000 RPM drives but
ATA/SATA has come a long way and for the usual drives most of us use, I
don't see what advantage SCSI could possibly have.

As for Symantec AV, I usually
install whatever is required by my current employer to VPN in. Most
of the time it is Symantec Corporate AV (whatever release is current -
went from 7 to 10). Only once it was McAfee. But hey, it was
provided to me for free, and it does its job, so a few seconds of low
responsiveness is not that bad a price. And the corporate version
seems to never expire - updates keep coming for free.

I believe corporate IT is supposed to handle the annual corporate
subscription payments for AV defn updates. My beef with them is that it
breaks several parts of the underlying mechanisms of the documented Windows
API, the most noticable being network DDE... and their lack of warranty
(fitness for use if you like) and bug fixes is a disgrace. Bottom line:
they sell software which does not work, they will not supply fixes without
registering and then jumping through hoops -- and preferably some extra $$.
The day you buy it you're supposed to sign up for "Gold Insurance" to
ensure some kind of functionality.

 

[George Macdonald]

As usual, it depends. The performance characteristics of SCSI vs.
SATA drives are somewhat different, and not just because of the
interface used. SCSI drives tend to be designed and tuned for
different types of disk access relative to SATA drives. As a result,
some things will be faster on a comparable SCSI drive and some things
will be slower. Generally speaking, lots of small and random accesses
will favor SCSI, lots of larger linear accesses will favor SATA.

Uh, my question was more rhetorical than may have appeared. With the
NCQ of SATA-II, SCSI has lost some more of its advantage, though I'm not
sure how the two queues differ in length and characteristics. If you add
in the by-passing of PCI in integrated SATA-II controllers, I think SCSI
starts to look even less attractive for even a small server system...
though it seems that some folks are finding it (SATA-II NCQ) a bugger to
get working with controller/disk incompatibilities.

In the case of the original poster, he's going to be doing mostly
large linear disk access, so SCSI would be a total waste of money.
Chances are that it would end up being slower than bog-standard SATA
disks unless you go for a 15Krpm RAID array, and even then the
difference will be rather unimpressive.

A much better speedup could probably occur simply by having a second
SATA drive and using that for the data files while loading the OS and
all program files and basically everything that is NOT related to the
disk backup onto the first drive. Actually I can't remember now, but
I think the original poster might have said that he already has such a
setup.

Some of the slowness he's experienced could be due to the M$ file system -
if NTFS (assuming he used it) is not set up right you can get lots of
churning; also the WinXP defrag is a bit of a dog in some situations. I
wish he'd given more detailed info.

 

[Nate Edel]

So what is it about SCSI that is better which makes it the choice?

As a bus, it beats SATA2 marginally (320MBytes/sec vs 300) and allows for
multiple drives per channel (and continues to with SAS, through expanders).

As a protocol, I'm not sure if the command queueing in SATA2 has caught up
with SCSI or not; the NCQ implementation through SATA1 drives was definitely
less powerful than the SCSI implementation.

As for controllers, and this is not inherent to SCSI itself, they tend to do
a lot more offload from the processor. This can actually be disadvantageous
for raw bandwidth given how fast processor speeds are, but can be a big
advantage in terms of random access/transaction processing performance. This
is not as big an advantage with say a $150 Adaptec board or similar (or the
motherboard-integrated SCSI chips); also, many of the hardware RAID
SATA/SATA2 solutions (like 3ware sort of thing) have equally powerful
offload abilities to comparably priced SCSI solutions.

Also, in an earlier post, you mentioned "not counting 15k rpm sorts of
things" but of course that's part of the picture; for serious TP workloads,
those make a huge difference and as far as I know are still only available
for SCSI (though there's nothing inherent in that, just marketing - there's
little advantage for home users and a lot higher cost/lower capacity.)

 

[Nate Edel]

Not being an expert in the theory of computer architecture, I know
that when the hard drive becomes the main bottleneck the solution is
SCSI (or one of SCSI RAID configs).

That was more a clear "accepted wisdom" up to the widespread adoption of
SATA RAID; these days, it can be a bit hazier. Even then, there has always
been a big difference between bottlenecks based on raw bandwidth or random
access latency. The first is a lot easier to fix throwing more drives at a
problem, and there's little reason today with SATA RAID to use SCSI for it.

 

[Don]

Uh, my question was more rhetorical than may have appeared. With the
NCQ of SATA-II, SCSI has lost some more of its advantage, though I'm not
sure how the two queues differ in length and characteristics. If you add
in the by-passing of PCI in integrated SATA-II controllers, I think SCSI
starts to look even less attractive for even a small server system...
though it seems that some folks are finding it (SATA-II NCQ) a bugger to
get working with controller/disk incompatibilities.

Not SATA, but otherwise yes, that is how it is arranged.

Some of the slowness he's experienced could be due to the M$ file system -
if NTFS (assuming he used it) is not set up right you can get lots of
churning; also the WinXP defrag is a bit of a dog in some situations. I
wish he'd given more detailed info.

Sorry abut that! Yes the drive dedicated to all the data copied from
DVDs is NTFS. The drive is ide DMA 6, NOT sata. I just checked it
and it was pretty fragmented, but the data is read off the drive by
both programs with no noticeable delay. To further clarify, when I do
my quarterly updates the entire folders are deleted before copying
begins. Of course, there could still be fragmentation from the other
database -- the subscriptions rarely arrive on the same day. There
are two databases -- one has relatively few very big files, the other
uses thousands of little files. Loading either database from new DVDs
causes the PC to behave about the same. The light on the DVD drive is
pretty much on all the time when copying either one . The DVD drive
is, I think, DMA2. For some reason, I suspect the DVD drive of being
the biggest hog but I will look in task manager next time UPS brings a
stack of discs.

What else can I tell you?

Don
www.donsautomotive.com

 

[Don]

So how about this? I just logged in to the PC under discussion from
my home using NetOp remote control while the data drive under
discussion is being defragmented. Between the remote access and the
defragment operation being performed you would think the PC would be
VERY unresponsive but it wasn't bad at all. There seems to be
something specific to XCopy from DVD that particularly bogs it down.

Don
www.donsautomotive.com

 

[The little lost angel]

something specific to XCopy from DVD that particularly bogs it down.

Sorry, but XCopy as in the DOS xcopy?