Should a 357GB Image take 24+ hours to create?

I am trying to create this image and it seems to be running very slow to me. The image is be saved to another dirve on the computer being imaged. I have 1G of Ram and a 932M Pent 3.

Is this normal, I am using the trial version of True Image Enterprise 9.0? Seems slow to me. Maybe I'm wrong. Someone please let me know what kind of time you get.

 

On a much slower system, using a 7200rpm USB drive with an 8MB cache, it takes a bit under 3 hours to do a copy and verify, I have about 38904421376 bytes in files (as of a few daze ago), and compression was about 33%, so the image was about 25795715584 bytes.

Extrapolation would indicate that a 357GB image (is that the raw data, or the compressed imge?) would indeed take more than 24 hours.

 

357G is the size of the drive, it has 234G of data used on it. I just did the normal compression. This still seems a little slow to me.

 

The total size of the partition is of little value for this problem. The amount used is important and the compressed size of the .tib files is probably the most important because it is the amount of data that has to be transferred to the backup medium. These days most processors are fairly fast so they play a lesser role but certainly cannot be eliminated especially for slower speed CPUs.

Regardless, your times seem slow. Doing HD to HD within Windows which is what I assume you are doing since you are using a trial version you should be able to get around 400MB/minute of compressed .tib files I would think.

You don't say if your times include the verify time or are the straight write time and also whether or not your 234G is uncompressed original or the size of the compressed .tib files.

So if we assume your 234G is the total .tib size without a verify then the time should be about 9.8hrs at 400MB/min.

Unfortunately this time is suspect without the actual details. If you have Verify as part of the time then this would bump it up to say 17hrs since the verify is almost as long as the create. If your disk system really is slower then you could easily increase the estimated time as well. So a slow disk system and a Verify might get you to 24hrs alright.

Do you know what DMA speed you are running?

 

and that would at optimal speed.

But you have to add in the time it takes to read the source and to compress
I'd guess that a typical system, it's just gotta take more than 12 hours.

In another thread, I asked Acronis about th effect of fragmentation. This is most certainly a factor for the destination drive, but Acronis needs to state the effect for fragmentation on th source drive using a "drive" backup.

It's also hard to figure the effect of the sped of the destination drive.

Since I only use TO with the newer USB 8mb cache drive, I have no way to compare. But I do use Ghost 10 on an 80GB drive with 2MB cache and a 200GB drive with 8MB cache, both are 7200 RPM. SEagate does not publish the transfer rate, so I cannot compare at that level. In any case, the backup does seem to run faster on the drive with 8MB cache, but not by that much, maybe 20 minutes, if that much, or less than 10% faster.

I have not defragged both USB drives to eliminate that variable, some day I'll do that.

 

I based the 400MB/minute on the time taken between create and start verify listed in the TI log to do a backup that resulted in 2.8Gb of .tib files. HD to HD. So it should account for everything.

My PC is a 1.2Ghz AMD Athlon with 512MB RAM. The only wrinkle is that the 2 7200rpm 2MB cache disks are on a Promise UDMA 133 card which is why I dropped the number to 400MB/min from the over 600 MB/min I actually get. I figured dropping from over 600 to 400 should account for that and the slightly faster CPU than his for my estimated times.

When I run Drive Image 2002 on this machine it would show over 800MB/min being processed but that is likely the uncompressed amount of data.

For comparison my newer machine, P2.8Ghz, 1GB dual-channel RAM, 2 SATA drives disk to disk, will, according to the TI log, write the TIB at over 1300MB/minute.

From my understanding the larger cache a disk has shows up as better burst transfer rates but plays a lesser part in long transfers just because the disk still has to seek out the data.

 

This is still running. When it gets done I will update with better numbers. Thanks for the help.

 

My system has more memory, but a slower processor,

A good way to compare timings may be to run the program at http://ftp.raxco.com/pub/download/pd70/tools/FileAccessTimer.zip.

 

The tib file ended up being 205G and it took almost 25 hours to complete. This is without anytype of verify, just creating the .tib.

Also how do I figure my DMA speed?

 

To check DMA (current transfer mode) settings:

My Computer, Properties, Hardware, Device Manager, IDE ATA/ATAPI controllers, expand to list controllers, right click on the channel, Properties, Advanced Settings

Windows will drop the transfer mode if it encounters too many errors. The only way I've found to set things back is to remove the controller and reboot.

 

The Current Transfer Mode is set to PIO mode. And Transfer Mode states it will use DMA if available. So you think I should remove the controler?

 

Sounds like you’ve got a problem. PIO mode will crrrrrrawl.
I had this problem and, like I said, I had to remove the controller and reboot to regain DMA modes. It kept on reoccurring until I finally replaced the drive.

 

Also, I ran a full scandisk (the one that requires a reboot) which helped for a few days, but the problem always returned. The scandisk never did report any problems though.

 

So you think I will need to install a new drive to fix the issue. This is just a test box so I may be able to do it without a lot of problems. Which disk do you think is causing the issue the disk I'm reading from or the disk I am writing to?

 

“Which disk …”
The one that’s set at PIO mode.

“So you think I will need to install a new drive … “
Run a full scandisk and see if it solves the problem.

 

Did you try selecting DMA such that the current transfer mode is DMA?

What do you have on the same channel as the HD? If you have a HD mixed with an optical drive on the same IDE channel the optical drive might keep it in PIO mode.

If you have a bad device on the cable it probably doesn't matter if it is master or slave since the properties are for the channel not the separate device.

Anyway, if you are in PIO mode, I think you found the trouble or at least the first thing that has to be corrected. You could try a different cable since it is easy to do.

 

“Did you try selecting DMA such that the current transfer mode is DMA?”

AFAIK – You can select the ‘Transfer Mode’, but Windows sets the ‘Current Transfer Mode’. If you select ‘DMA if available’, Windows, the first time it see the channel, will check the drive. If the drive is capable of DMA modes, Windows will set it at the highest DMA mode the drive will support.
If the drive gets set to Ultra DMA 5 but Windows begins to detect repeated errors, the drive will have its transfer mode systematically reduced. When that happens, the only way to set it back is to remove the channel and reboot. A simple reboot will not reset the current mode.
It is possible to mix and match on the same channel.

 

Thanks for the info.

I had a LG reader and there was no way that anything could co-exist on its channel as DMA. Anyway I think it is still considered a poor idea to mix optical drives with HDs on the same channel.

 

"Anyway I think it is still considered a poor idea to mix optical drives with HDs on the same channel."

Agreed. My example was of a DVD and a Zip drive. Not often I'd have both of them humming a once.

 

Here is a little update:

I got my Primary IDE's Current transfer Mode set to Ultra DMA Mode 2, this is for device 0, for device 1 it is NA.

For the secondary it is the same way.

However I tried to restart the same image which took around 25 hours. After a few minutes I checked the time and it stated it would take about 2 Days. While going through the image wizard it stated the image would only take about 7 hours. So although I did make the changes like you guys suggested it didn't fix the slowness.

I was able to create an image of a remote drive, however this on is much smaller. The tib file was about 3.5G and it only took 22 minutes. So if you calculated out the time for my large 205G process it would have took about 21.5 hours. So I guess nothing is faster. I check my event logs and found nothing to show errors there. Also the first time I tried to run the remote image it failed with a 'code 4 "write error". This maybe network related but, it too did not show in the event log.

 

How did you get your drive to Mode 2 and is it still at that setting? Mode 2 is still slow. My PATA drives are Mode 5.

 

I just choose DMA if availble and this is what came up, so maybe I have a slow controler. I will look into that.

 

There is no need to uninstall the controller from Device Manager. The checksum for the drive(s) has got corrupted due to read errors (XP will do that with little tolerance).

To regain DMA mode do as follows:

Open regedit, and edit the following keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\000x

Click on the sub-folders 0001 and 0002. Among the keys inside those folders, you'll find MasterIdDataChecksum and SlaveIdDataChecksum.

Double-click the key(s), and delete the value assigned to it.

Reboot, and XP will redetect the drive's DMA.

 

Have you got the manual for your motherboard or perhaps can download it if you don't. That way you can check what the controller is supposed to be capable of.

Your BIOS settings might be a clue as well regarding how the drives are indentified before Windows puts its nose into the mix.

Naturally, a DMA 5 controller with a DMA 2 drive isn't going to run at DMA 5. My guess your controller probably is in the the UDMA 2 speed range but I don't know.

I fired up my old AMD K5-II 500Mhz system and did a test. Ran at about 120MB/min (that is per MB of compressed image file) which is slower than your system (no surprise); the disks are UDMA2. Other wrinkle is that was using DI2002 since TI isn't on the machine and it does its backup in DOS. So it is at best a rough ballpark comparison.

 

"To regain DMA mode do as follows: ..... "

OK, LOL, and that's eaisier than clicking "Uninstall" how?