pjd813 Posted May 7, 2003 Report Share Posted May 7, 2003 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 More sharing options...
AmyJ Posted May 7, 2003 Report Share Posted May 7, 2003 CR487-ETE - This does not show up in a search of the supported devices. While in Retrospect, go to Configure > Devices > Environment and list Vendor, Product and Version for your drive. Link to comment Share on other sites More sharing options...
pjd813 Posted May 8, 2003 Author Report Share Posted May 8, 2003 Vendor = Mitsumi Product = CR-487ETE Version = 0019 driver = MITSUMI CDRW (5.01) Link to comment Share on other sites More sharing options...
pjd813 Posted October 28, 2003 Author Report Share Posted October 28, 2003 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 More sharing options...
pjd813 Posted November 21, 2003 Author Report Share Posted November 21, 2003 Is anyone out there listening? ? Link to comment Share on other sites More sharing options...
AmyJ Posted November 21, 2003 Report Share Posted November 21, 2003 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 More sharing options...
pjd813 Posted November 23, 2003 Author Report Share Posted November 23, 2003 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. Link to comment Share on other sites More sharing options...
pjd813 Posted December 3, 2003 Author Report Share Posted December 3, 2003 wellllllll....... is there an answer or a suggestion ??? Link to comment Share on other sites More sharing options...
pjd813 Posted December 14, 2003 Author Report Share Posted December 14, 2003 What do I need to do to get the restore speed up to the backup speed ????? Link to comment Share on other sites More sharing options...
AmyJ Posted December 15, 2003 Report Share Posted December 15, 2003 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 More sharing options...
pjd813 Posted December 15, 2003 Author Report Share Posted December 15, 2003 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? Link to comment Share on other sites More sharing options...
pjd813 Posted December 29, 2003 Author Report Share Posted December 29, 2003 still confused .. Link to comment Share on other sites More sharing options...
AmyJ Posted December 30, 2003 Report Share Posted December 30, 2003 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.