Software compression uses only one core

[Lennart_T]

I had the impression that Retrospect 8 would finally be multithreaded, but I can't get it to work.

 

RetroEngine uses at most 100% of ONE processor core.

Yet, the recommendation is Intel Core Duo processor.

( Why recommend two cores if Retrospect isn't going to use them? )

 

Now, how do I get Retrospect to use all cores for software compression?

[bvaandr]

Interesting verification of something I just noticed on the Windows multi-server version. When running just one backup set verification job on a 1.8 TB compressed backup set, the first core is maxed out at 100% usage while the other ones are barely ticking over.  Even the 8.2 beta offers no apparent improvement, so far as multi-threading goes.  This may be a big reason for slow backups, verifications, and so on.  Zip files that are being backed up are especially slow, since the Retrospect compression routine apparently still tries to compress them.  I have noted in many different scenarios and operating systems that any algorithm that tries to compress already compressed files seem to try to do a lot of work for nothing.  So, just as an example, verification rates for zips are 3 GB/min on my system, whereas binaries go 6 to 8 times as fast. The 8.2 beta seems to have significantly improved speed over its predecessor, but it still appears that hardware level or OS level compression may be the answer, if time and patience are lacking.

[NTmatter]

As far as I can tell, Retrospect is multithreaded in the sense that it will run multiple jobs at once, with one job per core.

 

Having a multi-core system is still beneficial as it means other things (such as the UI and the OS) don't need to interrupt RetroEngine while it does its thing. It also means that you could potentially run two jobs at once if you're not bottlenecked by IO bandwidth.