Speed up remote service checksummer

[dbadmin]

Is there any way to get the remote service to use more CPU to create the checksums? I tried changing the Scanning Threads Per Listing higher but that really didn't make a difference. I am using the remote service to make the checksums of VHDX files at a remote site, and the machine is dedicated just for this task, but the max CPU I see being used is 20%. Is there a way to get it to just max the CPU and create the checksum faster?

The machine running the remote service is a VM running on the same physical box that is hosting the file shares so I don't think its a network issue.

I did try to get the setup running without the remote service, but every test failed to use the differential update, though I can get it to work from if the source and destination are both windows servers. It seems like perhaps the QNAP nas is doing something to the files on the remote end to make the program think the files have changed. Perhaps you have some incite as to what that could be?

Thanks!

[superflexible]

Without the remote service, it can use Partial File Updating the second time you run the profile with the same destination. You need to look in the log file to get statistics on bandwidth saved, and possible reasons why partial file updating could not be used. Files are considered different if the timestamps or size has changed. Make sure you use the default Comparison options (i.e. ignore up to 2 seconds differences).

The Syncovey Remote Service will use only one CPU core for each file. You could try the checkmark "Request only one file at a time" in the Syncovery profile. That means files being copied in parallel will send separate checksum requests, and the remote service may process them in parallel too.

[dbadmin]

So I have tried the setting "Request only one file at a time" and its interesting, now in the status of the remote service monitor window I can see alternating flashing that its creating the check-sums for the different files. It shows different file names and different percentages as the files are much different sizes, but unfortunately its not using any more CPU then before, so I think it will net in the same speed.

[superflexible]

Thanks, I will consider making it multithreaded.