No. That's not a normal upload speed. You have either a bottle neck somewhere or a poor pairing with Google. Or something odd like a ip6 issue or network errors.
It's best to use the question template for any questions.
You are using a bleeding edge kernel so I'd avoid that and use something stable.
You'd want to grab the latest version and use that.
You'd want to post a full transfer log and see what's going on.
If you are mainly transferring large files, you can increase that to 128/256/512/1024M depending on your system specs.
Producing a full log would take an hour.
Is there any information printed at the end that would be useful?
Because it seems to me it's just the same output for each chunk transmitted, so I would let it run for an hour for no extra information...
I've created a full log now (for a slightly smaller file), as I expected there is nothing there that could not be gleaned from just looking at the first stanza.
Here the beginning and the end:
2020/04/20 08:17:25 DEBUG : rclone: Version "v1.50.2" starting with parameters ["rclone" "copy" "-vvv" "testfile.mp4" "gdrive:" "--log-file=out" "--drive-chunk-size" "128M"]
2020/04/20 08:17:25 DEBUG : Using config file from "/home/mh/.config/rclone/rclone.conf"
2020/04/20 08:17:25 DEBUG : gdrive: Loaded invalid token from config file - ignoring
2020/04/20 08:17:26 DEBUG : gdrive: Saved new token in config file
2020/04/20 08:17:26 DEBUG : testfile.mp4: Need to transfer - File not found at Destination
2020/04/20 08:17:26 DEBUG : testfile.mp4: Sending chunk 0 length 134217728
2020/04/20 08:18:25 INFO :
Transferred: 21.152M / 218.811 MBytes, 10%, 364.767 kBytes/s, ETA 9m14s
Errors: 0
Checks: 0 / 0, -
Transferred: 0 / 1, 0%
Elapsed time: 59.3s
Transferring:
* testfile.mp4: 9% /218.811M, 359.316k/s, 9m23s
2020/04/20 08:19:25 INFO :
Transferred: 41.684M / 218.811 MBytes, 19%, 357.546 kBytes/s, ETA 8m27s
Errors: 0
Checks: 0 / 0, -
Transferred: 0 / 1, 0%
Elapsed time: 1m59.3s
Transferring:
* testfile.mp4: 19% /218.811M, 330.007k/s, 9m9s
(and so on)
2020/04/20 08:27:25 INFO :
Transferred: 208.590M / 218.811 MBytes, 95%, 356.360 kBytes/s, ETA 29s
Errors: 0
Checks: 0 / 0, -
Transferred: 0 / 1, 0%
Elapsed time: 9m59.3s
Transferring:
* testfile.mp4: 95% /218.811M, 359.878k/s, 29s
2020/04/20 08:27:57 DEBUG : testfile.mp4: MD5 = 183f78cb6831a02c7b2daac6a027c625 OK
2020/04/20 08:27:57 INFO : testfile.mp4: Copied (new)
2020/04/20 08:27:57 INFO :
Transferred: 218.811M / 218.811 MBytes, 100%, 355.008 kBytes/s, ETA 0s
Errors: 0
Checks: 0 / 0, -
Transferred: 1 / 1, 100%
Elapsed time: 10m31.1s
2020/04/20 08:27:57 DEBUG : 5 go routines active
2020/04/20 08:27:57 DEBUG : rclone: Version "v1.50.2" finishing with parameters ["rclone" "copy" "-vvv" "testfile.mp4" "gdrive:" "--log-file=out" "--drive-chunk-size" "128M"]
That seems to be a snippet of the log and not the full log.
A general tip as when you have someone using their time to help you out with a problem, why fight them?
Can you just post the full log?
I asked for the kernel because if you search the forums, there are numerous issues with the newer kernels due to async reads in the new kernels. Those tend to show up in the full logs and if not, it is another thing that can be ruled out.
I'm assuming when the transfer is happening, you have sufficient bandwidth on the system and you've checked for CPU/Disk/Memory items already as well.
My general speeds are maxing out my gigabit using rclone/Google drive when I uploaded:
Transferred: 54.635G / 54.635 GBytes, 100%, 86.967 MBytes/s, ETA 0s
Transferred: 246.518G / 246.518 GBytes, 100%, 88.866 MBytes/s, ETA 0s
Transferred: 228.247G / 228.247 GBytes, 100%, 91.020 MBytes/s, ETA 0s
Those are my last 3 days as an example. I use primarily defaults minus a very large drive-chunk-size of 1024M since I have a machine with 32G of memory on it and no constraints.
You are also using 1.50.2 and you can upgrade to 1.51 and produce a log.
Did you check network errors? traceroute? See if you have intermittent issues along the network route? Are you hosting on a VPS? Perhaps you're being throttled by your or your VPS provider? Perhaps try a VPN? Hardcode some IPs mapping too google servers and try different ones. Use a different DNS provider (like google or cloudflare) to see if you get different results? Are you okay on memory? Disk i/o? CPU?
I don't mean to sound insensitive. But if you ask for help, you kind of need to be ready to provide information necessary for people to help you. The things I mentioned do help in figuring out what is wrong and where the bottle-neck is. No one knows what configuration you have or what you're running. If you'd like help, then most folks on here would be glad to help.
I was asking you to actually 'try' a vpn.
That isn't neccessarily a good or bad thing. The question is around peering here.
Top gives you CPU resources. It doesn't tell you a lot of information on much else like if your disk is busy. Perhaps you have a I/O bottleneck. We don't know.
In my observation its pretty predictable. Its the OS/network/Google API that can be unpredictable.
I don't see any detail you've actually given anyone to help. All we know is you run a command and you're not happy and you're running version 1.50.2 without a vpn and with google DNS.
Bypassing traffic shaping. QOS. If it was targeting https or rclone.
Not a lot. You can change your dns and see if you get different ip targets for the API or potentially hardcode them in your hosts file.
Can you run traceroutes to the Google api ip and see if you're seeing network issues?
Are you on a vps? Or on your home network? If your on your own network is there another computer (perhaps even different enough OS) you can use to see if you see the same low performance?
Do you see higher speeds using other programs like curl? You can try: