JimKnopf

Members
  • Content Count

    28
  • Joined

  • Last visited

About JimKnopf

  • Rank
    Member
  1. Hi, Sync 2.6.1 (1319) armhf (latest/greatest version available using your apt repository http://linux-packages.resilio.com/resilio-sync/deb) tried to transfer a really huge single file (50 GiB) to 4 clients: - 2 clients have had more than 100 GiB free disk space in their file-systems where the receiving resilio folders reside: The synchronization finished as expected, fine. - 2 clients started with more than 50 GiB but below 100 GiB free disk space in the related file-system: Here the transfer were stuck on the sender side stating still 2MB data to be transfered. On the receiving side you could see the received file in the ".sync" subfolder ... but the complete transfer process finished only in that moment when 50 GiB free disk space or even more were made available in that file systems. On the stuck receivers you find log entries like "timestamp":1549493598,"type":2},{"folder":{"id":-2589366840598215013,"name":"1"},"id":14496,"msg":"Not enough space to sync 1 file to '1'", It looks like sync checks the available free disk space before moving the received file from subfolder .sync to the parent=target directory in a last step and ignores the circumstance that this is not necessary since both directories already reside on the same file system. By that you have to caclulate at least twice the amount of free disk space of the largest file you want to synchronize. Works as designed?
  2. JimKnopf

    Sync incomplete

    Hi, the log from the raspberry pi would be more helpful I think. First idea came into my mind: Have you checked the available disk space on the pi at /mnt/archivio ?
  3. Hi, I understand that Bittorrent has to find a way to make money with the product. But using now a Bittorrent server system in between the process of connecting clients sharing data, btsync is now exactly doing what I do not want at all: Giving someone Information about my (social) network. For establishing the links between btsync clients, the provider of the data and the receivers have to use the link https://link.getsync.com/ ... so, Bittorrent knows exactly who is connecting to whom and sharing data. Privacy was one of the biggest advantages of btsync for me comparing to cloud solutions. Sorry but with current 2.0 mechanism btsync is a NOGO for me. I know that you can still create 1.4 "classic" folders by doing a shift+click on the "add folder" button in the webGUI. But latest with the remove of this feature btsync is "out" of my environment. My 2 cents worth.
  4. Logs and more inforamtion sent to request #13117. Might I suggest to move this thread to the sub-forum BitTorrent Sync for NAS (Network Attached Storage) which wasn't existing when the topic was opened in April 2014?
  5. So, tried btsync 1.4.72 on my Synology DS214se and btsync is still preventing the NAS from hibernation. With this btsync version I can see frequent accesses to the files and directories /etc/resolve.conf /usr/local/btsync/var /usr/local/btsync/var/sync.log causing the NAS not fall into sleep. Sep 4 10:25:45 synology214se kernel: [696121.024546] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:26:46 synology214se kernel: [696182.258348] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:27:47 synology214se kernel: [696242.894856] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:28:48 synology214se kernel: [696303.648485] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:29:49 synology214se kernel: [696365.002425] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:30:50 synology214se kernel: [696425.690824] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:31:51 synology214se kernel: [696487.112083] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:32:43 synology214se kernel: [696539.169390] [/usr/local/btsync/var] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:32:52 synology214se kernel: [696548.378425] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:33:53 synology214se kernel: [696609.369238] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:34:54 synology214se kernel: [696670.404352] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:35:55 synology214se kernel: [696731.430042] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:36:56 synology214se kernel: [696792.505419] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:38:58 synology214se kernel: [696914.445271] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:39:59 synology214se kernel: [696975.352387] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:41:00 synology214se kernel: [697036.423209] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:42:01 synology214se kernel: [697097.710098] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:42:43 synology214se kernel: [697139.608243] [/usr/local/btsync/var] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:43:02 synology214se kernel: [697158.533397] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:45:04 synology214se kernel: [697280.682144] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:45:10 synology214se kernel: [697286.731258] [/usr/local/btsync/var/sync.log] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:46:05 synology214se kernel: [697341.909064] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:47:06 synology214se kernel: [697402.724441] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:48:07 synology214se kernel: [697463.729874] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:49:08 synology214se kernel: [697525.096243] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:50:09 synology214se kernel: [697585.925712] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:51:10 synology214se kernel: [697646.660838] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:52:11 synology214se kernel: [697707.906362] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:52:43 synology214se kernel: [697739.961112] [/usr/local/btsync/var] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:53:12 synology214se kernel: [697769.019180] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:54:13 synology214se kernel: [697829.884610] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:55:14 synology214se kernel: [697890.979216] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:56:15 synology214se kernel: [697952.206347] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:57:16 synology214se kernel: [698012.813897] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:58:17 synology214se kernel: [698074.090057] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 10:59:18 synology214se kernel: [698135.224322] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:00:19 synology214se kernel: [698196.333894] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:01:20 synology214se kernel: [698257.135890] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:01:21 synology214se kernel: [698258.281252] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:02:21 synology214se kernel: [698318.411403] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:02:43 synology214se kernel: [698340.428702] [/usr/local/btsync/var] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:03:22 synology214se kernel: [698379.435260] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:04:23 synology214se kernel: [698440.701644] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:05:24 synology214se kernel: [698501.398852] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:06:25 synology214se kernel: [698562.157579] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:07:26 synology214se kernel: [698623.573903] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:08:27 synology214se kernel: [698684.831508] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:10:29 synology214se kernel: [698806.801590] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:11:30 synology214se kernel: [698867.777619] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:12:31 synology214se kernel: [698928.850439] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:12:43 synology214se kernel: [698940.796714] [/usr/local/btsync/var] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:13:32 synology214se kernel: [698989.952323] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:14:33 synology214se kernel: [699050.928651] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:15:34 synology214se kernel: [699111.890056] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:16:35 synology214se kernel: [699172.901925] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:17:36 synology214se kernel: [699233.948474] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:18:37 synology214se kernel: [699295.209496] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:19:38 synology214se kernel: [699355.938082] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:20:39 synology214se kernel: [699416.975180] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:21:40 synology214se kernel: [699478.176202] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:22:41 synology214se kernel: [699539.281514] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:22:43 synology214se kernel: [699541.214732] [/usr/local/btsync/var] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:23:42 synology214se kernel: [699600.228408] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:24:43 synology214se kernel: [699661.061457] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:25:44 synology214se kernel: [699722.243946] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:26:45 synology214se kernel: [699783.495599] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:27:32 synology214se kernel: [699830.419694] [/usr/local/btsync/var/sync.log] opened by pid 19363 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:27:46 synology214se kernel: [699844.420648] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:28:47 synology214se kernel: [699905.580677] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:29:48 synology214se kernel: [699966.405961] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:30:49 synology214se kernel: [700027.487911] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]Sep 4 11:31:50 synology214se kernel: [700088.186627] [/etc/resolv.conf] opened by pid 19361 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)]My team uses a predefined hosts configuration and NO relay server, NO tracker server and NO DHT network. Let me know if you need more information.
  6. 1.3.109 fixed this. Thx a lot to improve the synchronization speed by this.
  7. @coreycauble: You might have been run into this: http://forum.bittorrent.com/topic/29870-suboptimal-performance-btsync-1394/ Workaround for me: Until this is not changed/fixed use small files instead of large ones. 7-zip is a nice tool to split such files into small parts.
  8. @RomanZ: I understood rtrpm-bittorrentsync that way that we he wants to avoid the situation that the seeder (the client with original file) has to send the same data chunks to more than one client in the network. I totally agree with this since this would be an optimum process with highest efficiency. But if the current logic of btsync just base on a pure polling mechanism where a client without the data dictates what chunks other clients have to send than this cannot be guaranteed. This in fact is the behavior I can see. In a perfect network the seeder would have to send the amount of data of a file only once by distributing the pieces in a disjunctive way to the clients in the network and these clients exchange the missing data among them without the seeder. With current implementation the seeder runs much longer than the required minimum of a single transfer time of the file. My experience is that if you compare the time a seeder would need to distribute a file in a pure sequential way (so any client would get the data by FTP i.e.) with the runtime btsync currently offers then the time saving is around 30% - 50% ... but this very depends on the file size and number of files to distribute.
  9. If you connected both Laptops with a LAN cable, the LAN-interface on each of the system also requires an IP address. So, what is the real IP address of the specific LAN-interface used by the cable? If these are Windows systems open a cmd window and invoke the command "ipconfig /all" to get this information.
  10. Thx a lot for caring. As a non-native English speaker I already feared that my description was too incomprehensible. Our workaround for now is to cut all large files to very small pieces by using archive programs like 7-zip.
  11. JimKnopf

    Improve Upload Balancing

    Currently the distribution of the available upload bandwidth to the other visible clients seems to depend more on the individual latency to each of the others than on the fact what upload bandwidth the other clients have. This could lead to the strange situation that the client with the smallest upload bandwidth to the internet gets the most data from all clients since it shows the best response time to them. For the main target namely to distribute the data to all clients as fast as possible, such behaviour is sub-optimal. It would be better and more fair to prefer those clients for upload bandwidth which themselves offer the most upload bandwidth to the others. This would guarantee a nearly optimal distribution speed. Example 1: If the local client knows remote clients A,B,C which have the individual upload bandwidth Ua, Ub, Uc on their site to the internet, the local upload bandwidth could be distributed by: full local bandwidth in percent to remote client X: 100 * Ux /(Ua + Ub + Uc), Ux is upload Bandwidth of Client X to the internet This would prefer the faster (stronger) remote clients which are more helpful to distribute the data as fast as possible. Example 2: Another algorithm could be to first pump all data to the client with the largest upload bandwidth until it is full then start filling the second largest ... and so. While the first seeder is filling later clients the best uploaders in the network could run in parallel at full upload speed. This is also near an optimal distribution regarding required time. Perhaps there are better/easier ideas to get near an optimal distribution algorithm.
  12. Hi RomanZ: Many thanks for your answer. No the download bandwidth cannot be a limiting factor since even the slowest internet connection has 14 Mbit download bandwidth capacity whereas the fastest internet connection only has 10 Mbit upload bandwidth. But your answer let me check the latency between my internet connection and the others. And really: The slowest internet connection shows the best ping round-trip times (used average of 100 pings). The member with the fastest internet connection showed the slowest ping response times. Comparing with the behaviour seen, the client order of getting finish with a very large file synchronization exactly matches with the order of ping latencies between the seeder and the clients. Sounds logic and is clearly a correlation but the effect is quite dramatic in real. Would be very cool and helpful if one could influence the upload bandwidth of the own btsync client to other clients. Best would be if the protocol would automatically determine the upload capacity of the other clients and trying to balance the local upload to them so the data distribution gets done as fast as possible.
  13. JimKnopf

    Removed Files Keep Being Readded/updated.

    My team has had a similar situation last days: One member was currently extracting data from a large 7zip archive (consisting of several files) in a shared folder and another deleted these files the same time at his btsync client. The effect was that all files every deleted at all clients except at the member's site currently accessing these files with 7zip. After the extraction this client started to re-synchronize these files again to the other clients sharing this folder. Just in case someone is interested how to reproduce this scenario. Most of us use 1.3.105, Windows and ARM platform.
  14. Perhaps I'm alone with my question and the most people don't care how this works. In case you're also interested in the answer to the questions I placed, please, express you curiosity by making a simple post to this thread. Thx in advance,
  15. Hi, can some of you explain to me how a btsync client decides what upload bandwidth will be used to the other members sharing the same secret? Background: When my team (consisting of 5 clients) shares data over the internet we can see at the seeder client, the system with the lowest upload bandwidth gets the most bandwidth from the seeder. "iftop" is a nice tool to check this on a Linux client. We have here the effect while transferring large data files that the clients with the smallest upload capability get ready first and the systems with largest possible upload bandwidth finish at last and this in a strict order! This is obviously the wrong order since it would be of course optimal to fill the client with the highest upload capability first so this resource can be fully used while distributing the data instead of waiting for the clients with the smallest capability to upload data to the others. But perhaps this simply bases on the understanding of the algorithm used and can be influenced somehow, so that's why I'm asking this question, here. Greetings from Germany