It looks like my rclone is limiting each file transfer to ~12MB/s. Even when transferring one large ~35GB file the limit is the same 11-12Mb/s. Downloading multiple files lets me get to around 40 Mb/s, each one at 11-12.
Tried with 1.36 to newest 1.41, is there some default setting I don’t know about?
SYS server 18.04 brand new as of today. I have a 16.04 server from SYS running the same rclone version that doesn’t have this speed issue.
You can try upload to other service as S3 to check the limit is of gdrive (api) , or your connection
That is very likey the provider, not rclone… Which provider?
If you are using google drive, then try
--drive-v2-download-min-size SizeSuffix If Object's are greater, use drive v2 API to download. (default off)
Something like --drive-v2-download-min-size 100M - that might help.
Google drive, With an plexdrive ENC mount then rclone to decrypt.
Using the v2 flag doesn’t help, and pulling the encrypted file also seems the same speed.
Using rsync from the cloud mount I can pull 10-17, but most of the time its around the 11/12 MB/s mark.
I’m also noticing a recent slow down downloading from GDrive. It used to max out my bandwidth at 40+MB/sec but recently (last day or so) I’ve been averaging around 8MB/sec. This is for downloading a single file. Speed tests show I still have full bandwidth available.
Perhaps Google has started bandwidth throttling?
Also: Fatal error: unknown flag: --drive-v2-download-min-size
$ rclone -V
rclone v1.43.1
You need the latest beta
I just wiped my old server that was getting 30Mb/s and imaged it for 18.04 on SYS and it appears to have the same issue now. Putting it back to 16.04 gives me the full speed (once I bind it to ipv4)
Is there some issue with 18.04 or the new network interface that isn’t eth0? My different interface is enp4s0
Tried the latest beta with the --drive-v2-download-min-size flag and same results. I also tested on another machine on a different network with v1.38 and got similar results, maxing at around 10MB/s.
Will try to test with other providers and see if we can narrow it down to a GDrive specific issue.
Ran some download tests from a Windows VM on Azure. I saw it peaking over 1Gbps, but then the bandwidth meter in Task Manager was stopping and starting, like it was downloading in bursts. On about the third or fourth test of downloading a single file, I ran it with -vvv and saw a 403 rate limit message. Also tried latest beta with the v2 flag and it didn’t seem to make a difference.
Are you using your own API key? You shouldn’t get any 403s copying a single file as that doesn’t make sense.
I also don’t get bursts. I get a consistent download over multiple tests. There only limit I’ve seen is the V3 API limit on a single file download.
Just set up a gdrive api key, same results.
Also just tried a single large file from OneDrive and getting pretty much the exact same speed.
Finally, tried downloading a file from GDrive web interface in chrome and it maxes out my bandwidth.
Starting to look like a possible issue with recent rclone version.
Why? I’m using the same version and can max it out doing the same tests you. It seems to be your setup rather than rclone.
Well it just seems strange that the issues only started a few days ago when I updated to the latest version. And it’s happening on multiple different computers on multiple networks.
Are you using the official version downloaded from rclone.org or building from source?
I ran my tests on the latest version and the latest beta (you need the beta for the v2 flag).
Note that the web interface uses a different (private) API with different endpoints to rclone…
My issue was fixed by downgrading to 16.04 on my SYS server if anyones on OVH try that.
At home 16.04 and 18.04 made no difference in speed, only on the OVH hosted server.
Sure, I was just trying to verify if there was any connection issue to gdrive in general.
Anyway, confirmed the issue is not with rclone. I was able to max out bandwidth from a different machine (Windows 10) on my same network.
The slow machine is running Ubuntu 18.04 which lines up with @nreymer experience, so I’m guessing a recent update to some package is the cause.
