Is Google Drive using QUIC? If so, then its using the same BBR congestion algorithm as the bbr tcp stack, and BBR's algorithm which does not view loss as congestion will help a lot.

It would be interesting to re-try the experiment on Linux or FreeBSD using BBR as the TCP stack and see if the results are any better for dropbox.

FWIW, my corp openvpn is kinda terrible. My upload speeds via the vpn did not improve at all when I moved and upgraded from 10Mb/s to 1Gb/s upstream speeds. When I switched to BBR, my bandwidth went from ~8Mb/s -> 60Mbs, which I think is the limit of the corp vpn endpoint.

Looking at the flows on my network while uploading a file, it seems Google Drive's mac client just uses regular old TCP, same for the website.

QUIC is UDP, and TCP does not use CCA in userspace.

QUIC absolutely uses congestion control. See section 6 here https://tools.ietf.org/id/draft-ietf-quic-recovery-26.html

No denying in that.

QUIC does run in user space, and also uses congestion controllers running inside the QUIC stack, in user space.

(I work on a QUIC implementation in Rust.)

QUIC is a protocol... "...CCA in userspace" CCA stands for congestion control algorithm.

Strange. Dropbox has no problem hitting mid-50s MiB/s if not more on my gigabit connection. I wonder if it's a routing issue and your path to their datacenters is bad?

It uploads fine with web version, so I doubt it's a routing issue (granted, they could use different datacenter.)

Interesting, can you try disabling upload limiter in settings? Also what is your RTT to `nsf-1.dropbox.com`?

PS. One known problem that we have right now is that we use a multiplexed HTTP/2 connection, therefore:

1) We rely on the host's TCP congestion. (We have not yet switched to HTTP/3 w/ BBR.)

2) We currently use a single TCP connection: it is more fair to the other traffic on the link but can become bottleneck on large RTTs.

Tried to change upload speed to no limit, doesn't make much difference.

Ping result:

  Pinging nsf-env-1.dropbox-dns.com [162.125.3.12] with 32 bytes of data:
  Reply from 162.125.3.12: bytes=32 time=27ms TTL=55
  Reply from 162.125.3.12: bytes=32 time=27ms TTL=55
  Reply from 162.125.3.12: bytes=32 time=27ms TTL=55
  Reply from 162.125.3.12: bytes=32 time=27ms TTL=55

  Ping statistics for 162.125.3.12:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
  Approximate round trip times in milli-seconds:
   Minimum = 27ms, Maximum = 27ms, Average = 27ms

App Ver. 122.4.4867

Is the OS being Win7 a factor? (Work computer, can't update [yet]).

Download speed is normal (100Mbps).

Oh, Windows 7? That does explain it. Windows TCP stack really improved in 8.1. The main change there is the auto send buffer tuning which allows automatic growing of SNDBUF. Let me see if we can put a dirty hack^W^Wworkaround for Windows < WIN2012R2SERVER that would unconditionally set SO_SNDBUF to something like 1Mb.

Thank you for the hard work!

Yeah, Windows 7's speeds with single connections are very, very slow. It took me years to figure out the reason were bad TCP settings, because it worked fine when I used a multiconnection downloader. What fixed it for me was running these 3 commands in a CMD with admin permissions:

    netsh interface tcp set heuristics disabled
    netsh int tcp set global autotuninglevel=normal
    netsh int tcp set global congestionprovider=ctcp

Thanks for the tips.

I tried, and the first two lines helped the speed bump to 2.5MB/s! The third one doesn't seem to have any immediate effect.

Still not OneDrive level, but I'm more than happy.

Good to know which actually take any effect, since it's been so long since I cobbled those commands together that I didn't really remember either!

I probably took them from Win7 forums or some stackoverflow spinoff, the TCP problems on Win7 are not entirely unknown.

Google are migrating Backup and Sync to DriveFS soon [0], but you can upgrade right now. Now, I don't remember how I did it, but I do have Drive FS on my personal account.

[0]: https://support.google.com/googleone/answer/10309431#zippy=

Good to know! Definitely will try it later, but I currently have a backup job (one-way photo backup, not sync GD) set up on my second GDrive account which I don't want to touch.. yet.

Are you using the version of Windows with the fix mentioned in the article?

Yea, Dropbox on my Macs has continuously been outrageously slow at uploading. Everything else is multiples faster.

Dropbox does at least resume fairly reliably though, so I can generally ignore it the whole time... unless I have something I want to sync ASAP. Then I sometimes use the web UI and cross my fingers that I don't get a connection hiccup ಠ_ಠ

> Edit: should mention Google's DriveFS can reach max speed too, but it's not available for my personal account (which uses the "Backup and sync for Google" app).

That thing is far too aggressive about network bandwidth. It will upload 20 files at the same time and the speed limit setting doesn't work.

Is 20 files some kind of hyperbole? If not, how do you get it to do that?

I've never seen it transfer more than five files at a time, which sometimes drives me crazy when there are a lot of small files to sync.

It's not hyperbole. I make a backup of my computer, with the output being a bunch of 500MB files. And I would then copy or move those files into a folder on the file stream drive. It's not entirely consistent, and it used to do less, but with some update it decided that it should upload way too many files at once. I've had to switch to an entirely different program to upload those files sequentially.

What is the program that you are using? I am currently using odrive for macOS since they don't have DriveFS support for Apple Silicon. odrive work ok, it just have a weird file conflict sometime.

I'm using rclone to do big uploads.

I still use DriveFS for everything else, at least for now. Rclone is capable of mounting the drive but it's not really designed for that.

Google Drive is a gem. I hope it lasts forever cause no one is competing with them.

Except we're still waiting for an official Linux client since Google promised it was "coming soon" in 2012

https://abevoelker.github.io/how-long-since-google-said-a-go...

Of course there are alternatives now, but I like to plug this page whenever I can.

I'm using rclone and honestly prefer it at this point, and there are others as well, so while an official client would be nice it no longer is a concern for me.

I disagree. I had my machine backed up to Google Drive using their Backup and Sync program and when I got a new machine there was no reasonable way to restore the data from the old machine to the new machine, using Google Drive. Sure I can copy data from my old machine, but what if ti was lost or stolen? If the app can't handle this use case, what's the point of it? The only way to restore the files is in small chunks using the web based interface - not reasonable for tens of thousands of files and hundreds of gigabytes.

The workaround was to back everything up to the "Google Drive" folder since this seems to be the only folder that Backup and Sync can actually restore.

Had a somewhat similar issue, but with Drive File Stream.

At one point I set it up to use my second SSD as the local storage. Then I needed that SSD elsewhere, so I just took it out. It was impossible to restart the damn thing. It kept complaining about missing folders. I even tried uninstalling and reinstalling it, but it kept its settings.

Since I barely used that machine, if ever, and I'm not particularly familiar with Windows, I never really looked into how to completely clean up the configuration. But the point is that there clearly are some pretty stupid decisions about some products.

For future reference, most windows apps keep their settings in the AppData/Roaming folder in your user folder. There's a useful shortcut as an env variable - type %APPDATA% into explorer to go straight there.

System-wide settings and state should be stored in C:\ProgramData.

To be fair it is called Backup and Sync not Backup, Sync and Restore.

But on a more useful note how I have handled this in the past is to download the complete Google Drive data using Google Takeout. Not the greatest solution but it has worked.

It should be implied that if you are backing up files at some point you might like to restore them

Are you saying the files were no longer available in Google Drive? Did you download the Drive for desktop client to try restoring files or just try reinstalling the Backup and Sync client?

The files were still in Google Drive under "My Computer". My attempt was the latter, reinstalling the Backup and Sync client.

I believe simply installing the Google Drive for Desktop client would have been what you wanted to do. As the name suggests, the Backup and Sync client is well primarily for backing up and syncing your data automatically to Google Drive and Google Photos.

Thanks for the tip! I'll check that out

There are better Google Drive clients like SyncDocs that can actually restore properly.

Really? Google drive sync has been hot garbage for me. Before that program came everything was fine and dandy, but drive sync constantly stumbles over it's own feet, restarts and fails to up- and download files. I'm longing back to Rsync or even FTP after trying to use google drive to move data.

It does indeed take forever to upload most stuff.