Ok, update:
Seems like rclone is heavily CPU bound on the VPS I was using. It was a quad core ARM. I’ve decided to test using a “C2L” server from Scaleway, and these are the speeds I’m getting from ACD to GSuite GDrive.
Transferred: 24.971 GBytes (70.762 MBytes/s)
Errors: 0
Checks: 2439
Transferred: 4
Elapsed time: 17m1.3s
Much better than the 12MBytes/s I was getting on the ARM VPS.
My system consists of a Intel 5930k overclocked to 4.5 GHz, 32GB RAM and a Samsung 950 Pro 512GB SSD for the system. I should not have any bottle necks there.
I’ve been reading a bit around the web, and there are multiple sources that claim that there is a hidden limit on the API. But then again… everyone should experience that.
Hmmmm, I don’t think there is any artificial limit. If that were the case, I would have topped out by now. 70+ MBytes/s is pretty decent. The quad core ARM VPS was 100% constantly while uploading. As soon as I switched to 8x Core x86, suddenly the 12 MBytes/s I was getting, disappeared.
Most posts I’ve seen seem to show a maximum of about 40 MBytes/s.
If I start a single upload, it stabilizes at 700 kB/s. If I start two at the same time, both of them are at 700 kB/s. 10 at the same time and all of them are at 700 kB/s each… I have more than enough throughput to surpass measly 700 kB/s many times.
In fact, I just tested from a different location with a different ISP (100/100 fiber). Same result… And this ISP is by far the best regarding peering, which also translates to it being the most expensive.
I don’t see any other explanation, than there’s a limit on my account. It’s a brand new business account created on their own website, so it’s not because it’s some cheap eBay account.
My GSuite account is also brand new, and legit. These are my current uploads:
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 66% done, 5.508 MBytes/s, ETA: 17m34s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 46% done, 3.068 MBytes/s, ETA: 43m32s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 41% done, 2.463 MBytes/s, ETA: 35m38s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 48% done, 2.935 MBytes/s, ETA: 46m6s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 98% done, 1006.355 kBytes/s, ETA: 5s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 42% done, 4.660 MBytes/s, ETA: 41s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 58% done, 3.905 MBytes/s, ETA: 26m54s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 58% done, 3.366 MBytes/s, ETA: 5s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 100% done, 1.730 MBytes/s, ETA: 0s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 54% done, 2.680 MBytes/s, ETA: 58s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 75% done, 3.364 MBytes/s, ETA: 10m0s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 23% done, 1.236 MBytes/s, ETA: 2h3m46s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 65% done, 7.398 MBytes/s, ETA: 26s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 37% done, 1.652 MBytes/s, ETA: 55m58s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 89% done, 3.068 MBytes/s, ETA: 13s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 53% done, 3.642 MBytes/s, ETA: 11m55s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 61% done, 3.078 MBytes/s, ETA: 43s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 42% done, 5.807 MBytes/s, ETA: 34s
*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: 85% done, 943.643 kBytes/s, ETA: 55s
It seems strange that you would be capped. Could it be something to do with a firewall or something? If each of your uploads is being limited to exactly 700 kB/s, then maybe something is capping each upload individually?
Only windows firewall, but rclone and rclone browser are added as allowed. It also wouldn’t make sense that it would allow a little bandwidth. It should be all or nothing if that were the case. With or without encryption doesn’t matter through Rclone, I only get 700 kB/s in both cases.
I just tested from my NAS… 15 MB/s (same ISO-file I test with in all cases). I think Bubbles said it best: “Something’s fucky”.
I don’t get it. Multiple different ISPs and in all cases it’s 700 kB/s. My NAS can push 15 MB/s with its measly ARM processor. The only common denominator for the issue here is Rclone.
Very strange indeed. Old rclone build maybe? 1.36 here.
I know this is going to sound really stupid, but you could temporarily boot from a Linux Live USB, install rclone and test again?
I’m just wondering if it’s a Windows limitation, as you said your NAS seems to be ok. My Linux box doesn’t seem to have any issues either. I’m wondering if it’s Windows reserved bandwidth…
I’m using Rclone v1.36 and Rclone browser 1.2. When I was using ACD I could usually get 5 MB/s per thread, so that would suggest that the OS itself is not the issue. I will try the LiLi when my newborn allows it 
Are you using standard configuration of the “transfer”-tab?
I’m wondering if my 60 character password and salt could be to blame. Gonna do some more testing without encryption.
Mine is just a simple one liner:
rclone sync -v --transfers=20 source:/ destination:/
There is a little scripting, but nothing out of the ordinary.
I hear you. It just seems very odd that your main machine with all that power is having the issue, but your NAS doesn’t. It’s begs the question is all. If we can eliminate the OS as the source of the bottleneck, then at least it means we can definitely look elsewhere.
PS. Gratz on the newborn. I don’t envy the late nights. I remember them well 
Could be related to this? Try a lower version?
I don’t think so. It is possible, but 1.36 on my Linux box isn’t suffering from this issue.
Just tested - same result sadly.
Read somewhere that IPv6 could be an issue, but it’s already disabled on my NIC. Also tried enabling jumbo frames, just for the hell of it… no change.
Tried disabling windows firewall completely… no change.
Anything out of the ordinary here?
2017/05/24 18:28:48 DEBUG : Using RCLONE_CONFIG_PASS password.
2017/05/24 18:28:48 DEBUG : rclone: Version "v1.36" starting with parameters ["C:\\RClone\\rclone.exe" "--config" "C:/RClone/rclone.conf" "copy" "--transfers" "8" "--checkers" "8" "--contimeout" "60s" "--timeout" "300s" "--retries" "3" "--low-level-retries" "10" "-v" "--stats" "1s" "X:\\SW_DVD5_Win_Pro_7w_SP1_64BIT_-2_MLF_X17-59256.ISO" "GD:"]
2017/05/24 18:28:48 INFO : Google drive root '': Modify window is 1ms
2017/05/24 18:28:48 INFO : Google drive root '': Waiting for checks to finish
2017/05/24 18:28:48 INFO : Google drive root '': Waiting for transfers to finish
2017/05/24 18:28:49 DEBUG : SW_DVD5_Win_Pro_7w_SP1_64BIT_-2_MLF_X17-59256.ISO: Sending chunk 0 length 8388608If you have a bunch of small files, it tends to be pretty crappy the small files seem to delay each other not sure why. I’ve found 15 upload w/100 checkers gets me the best speed with the cheapest google cloud compute,
In my case it’s a single ISO-file at about 2.8 GB.
I tested on three other systems and two other ISPs - all with same result. I’ve deleted everything and started again from scratch, but same result. I’ve tested with and without encryption.
Got a friend to test on his account, on yet another different ISP on Win10. Same issue.
Working as intended…
"Regarding your drive, this is an expected behaviour, it is an automatic traffic shapping on the data content that you upload. I suggest you focus on one task at a time to maximize the speed on that particular upload.
We appreciate your patience with this,
Have a lovely day,
Alex
Google Cloud Support"
Did you find a solution ?
Submitted a new ticket to Google. I’m not taking the “expected behavior” as an answer.
Okay, so Google support have replied.
I wanted to thank you for your comprehension regarding the third party app matter. I’d really like to be able to determine whether there are issues with Drive and third party apps, regarding the speed of upload and download, however, I was making a research to try to find out if there was something related to a delay between Rclone and Drive. Unless we have in mind that, since ISP is connecting to the Google servers through a third party app the whole environment delays since the protocol they use has to confirm that it has already de information that is going from the first channel, the second channel confirms it has the data and sends it to the third and final destination which also has to confirm that it has it.
Regarding the traffic issues, I’ve already confirm that within the Google servers there’s no traffic issues. After reviewing our records, I was not able to find any report about Rclone causing delays while uploading/downloading files, since it is out of our scope of support. However you can consider using our Drive Sync app if you’d like to sync your files from My Drive to your computer.
Considering Google’s response and the fact that I’ve tested Rclone on five other computers and four different ISPs, more and more suggest that there is an issue with Rclone.
I give up… It’s definitely a problem with Rclone. Seeing that there are many hundreds open issues with Rclone, I’m gonna drop it.
I’ve now tested GoodSync and it works just fine. Encrypts everything and I get 15 MB/s. Better UI as well.
It could also be a problem with windows 10 and until you know where it is, its hard to just say its rclone…
Just for grins try disabling “Large Send Offload” (and/or tcp segmentation offload) on the NIC (network card properties). I’ve had an Intel Card act really wonky until I turned this off. You may want to fully disable Window 10s QOS and reserved bandwidth even though you appear to be getting full speed using the GUI and other methods.