Sign in to follow this  
pubidcam

Copy speeds are low, less than 2MB/s!

Recommended Posts

From my understanding, it does read ahead (which is also called pre-fetching) when dealing with hard drives in this particular situation. Granted it does also keep recently accessed data that is used the most, but that is not its sole purpose like in system cache or L1 and L2 cache.

http://www.pcguide.com/ref/hdd/op/cache-c.html

or even a version from Storage Review

http://www.storagereview.com/guide2000/ref...eCircuitry.html

Share this post


Link to post
Share on other sites
Why wouldn't it matter? I understand that, usually, the cache tries to prevent physical disk access, but in the case of file copying, it would be fast to read 8MB into cache, then write the 8MB out, read 8MB in, write 8MB out etc.

If it doesn't work this way, then that's fine, but file copying is indeed a unique disk activity. Most of the time, things are read from the drive and loaded to RAM.

If anyone can explain why, during file copies, the drive doesn't use it's cache to swap reads and writes, that would be nice.

Well, the drive does use its cache, just it doesn't read in chunks to fill up the cache. File copying is not unique from the hard drive's point of view. Depending on the exact algorithm use to manage the cache, what most likely happens is this for a drive with 8MB cache:

1. Windows issues a read of 64KiB from hard drive to a memory location.

2. Hard drive reads 64KiB, sends to the memory location, and caches the data with available memory or replace old data if none is available.

3. Windows issues a write of 64KiB to hard drive from that memory location.

This process just repeats until all data are copied. The hard drive never knows it's copying anything. It just does what ever the operating system tells it. It may read ahead a few kB of data in consecutive sectors (it doesn't know the data is part of the file or not). At the end the cache will fill up with 8MB of data, but it never reads 8MB of data in chunks and writes 8MB in chunks.

Also, reading 8MB into a buffer before writing it doesn't guarantee copying will be faster (there're situations where it will be slower). The operating system does know it is copying data, so it could allocate some space in RAM and read all data and write in chunks. But it only reads 64KiB for other reasons.

Share this post


Link to post
Share on other sites
datestardi:100% CPU usage in 98SE sounds to me like something is throwing the computer (and consequently the drive) into DOS-compatibility (PIO) mode. Can we assume you're not trying running DOS programs before you copy, or trying to copy with DOS programs?
I'm not using DOS programs, and DMA is always checked in Control Panel/System/Device Manager. Nevertheless, I think that it's concluded, with reasonable amount of certainty, that my disks are slow because of their production date. My CPU was stuck on a sponge when I bought it, and Windows 98 shows CPU usage to be much higher than in Windows XP, so I'm not to much concerned about it.
meanie: WD: Western Digital WD800JB (80GB - 2MB buffer)

HT1: Hitachi T7K250 (250GB - 8MB buffer)

HT2: Hitachi 7K250 (160GB - 8MB buffer)

They are 7200RPM. I transfer different 200MB files around, and the arrows point to the destination.

WD->WD: 8MB/s

HT1->HT1: 23MB/s

HT1->WD: 33MB/s

WD->HT1: 25MB/s

HT2->HT1: 55MB/s

Seeing my old hard drive is that slow, yours transferring at 2MB/s is kinda reasonable.

Apparently so. Thanks for your figures, although you didn't put the HT2->HT2 figures, and since I have the same disk, it's those figures I'm most interested about.
meanie: 1. Windows issues a read of 64KiB from hard drive to a memory location.

2. Hard drive reads 64KiB, sends to the memory location, and caches the data with available memory or replace old data if none is available.

3. Windows issues a write of 64KiB to hard drive from that memory location.

This process just repeats until all data are copied. The hard drive never knows it's copying anything. It just does what ever the operating system tells it. It may read ahead a few kB of data in consecutive sectors (it doesn't know the data is part of the file or not). At the end the cache will fill up with 8MB of data, but it never reads 8MB of data in chunks and writes 8MB in chunks.

So, what you are basicaly saying is that hard disk reads just 64KB on from one part of the disk, than moves and write those 64KB on another part, then goes back again to read. I thought that computers are smarter than that, it just doesn't sound right. If the 64KB is some kind of a limit, couldn't it be that 64KBs are read in succesion, and then written.

SRs' article at http://www.storagereview.com/guide2000/ref...eCircuitry.html , that Mike@ComputerTechnical pointed out, says this:

if copying a 10 MiB file for example, on a typical disk with a 512 kiB buffer, at most 5% of the file could be in the buffer: the rest must be read from the disk itself.
Disks can't read and write at the same time, and what is read must be remembered somewhere until it's written. I guess that disks' buffer is faster than RAM, so it would make sense that it's carrying as much as possible in its backpack :) HSW rocks.

This make me wonder, how the 2MB buffer in my CD burner behaves then?

Share this post


Link to post
Share on other sites

Just wondering.. Did you install a Creative SBLive! soundcard in that machine? :unsure:

Another possible problem is Windows default driver for VIA bus master IDE itself. That one on many ocassions reverts (or degrades) to UDMA33 or PIO modes whenever the operating system detects slight problems (like not detecting 80-wire IDE cable). Have you tried VIA's own driver instead? :blink:

Share this post


Link to post
Share on other sites
Just wondering.. Did you install a Creative SBLive! soundcard in that machine? :unsure:

Another possible problem is Windows default driver for VIA bus master IDE itself. That one on many ocassions reverts (or degrades) to UDMA33 or PIO modes whenever the operating system detects slight problems (like not detecting 80-wire IDE cable). Have you tried VIA's own driver instead? :blink:

I have integrated sound, and VIA Bus Master PCI IDE Contoller Driver Provider is VIA Technologies, Inc. Edited by pubidcam

Share this post


Link to post
Share on other sites
I have integrated sound, and VIA Bus Master PCI IDE Contoller Driver Provider is VIA Technologies, Inc.
That rules out the SBLive! bus hog issues and Windows own VIA driver fallback. Check the BIOS settings on the maximum UDMA used. It should be either UDMA5 (ATA100) or UDMA4 (ATA66). Many older drives do not run at ATA100, but only at ATA66 (or even lower such as ATA33). Try setting a UDMA mode which both drives support (recommend either ATA66 or ATA33). Also make sure the IDE cable used is a certified 80-wire ATA66/ATA100 IDE cable. ;)

Share this post


Link to post
Share on other sites

What about this?

Windows 98SE -> Control Panel -> System -> Device Manager -> Disk Drives -> GENERIC IDE DISK TYPE47 -> Driver Provider: (Standard disk drives) Date: 4-23-1999

Instead of IBM-DTLA-305020. Just to add that the drive is from 2001.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this