Why does XP Professional take forever to transfere large data?

[Candyman7]

It takes forever to transfer huge data from one place to other place in Hard drive. It does not use 90% CPU. It uses only 12% to 25%. On the other hand Windows 2000 uses up to 95% of CPU for transferring data from one place to the other. For other usage my processor works perfect!

What could it be? Maybe a different Algorithm? Is there a way to change CPU utilization? By the way, by setting higher process priority(In Task Manager) does not make much difference. Definitely not a Virus or a spyware... I know that for a fact.

Could it be XP? Or maybe AMD? Is there a solution to this problem with XP?



My System
Windows XP Professional OEM
AMD XP 1800
WD 7200RPM
Ultra DMA enabled

 

[Alphathree33]

You must be the only person who COMPLAINS when the CPU works efficiently.

It will probably use a DMA transfer of some kind which doesn't require the CPU's full attention except for Kernel interrupts and such.

If you're transferring on the same physical disk, it may be that the data you're moving is very fragmented and it takes the hard drive a long time to find it -- in other words, try defragging first. There could also be damaged areas of the disk that it's trying to working around -- try scan disk.

You might also want to make sure that your memory and page file aren't being heavily used during the transfer.

I'm not sure if the data actually goes through memory, but if it does and you're memory is backed up, you might be in the situation where the main memory is getting a lot of page faults that the hard drive has to take care of during the transfer.

 

[Netopia]

On Access Virus Scanning?

 

[sat]

Originally posted by: Netopia
On Access Virus Scanning?

good point. Here are some thoughts:

1. Defrag & chkdsk (like the other poster said)
2. Turn off your AV scanner (if you have one that is)
3. Are you copy a LOT of SMALL files? Or SMALL number of LARGE files? The former tends to be slow due to several reasons (files scattered around even on fully defragged drives, lots of disk i/o overhead, lots of api calls in between).
4. Are the partitions you are copying FROM and TO, on the SAME physical hard drive? Then it tends to be (much) slower. No way to get around this - interleaved reads/writes not possible - everything is serialized (the on-disk cache somewhat helps)
5. The fastest would be copying from (a partition on) one physical drive to (a partition on) another - and the disks are connected to unique IDE/SATA ports.
6. The ultra-fastest is to buy a SCSI drive, or the Raptor drives (IDE), or setup a striped RAID-0 configuration and double the speeds