Jump to content

read and write speed ???


Recommended Posts

I'm using the Firewire version of the CR487-ETE mechanism in the LaCie enclosure. The Backup phase is very fast at 200 MB/sec or thereabout. I am now doing a restore and it is only going at 60MB/sec.

 

Whaty do I need to do to get the restore speed up to the backup speed ?????

Link to comment
Share on other sites

  • 5 months later...

I have now calibrated this mitsumi drive using the "Configure" preocedure successfuly. The backup speed is over 200 MB per minute, yet the restoral only shows 64 Mb per minute. The drive shows 52x as the write and read speed, so why is there a difference in the restoral speed ?

 

 

Link to comment
Share on other sites

  • 4 weeks later...

Restore speeds can be slower for many reasons, including read speed of the drive, how fast the data can be written to the destination drive, type of files being restored and the segmentation of the data being restored.

 

When you do a backup, data is written sequentially to the media. The data is constantly being streamed. When you do a restore, there may be files spread across multiple tracks (segments) and discs. Once a file (or a hundred files) are restored, Retrospect may need to locate the next file or set of files on a different part of the disc. This constant locating can slow down your restore.

 

Link to comment
Share on other sites

I'm using a Western Digital Internal 120GB IDE hard drive with a 4MB buffer and it's fast enough for flawless DV capture and streaming on a 500DP G4 Power Mac with gobs of RAM using system 9.2.2

 

This drive has 16GB of contiguous available space and I'm doing the test with a 600MB collection of data files of all sizes, although most of the files are 20MB or greater, with a whole bunch at all other sizes.

 

I'm using Vebatim ValueLife 52x media. The Mitsumi drive extracts Audio at wicked impressive speeds to the same hard drive, so the hard drive IS capable of keeping up while it is writing data.

 

What additional drive or system spec should I be looking at?

 

Thanks,

 

Pete D. computer.gif

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Quote:

I'm using Vebatim ValueLife 52x media. The Mitsumi drive extracts Audio at wicked impressive speeds to the same hard drive, so the hard drive IS capable of keeping up while it is writing data.

 


 

Extracting large contiguous (and even non-contiguous) tracks from a CD is much different then restoring mulitple packet files from backup media for the reasons previously mentioned.

 

For faster restore speeds, you may want to consider moving to a different backup medium, such as hard drive. Retrospect will stream the data as fast as the hardware will allow - there are no speed settings available.

 

 

 

 

Link to comment
Share on other sites

OK .. bear with me here . ... I'm still trying to understand this..................

 

When I do my test (unlike a "normal" restore) .... I'm restoring the large (I am assumning contiguous) chunk of data that I just backed up. Yet my restoral speed is still around 1/3 of the backup speed. It's not any faster than a conventional random restoral of mixed files...

 

If it's the "packets" that you mentioned that cause this, I still don't understand why the backup is so much faster .. since I'm assuming that the packets need to be created .. isn't there overhead for that too?

 

confused.gif

Link to comment
Share on other sites

  • 2 weeks later...

Each time you run a session data is appended to the end of the backup set. And if you restore selected files, the data is not necessarily going to be contiguous. Retrospect must look for the data on the disk - data which may be spread out across the entire disc or discs.

 

For example, if you ask Retrospect to restore 10 files and they all stored in different places (even from the same backup session) Retrospect must "locate" the first file, restore it then locate the second file and restore it then locate the third file, and so on. This is where you may see additional overhead. When ripping audio files you're not asking the drive to find multiple small files that are spread across the entire CD - you're asking it to write very large files that are on tracks.

 

Yes, there is overhead when writing the packets but the drive does not have to spend the time constantly looking for a place to write data - it's written to the end of the media.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...