Resilio Connect is a very flexible software complex that works in a wide range of use cases and environments. Possible configuration parameters are widely represented but not limited to those mentioned in the Job or Agent profile. There are many more hidden custom parameters for advanced tuning and getting the maximum value.
Some of them serve well for some of most wide spread use cases and are covered in this section.
Below you will find a list of advanced parameters that can be used in the Agent Profile, or Job profile if mentioned specifically.
Use with care
Please use them with caution and only if you understand what you're doing. Each of these has side effects and may be not compatible with some other non-default parameters.| Name | Default value | Description |
| tunnel_compress_stream | false | Added to Agent profile in Resilio Connect v3.0.0. Helps to safe data traffic. As a side effect, enabling compression will cause CPU usage to compress and decompress data. |
| disk_worker_pool_size | 1 | number of threads each disk uses for disk operations. Increasing the number shall improve performance on high-latency CIFS with multiple worker threads support. Applicable for high speed drives (fast SSD, raid). May be used to find best performance on network shares. Can be increased when syncing with a cloud storage, see here for more details. |
| disk_worker_per_job | false | If set to true, a job will have standalone drive thread and perform synchronization if parallel with other jobs. On the other hand, multiple parallel threads may clog the disk. For agents to perform indexing in parallel as well, set parameter parallel_indexing as true as well. Requires restarting the Agent for changes to be applied. |
| direct_torrent_enabled | true | If a file is smaller than the current speed, it won't be broken into pieces. This may reduce transfer time as fewer requests are made and fewer pieces are transferred, but if transfer is interrupted, file will be re-synced from start. Works only for non pre-seeded case. If you choose to disable it, it shall be done for both - sender and receiver of files at the same time. If it's disabled for receiving agent, the Agent will request file pieces, without significant impact on performance. But it's it's disabled for sender only, the receiver will request full file, and when sender rejects this, will switch and request file pieces, which leads to excessive work traffic between agents. |
| build_script_working_dir | false | If set to true, and pre-indexing trigger in Distribution or Consolidation job has a command to create the source path, it will be created. |
| lazy_indexing | true |
Made visible in Job Profile in v3.2.1. Enabled lazy_indexing means that the Agent will not hash any files until some other Agent requests to download it. It improves speed of merging folder tree and getting the job into balance (especially when only few files differ on different agents). On the other hand, not having a file hash is a great risk in cases when files are renamed, new agents appear in the mesh, etc. read more about using this parameter here. Some other parameters require this option to be either on or off. Can be added to either Agent or Job profile. |
| transfer_job_force_owner_to_hash_file | true |
! Important ! Starting with Active Everywhere 4.0, we recommend retaining file hashes. Read more about it here. Made visible in Job Profile in v3.2.1. Disabling it is not advisable for Synchronization jobs, especially if agents tend to go offline periodically as other agents won't be able to download the files until file owner is back online. |
| connect_more_peers_interval (deprecated starting with v3.0) | 1, sec |
Be sure to add them to all agents in the job. These three parameters define how frequently agents do the following accordingly: Increase these up to 2-5 minutes for large numbers of agents or files. Agent will do this less frequently and thus sped more resources on transferring files, but as as side effect current status and job performance statistics will not be updated in realtime. |
| state_notify_interval | 10, sec | |
| update_peer_stat_interval | 5, sec | |
| net_default_timeout | 30, sec | Timeout for peers connections. Increase up to 3-5 minutes for unstable networks or if there are a lot of agents and files in the job. |
| transfer_peers_limit | 50, integer |
Number of agents that can be connected to each other at a time. Increasing this parameter will force agents to be busy with establishing and keeping connections to each other. It will impact the job performance and load the Agents. It makes sense to decrease it especially for unstable networks. |
| ignore_mtime_assign_errors | false | If an agent cannot change file's attributes (mtime or x flag), the Agent reports error and job stalls. If it's True, the Agent will skip the error, write the current mtime on disk and preserve the correct one in the database. Other attrs are dropped. The greatest side effect is that files will get current timestamp on disk - it may affect other applications that work with the files or files will be considered newer if the job is recreated (see pre-seeded usecase) |
| reset_file_error_interval | 60, sec | how often the Agent will try to re-download a file that failed to be synced for a reason, again. If there are a lot of non-synced files in a job, it makes sense to increase the value up to 1800 (which is 30 minutes). Otherwise, the Agent will one be busy trying to sync failed files. |
| recheck_locked_files_interval |
Made visible in Agent Profile in v3.2.1. Similar to reset_file_error_interval, but refers to local locked files. It is the frequency at which the Agent will come back and see if the file is still locked (in cases when it's not notified by the system). Default value is 600. Put there 60 (=1 minute) if it fits your use case. Don't put a too frequent interval as the Agent will be only busy with rechecking the file. Don't put a too rare interval either as some delays in synchronization will be observed. |
|
|
transfer_job_exact_ctime_timestamps |
-1, special |
The parameter defines the Agent's strategy when synchronizing creation timestamp (ctime) of a file and taking it into account in pre-seeded use case. -1 (auto, it basically sets values 1 and 2 for different agents) |
|
transfer_job_verify_downloaded_files |
false | Works for destination agents in Consolidation or Distribution jobs. Re-checks the hash of a partly downloaded ...!sync file before moving it to its destination location. If enabled, increases disk and network load. File will be redownloaded if "Disable differential sync" in Agent Profile is True |
|
priority_peers |
- | See it as an arbitrary Agent in mesh. Especially valid if Selective Sync is used on other agents. The arbitrary agent shall not have Selective Sync enabled as it will keep all the files and will confirm receiving files to others. Users may now be confident that files are there and clear them off their workstations to free up some space. Add custom parameter priority_peers with Agent ID as value in Agent Profile. Agent ID can be learned from the agent details. If several agents need to be defined, use semicolon (;) as separator. |
|
download_priority |
0, special |
It works on receiving agent only when it selects files for download. 0 - no priority |
|
prioritize_initial_indexing_mode |
1 |
The value is bitmask and sets priority for building file indexes before syncing. By default agent prioritizes indexing only for initial rescan and only when lazy_indexing is enabled. It's possible to enable priority for every rescan after restart and ignore lazy indexing state (but if it turned off, time spent for periodic scan can increase significantly) 0 - OFF 1 - initial rescan (for newly created jobs) 2 - first rescan (agent Agent restart) 4 - ignore lazy_indexing state Read more here. |
|
transfer_job_prefs_folder_name |
- | Lets two agents sync same folder. Pattern is .sync.abc Shall be added to Job profile. This needs to be done before job creation. It's ignored for already created jobs. Of two agents that are going to use same folder it's sufficient that the parameter is fed to at least one of them. Works for Distribution, Consolidation and Synchronization jobs. |
|
db_preload_on_startup_mode |
2, special |
Agent will attempt to load files in "preload mode": this way database file is read sequentially, which is much faster on HDD/NFS drives. The side effect is that additional RAM is required to load the database on start (double the database file size). However, this memory is freed right after load is complete. 0 - OFF |
|
keep_expired_transfer_num |
1000 | Count of job run of Consolidation, Distribution or Script jobs on tab Transfers count in Agent UI. |
|
net.utp3.ack_repeat_times |
1 | ACK packets will be repeated if no new data is available. This helps to keep stable speedup and operating with lower windows on lossy links. Default value is 1. |
|
net.utp3.max_send_threads |
2 | Max threads to use for sendmsg() system socket API. Default value is 2. |
|
net.utp3.max_socket_threads |
2 | For arm OS X default is 1. This value limits net.utp3.max_send_threads. For value N there will be N receive and N send threads per address family (ipv4 and ipv6). Not too useful unless we use single port as RPS/RSS moves all the data to single socket. |
|
net.utp3.speed_per_worker |
400 | Speed threshold per sendmsg() worker, kpps. Default value is 400, which is ~550MBps at mtu 1500 and it's good for 3+GHz CPUs with >10GBps memory channel. For 2GHz, use 300-350. This parameter must conform withnet.utp3.max_send_threads. Combination max_send_threads * speed_per_worker is not linear due to cache effects, it's better to have fewer workers with more speed than more workers with low speed. |
|
net.utp3.max_send_buf_pkts |
200000, packets |
Max send buffer to allocate for ZGT. Default value is 200000 (300MB at mtu 1500). Large values allow to keep sending in case there's a gap in data generation. ZGT requires two 1.7RTT frames of data to adjust speed, so setting this value too low will break ability to speed up. |
|
net.utp3.max_recv_buf_pkts |
200000, packets |
Max receive buffer to allocate for ZGT. Default value is 200000 (300MB at mtu 1500). Value is similar to window size and should now be less than BDP (better BDP 1.5) or incoming packets will be dropped. |
|
fs_fuse_storage_prefix |
- |
Option to set data storage path (aka cache) for virtual folders to point it to disk with enough free space when required. Full path to storage should be set. for an already created job, if you change the path, agent must be re-added to the job, or restarted in the job run |
|
external_port |
<> |
It's required to configure the external port in the Agent profile in cases when the Agents are each behind a NAT or firewall (pfSense in particular). It can be any allowed port, including the default Connect's 3839. |