sebijisi

Members
  • Posts

    8
  • Joined

  • Last visited

  • Days Won

    1

Recent Profile Visitors

326 profile views

sebijisi's Achievements

New User

New User (1/3)

  1. Did not find any mention, but do you plan to support newer QNAP ARM-based NAS? Upgraded NAS, lost Resilio .... I have one with with Annapurna Labs processor, but the package for the older x31 NAS does not install. I have a TS-332x. https://www.qnap.com/en/product/ts-332x I think it has a "newer" (not that A57 is all that new....) 64bit core compared to the older Annapurna Labs machines: [/proc] # cat cpuinfo processor : 0 model name : Annapurna Labs Alpine AL324 Quad-core ARM Cortex-A57 CPU @ 1.70GHz Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part : 0xd07 CPU revision : 3 processor : 1 model name : Annapurna Labs Alpine AL324 Quad-core ARM Cortex-A57 CPU @ 1.70GHz Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part : 0xd07 CPU revision : 3 processor : 2 model name : Annapurna Labs Alpine AL324 Quad-core ARM Cortex-A57 CPU @ 1.70GHz Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part : 0xd07 CPU revision : 3 processor : 3 model name : Annapurna Labs Alpine AL324 Quad-core ARM Cortex-A57 CPU @ 1.70GHz Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part : 0xd07 CPU revision : 3
  2. I get the feeling this is a limitation of BTSync not being able to sync large amount of files. The best I manage to do with a medium sized share (16GB, 16k Files, various sizes) was around 2 MB/sec, which will occasionally drop to less then 1 MB/sec in the "sawtooth" pattern described here. No matter it is local or remote or TCP or UDP. However when I add the share I originally want to sync (400GB, 420k Files, Most 8MB), it never goes over 1 MB/sec. Also, when the large share is added to BTsync, even when syncing is paused, the medium sized share mentioned above will also not go over 1 MB/sec. I am not sure I am CPU bound. One machine is an oldish Core 2 DualCore, the other a Dual Core (4T) Cedarview Atom. While BTsync has significant impact on CPU, the CPU usage for both machines is not nearly maxed out under the conditions lined above. Is there something in BTSyncs architecture that prevents it from syncing large collections? Some event-processing/thread locking limitation? Some scaling problem with a large number of files? Did anybody ever saw BTSync achieving or surpassing 100MBit/s when the files are large enough? Also I did notice some largish sqlite3 database (536 MB) created by btsync. And it seems to have no indices. However, as I do not know whether they are read or written more often I do not know whether this could be a performance problem. Just worked a lot with sqlite3 before, and noticed that it can go from awesome! to yuck! pretty quickly once there is a lot data in it.... I did try the "speed profile" thing for a few minutes, but it just collected 10 MB of data I can not interpret by myself
  3. Ok, it turns out I do not know how tu use iperf... UDP requires to set a sending rate. As in iperf -c <IP> -u -b 20mif you want to check 20 MBit. Turns out the host is still slower in UDP: Around 20-25 MBit, afterwards the dropped packet rate skyrockets. However, this does not explain BTSyncs << 10Mbit speeds. As for now I am trying with a TCP-OpenVPN that tunnels BTsync traffic directly to the machine. However as the Mac cleint exploded on me, and after crashing restarted indexing (and even asked a new identity and restarted the 30 day trial), I can not yet say what the results will be. For the time being the receiver still throws millions of [20150316 15:55:27.718] 10.8.0.6:59696: did not pick any blocks. blocking peer temporarily[20150316 15:55:57.593] Disconnect: Is seed[20150316 15:55:41.725] Disconnect: Timeout due to inactivityinto the log
  4. Hi, just read the thread. I have also been having serious speed issues syncing to a host across the internet. I tried everything and cursed BTsync to the moon and back. I think I just confirmed in my case it was not BTsync's fault.It was really is a problem with UDP traffic being throttled (heavily!) along the way UDP iperf -c <ip> -u------------------------------------------------------------Client connecting to <IP>, UDP port 5001Sending 1470 byte datagramsUDP buffer size: 208 KByte (default)------------------------------------------------------------[ 3] local <ip> port 44731 connected with <ip> port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec[ 3] Sent 893 datagrams[ 3] Server Report:[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.035 ms 0/ 893 (0%)The same pair of hosts using TCP iperf -c <IP>------------------------------------------------------------Client connecting to <IP>, TCP port 5001TCP window size: 85.0 KByte (default)------------------------------------------------------------[ 3] local <IP> port 50024 connected with <IP> port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 112 MBytes 93.8 Mbits/sec So my first question is: Is there a hidden option to force the sender to use TCP (or the receiver to request TCP connections from senders?), or is it at the moment only available in custom test builds? I think it is of general interest, because in this case it is a limitation of the network the receiving server is in (I got the same iperf results sending from two different networks) . It is hosted in an OVH datacenter (a french provider, pretty big in the EU), and I guess it might be related to their DDoS protection stuff. However, this is just a lucky guess as this is my first OVH hosted host I am not very familiar with their network. Anyway, I suppose there will be quite a few people renting el-cheapo servers as secondary offsite backup, that might run into this problem. I hope my post will make it at least googleable. But can almighty RomanZ maybe even solve it ?
  5. In fact in my current usecase I do not need more than 10 folders, HOWEVER the only reason I came to the forum/this thread today, was looking at the "Pro/Free" comparison, seeing the "Unlimited folders" for PRO, immediately thinking "Wow, despite what they said earlier, they really screw us". So yeah, I think this is not a good idea. As for the one time payment vs. Subscription-model: I understand, that software development needs to be continuously founded, so I rather have an "honest" subscription model, instead of a "one-time" fee and a paid upgrade to more awesome, not 100% compatible "Sync 3.0" a year later. However the price is really steep for what it is. If you do not want to go into the business of selling cloud storage yourself, just make a license like this that a commercial cloud storage provider for btsync needs to pay you license fees. Like 0.1 ct/GB/month rent to one of their customers comes flowing back your way.
  6. Have 1.4 on all devices although I complained loudly about the ridiculous interface. But as this is beta, and definitely has rough edges and probably some data-eating corner-cases I guess those will be fixed addressed in the 1.4 branch. Also I use Macs and Linux (xattr. issues) What is most unnerving are the "A HTML GUI makes multi-platform easier" argument: No Sirs, it does not. Everyone who builds websites that need to run on multiple renderers knows it. And in the end, the result will, well, look like the BTSync GUI. But I think bitching about this doesn't change anything, as it depends on the team developing it and their preferences. Theory: For example, maybe they only have a few developer they need to work on the code, and then a bunch of web developers. So the © developers can focus on the core and the web guys (JS) can take some burden away baking the prototype GUI. Maybe it makes development faster... I do keep an eye on SyncThing, but jumping from one beta product to another beta (alpha?) product just because I have anger issues with the GUI probably is not the wised decision. I will wait and observe....
  7. +1 want a nice, small, informative UI along the lines of the 1.3 OS X GUI. It should look native, but I guess with QT it could really be cross-plattform. Should even be easier to maintain than maintaining an ugly CSS/JS monster that needs to wok with different browser engines on all systems....
  8. Hi, Please understand I just registered because I DO love the BTSync concept, and besides some (to-be-expected) Beta bugs it is already working reasonably well. But when reading this I do not know how bad the Windows GUI was, but the OS X one for 1.3 was pretty okayish. Compared to this the new one is -and this is really the most polite way to put it- unintuitive, uninformative, ugly and generally a waste of space. Even as a longtime user it is not clear where to click, and it seems a lot of information that was there before is not accessible at all. So at least for OS X, can we please get the old GUI back? Or just release a commandline-only version just as for Linux. Maybe there is a chance to get/build a usable third-party GUI? I do not know whether the API is powerful enough or that... Did the old GUI use the API? Maybe just release the GUI part as open source? At the current state I can barely recommend BTSync to "normal" OS X users (it was ok before). So please do not take this as a personal offence. I wouldn't have taken the time to write it, if I did not like BTSync. I just hope this can be repaired Peace