Inconsistent Speed

[MaximoFrei]

@MaximoFrei

I suspect that saw-shaped traffic in your case is a result of losing UDP packets. For how long it takes Sync to transfer your file comparing to FTP?

 

Also, let me know if you are willing to test an experimental build.

On a 900MB file via FTP it takes 4 minutes, through BTSync it takes 5.

Per 10GB it's over a 10 minute difference using BTSync.

I'd be happy to test an experimental build.

[RomanZ]

@MaximoFrei

 

I've sent you experimental build. Let me know if it helps.

[alx49]

Hi,

 

I have the issue that is similar to topic starter in 1.4.103, could you help me please.

 

I have 2 nodes (linux and windows), located in different cities. Both have btsync 1.4.103. I send 4-5 Mb files from linux machine to windows. 

 

In logs(linux) I have following line

[20150201 12:45:55.807] SF[EA5D] [FEA5]: Found peer 100...A5 92.37.xx.xx:59365 direct:1 transport:1 version: 1.4.103, where IP corresponds to windows machine.  Also I see a lot of following snippets:

[20150201 12:54:34.020] SF[EA5D]: UpdatePeersStat[20150201 12:54:34.021] SF[EA5D] [FEA5]: up:10940972432 down:0[20150201 12:54:34.021] ScheduledTask:UpdatePeersStat invoked:timer reason:UpdatePeerFileInfo[20150201 12:54:35.339] Incoming connection from 92.37.xx.xx:59365[20150201 12:54:35.339] SF[EA5D] [FEA5]: Received request "state_notify"[20150201 12:54:35.339] SF[EA5D] [FEA5]: Got state notify - tree:77xxx1E pieces:3Dxxx90[20150201 12:54:36.079] SF[EA5D] [FEA5]: Going to sync state with peer 92.37.xx.xx:59365[20150201 12:54:36.079] ScheduledTask:SyncState invoked:timer reason:OnReceivedStateNotify[20150201 12:54:37.379] MC[EA5D] [FEA5]: generating intial request with root 77xxx1E[20150201 12:54:38.395] SF[EA5D] [FEA5]: Received request "id"[20150201 12:54:38.395] SF[EA5D] [FEA5]: Got id message from peer МАМА-ПК (10xxxA5) 1.4.103[20150201 12:54:38.395] SF[EA5D] [FEA5]: Received request "peers"[20150201 12:54:38.395] SF[EA5D] [FEA5]: Received request "root"[20150201 12:54:38.395] MC[EA5D] [FEA5]: processing root message, remote hash 77xxx1E, timediff: -88[20150201 12:54:38.395] SF[EA5D] [FEA5]: State sync finished[20150201 12:54:44.245] SF[EA5D]: UpdatePeersStat

Speedtest on windows machine (slowest one)

 

 

I expect to see constant speed about 350 Kbite/s, but in fact I see following:

After daemon restart:

Few minutes later

Few minutes later

 

or

 

As a result average speed is about 100-150 kbite/s.  Could you help me to find the problem?

 

Thanks in advance!

 

UPD. I have absolutely the same issue with one large file (3.5G)

Edited February 1, 2015 by alx49

[RomanZ]

@alx49

I've sent you an experimental build to your e-mail box. Let me know your testing results.

[hiphop03199]

I was just about to make a thread as well but noticed this has already been brought up as an issue. I wanted to report that I encounter a saw-tooth traffic pattern nearly every time I use BTSync. My image is unlikely to be as useful as the others posted above, but I'm happy to provide more details about my current set up if that is helpful (let me know what you'd like to know/see). The timespan in the image is  a five-minute window. My connection is 100mbps down/6mbps up. The tip of the sawtooth appears to often be when the download speed hits the 100mbps mark, and then it appears BTSync backs off by dropping to nothing at all.

 

[RomanZ]

@hiphop03199

I've sent you experimental build. Let me know if it helps.

[b0rman]

Same problem here.

1Gbps LAN PCs (i5 2500 / SSD / 32GB DDR3, lots of resources as You can see.), speed is around 50-150 kBps

v1.4.110

Seems like buffers doesn't matter at all.

Any ideas?

[RomanZ]

@b0rman

What kind of files do you transfer? Sync has a certain limitation on amount of files it processes per second, so if you've got a bunch of tiny files - they can affect transfer speed significantly (though should not introduce saw-shaped traffic).

[b0rman]

@b0rman

What kind of files do you transfer? Sync has a certain limitation on amount of files it processes per second, so if you've got a bunch of tiny files - they can affect transfer speed significantly (though should not introduce saw-shaped traffic).

Yes, I have 9GB of JPEGs less than 25KB each.

 

Any ideas how to improve my situation?

May I change this limitation since my PCs have lots of free resources and I'd like to use it to increase sync speed?

Is it possible to add this variable to config file?

[RomanZ]

@b0rman

Unfortunately this cannot be changed, it's not simply limited by some variable but this is more core limitation. We are aware of it and plan to improve in future.

 

Although, if you got average file size ~25Kb you should get your speed around 1.2 Mb/Sec, so the 50..150 Kb/sec is way too slow! Could you please send me some debug logs of your regular sync of these small files?

[b0rman]

@b0rman

Unfortunately this cannot be changed, it's not simply limited by some variable but this is more core limitation. We are aware of it and plan to improve in future.

 

Although, if you got average file size ~25Kb you should get your speed around 1.2 Mb/Sec, so the 50..150 Kb/sec is way too slow! Could you please send me some debug logs of your regular sync of these small files?

 

Debug logs:

 

https://mega.co.nz/#!1VtilTTY!C_MybxPia3DgdEpRX-MoUExqBBMCXW8KHLU9P506JKE

 

https://mega.co.nz/#!YEESATSS!xaMB51qhucajCMgOWT42ooySM3cAC7ig1Qn4_uoWsvg

[RomanZ]

@b0rman

Thanks for the logs, I'll let your know analysis results.

[b0rman]

@b0rman

Unfortunately this cannot be changed, it's not simply limited by some variable but this is more core limitation. We are aware of it and plan to improve in future.

 

It will be awesome to see it in config some day

[adinunzio10]

Hello All,

 

I seem to be having same/similar problem, and reading through here can't really seem to find anything to help my situation.

 

When I download off rutorrent (seedbox) via chrome, I can usually get ~14MB/s.

 

But with BT Sync, the max I get is 3.3, after it hits 3.3, it drops back down to ~.5 and then increases back to 3.3 rinse and repeat until download is complete. 

 

What could be going on that causes this to happen only in BT Sync? 

 

I am downloading a single 3.5GB file.

 

Have also tested with multiple 50MB files. 

 

Note that I am using 1.4.106 Beta

 

All below data is shown from the single 3.5GB file, can record data from multiple 50MB if requested, but I believe it will be identical. 

 

BT Sync:

 

 

Chrome:

 

 

 

 

Edit: Multiple edits to add graphics, modify text.

 

Edit2: I did some further testing, I wanted to see if i limited send data on server to 3000kbs if it would stay there instead of crashing, except when I did that, it wouldn't even get past 1.3mbps before dipping back down , I turn off limit, and back to 3.3 before dipping back down. I decided to set a receive limit on my PC of 3000kbs, that worked except after getting to 3, it crashes back down to >1. So no matter what, cannot hold a consistent download, nor a max speed download. 

 

Edit 3: added speed test of home connection

 

 

and speed test of seedbox using home connection

 

Edited February 19, 2015 by adinunzio10

[RomanZ]

@adinunzio10

Just to make sure I understand your setup correctly:

 

- You are transferring a single file ~3.5Gb from your seedbox to home computer over internet

- Home computer has a bandwidth of 134Mbytes for download and 9.9MBytes to upload data.

- seedbox has bandwidth of ~10.6 MBytes for upload.

 

With this setup, when you download 3.5Gb file with chrome - you get 14Mbytes/sec

When you get it with Sync you get saw-shaped speed traffic which never transfers faster than 3.3Mbytes/sec.

 

Is this correct or I'm missing something?

[adinunzio10]

@adinunzio10

Just to make sure I understand your setup correctly:

 

- You are transferring a single file ~3.5Gb from your seedbox to home computer over internet

- Home computer has a bandwidth of 134Mbytes for download and 9.9MBytes to upload data.

- seedbox has bandwidth of ~10.6 MBytes for upload.

 

With this setup, when you download 3.5Gb file with chrome - you get 14Mbytes/sec

When you get it with Sync you get saw-shaped speed traffic which never transfers faster than 3.3Mbytes/sec.

 

Is this correct or I'm missing something?

 

Hello yes you are correct, not missing anything. I could get results from other software like FileZilla or CuteFTP, but just wanted to show its only BT Sync that does the saw-shaped speed traffic. I asked my seedbox if they know why, they didn't but they suggested to try rsync (they were also the one to suggest me trying BT Sync in the first place)  haven't tried yet though as I haven't had much time and was hoping this would fix it's self or I would get a response.

Edited February 21, 2015 by adinunzio10

[adinunzio10]

@adinunzio10

Just to make sure I understand your setup correctly:

 

- You are transferring a single file ~3.5Gb from your seedbox to home computer over internet

- Home computer has a bandwidth of 134Mbytes for download and 9.9MBytes to upload data.

- seedbox has bandwidth of ~10.6 MBytes for upload.

 

With this setup, when you download 3.5Gb file with chrome - you get 14Mbytes/sec

When you get it with Sync you get saw-shaped speed traffic which never transfers faster than 3.3Mbytes/sec.

 

Is this correct or I'm missing something?

 

 

Cannot edit my past post. Wanted to update that I am still using BT Sync and I have not had time to do any troubleshooting. I noticed it is getting as high as 3.6 or 3.7 before dipping down, but the results are still the same. 

[RomanZ]

@adinunzio10

If you get a chance for testing - I can provide you an experimental build which prefers TCP when transferring over Internet. Let me know if you are interested to test.

[adinunzio10]

 

@adinunzio10

If you get a chance for testing - I can provide you an experimental build which prefers TCP when transferring over Internet. Let me know if you are interested to test.

 

 

Yeah, thanks! I would be willing to test that and compare results from stable to experimental builds. I am off work today and tomorrow, so if you get back to me I will probably give that a go this weekend. 

[JasonB]

I have a very simple use case. I'm using BitTorrent Sync to sync files between my desktop PC and my Android phone across the LAN (nothing internet at all). 

 

I have an Asus RT-AC68U router and I have the listening port specified in Advanced Preferences configured for port forwarding to the desktop PC IP in the router. 

 

I'm connected via Wifi to the 5Ghz side of the router and with the phone sitting next to the PC and showing a 433Mbps WiFi connection speed when using BitTorrent Sync I get 500 KB/s which seems way low. 

 

I'm gathering log information on a transfer I'm completing this morning. Please let me know where I can send it and I'll be happy to provide it.

Edited February 28, 2015 by JasonB

[RomanZ]

@adinunzio10

I've sent you experimental build, let me know your testing results.

 

@JasonB

First of all - could you please share info on what amount of files do you sync and what is the average file size?

[JasonB]

@RomanZ Generally I'm transferring just 2 or 3 700MB to 1.1GB files each day. 

[RomanZ]

@JasonB

Okay, so it is not a multiple tiny files issue. If you are transferring to your PC, please follow this instruction to collect speed profiling information. If you are transferring to your Android device - it might be a bit more complex and I suggest checking the issues is not in Android storage slow speed (i.e. try to deliver file with other means over network and save it to same location - does it have higher speed?)

[adinunzio10]

@RomanZ

 

 

 

Above screenshot is using experimental build and is transferring a ~1GB file over BT Sync, at a solid 15mbps Which is awesome!

 

Below screenshot is also using experimental build and is transferring series of smaller files (about 50MB each)

 

From the looks of it, it is reaching about 10-12mbps and the file is completing, in which it dips down, and quickly jumps back up to the next file, not constant, but still not a problem as it seems to only dip down when moving on to the next file, just thought i'd share. 

 

 

either way I am very happy, it seems the TCP transfer is a lot better. 

[RomanZ]

@adinunzio10

Thanks for your feedback. We'll address the issue when we collect enough info. If we need more information - i'll drop requests to this topic or directly to you.