Tiny quirk with TI 8 build 771

Discussion in 'Acronis True Image Product Line' started by Tipton, Sep 15, 2004.

Thread Status:
Not open for further replies.
  1. Tipton

    Tipton Registered Member

    Joined:
    Jun 14, 2004
    Posts:
    82
    The only quirk that I have found so far with TI 8 build 771, is again with the compression. With build 768, the compression would not be listed correctly, at the final screen before imaging. For example if you chose High, it would be listed as normal.

    Now they corrected that, but when I create an image within windows, no matter what compression I choose, it says it will take less than one minute.(See screenshot) I tried a few different compression settings, and it does take longer to image with higher compression. When I use the rescue CD, it will show different lengths of times that the imaging will take, depending on the compression level you choose.

    Other than that, this new build works totally fine.
     

    Attached Files:

    • ti3.png
      ti3.png
      File size:
      20.8 KB
      Views:
      553
  2. foghorn

    foghorn Registered Member

    Joined:
    Aug 7, 2004
    Posts:
    86
    Location:
    Leeds, England
    Remember that any estimates are guesses as it does not know how suitable the partition data is going to be for good compression ratios, until it has finished compressing it. Some files compress better than others. 60 seconds is neither here nore there when it doesn't know how it will get on with the compression.
     
  3. VorLon

    VorLon Registered Member

    Joined:
    Aug 26, 2004
    Posts:
    5
    Location:
    UK
    I don't think you noted Tipton's post - ie it's more reflective/informative in Rescue Mode :doubt:
     
  4. Tipton

    Tipton Registered Member

    Joined:
    Jun 14, 2004
    Posts:
    82
    Thanks for the reply Foghorn!

    Why does it actually give different time estimates when you use the rescue CD for creating an image?

    Not to mention, Ti 7 build 634 shows different time estimates during an image creation when imaging within windows. So does TI 8 build 764. Its the latest build 771, that shows one minute no matter what compression you select. Again this is only when creating an image within windows.

    Its really no big deal, because its working fine otherwise!

    Tipton
     
  5. Menorcaman

    Menorcaman Retired Moderator

    Joined:
    Aug 19, 2004
    Posts:
    4,661
    Location:
    Menorca (Balearic Islands) Spain
    Hi Guys,

    This problem already flagged back to Acronis Support some time ago and assurance received that it'll be addressed in a future build. Please checkout thread https://www.wilderssecurity.com/showthread.php?t=45068

    Regards
    Menorcaman
     
  6. AlainP

    AlainP Guest

    Samething here (less than 1 min....)

    This error appears only if I change de default backup filename.

    When I use the default filename "MyBackup.tlb" it works fine.


    Support told me to download latest build. I did and it's still the same. I wrote back to support ... still waiting for an answer.
     
  7. MiVi

    MiVi Registered Member

    Joined:
    Nov 5, 2004
    Posts:
    9
    Build 774, run from within Windows.

    Under None compression, time estimate is 12 minutes.
    Normal compression is 9 minutes.
    High is 20.
    Maximum is 30.

    Why would None be estimated to take longer than Normal compression??
     
  8. Menorcaman

    Menorcaman Retired Moderator

    Joined:
    Aug 19, 2004
    Posts:
    4,661
    Location:
    Menorca (Balearic Islands) Spain
    Yes the 1 minute time estimate bug has been fixed in Build 774!!

    The reason "Normal" compression takes less time than "None" is that the image file is smaller and hence there are less bytes of data to physically write to the disk. In the case of "High" and "Maximum", it's clear that the extra processing time required for these higher compressions algorithms outway the advantage of marginally smaller image sizes.

    Regards
     
  9. MiVi

    MiVi Registered Member

    Joined:
    Nov 5, 2004
    Posts:
    9
    "The reason "Normal" compression takes less time than "None" is that the image file is smaller and hence there are less bytes of data to physically write to the disk."

    That makes absolutely no sense.

    Any processing and compression of data should take longer than just writing the data straight, no matter how large the drive.

    Yes it's clear that higher compression will take more overhead and thus more time to process. That makes sense. To then go and use the exact opposite logic and say that a small amount of compression will take less time than doing nothing makes no sense. Writing a little bit of extra data to a modern drive should not take longer than it would take to compress the data and then write it - even if it's a small amount of compression.
     
  10. hoarenet

    hoarenet Registered Member

    Joined:
    Nov 6, 2004
    Posts:
    2
    How about this.

    If you have None selected then the CPU and Memory are going to be busy passing all the raw data uncompressed over the IO channels involved in writing to your image file and reading from the partition to be backed up without a break. The CPU and memory are both busy doing this along with the IO channel involved to write and read the data.

    If you choose normal then the CPU/Memory will be mostly busy compressing the read data but not have to pass that data to the backup image file. Once it's got a bunch of compressed data ready it will then send this quickly as a chunk to the Image file.

    Now if you choose High then this will increase the compression overhead and will indeed cancel out the saving of writing normal compression data to your image file. Therefore in theory it should be slower than normal.

    Thats my explaination. I hope it makes some sense.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.