7 ms·

Cool article, but I'm not impressed by DropBox's upload speed on my Windows computer, at all. I just tested rn with DropBox, GoogleDrive, and OneDrive, all wit

Cool article, but I'm not impressed by DropBox's upload speed on my Windows computer, at all. I just tested rn with DropBox, GoogleDrive, and OneDrive, all with their native desktop apps. I simply put a 300MB file in the folder and let it sync. DB: 500 KiB/s GD: 3 MiB/s OD: 11 MiB/s (my max bandwidth with 100Mbps) I don't know what causes the disparity here, but I have been annoyed by this for years, and it's the same across multiple computers I use at different locations. Another funny thing is if you just use the webpage, both GD and DB can reach 100Mbps easily. 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).

drewg123 5y ago
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.
- virtuallynathan 5y ago
  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.
- leadbase0 5y ago
  QUIC is UDP, and TCP does not use CCA in userspace.
  - dochtman 5y ago
    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.)
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - leadbase0 5y ago
      QUIC is a protocol... "...CCA in userspace" CCA stands for congestion control algorithm.
  - AndrewDucker 5y ago
    QUIC absolutely uses congestion control. See section 6 here https://tools.ietf.org/id/draft-ietf-quic-recovery-26.html https://tools.ietf.org/id/draft-ietf-quic-recovery-26.html
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - tmashb 5y ago
      No denying in that.
pityJuke 5y ago
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= https://support.google.com/googleone/answer/10309431#zippy=
- thrdbndndn 5y ago
  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.
encryptluks2 5y ago
Google Drive is a gem. I hope it lasts forever cause no one is competing with them.
- fletchowns 5y ago
  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.
  - vladvasiliu 5y ago
    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.
    - ripdog 5y ago
      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.
  - encryptluks2 5y ago
    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?
Dylan16807 5y ago
> 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.
- vladvasiliu 5y ago
  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.
  - Dylan16807 5y ago
    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.
    - Isthatablackgsd 5y ago
      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.
      - Dylan16807 5y ago
        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.
kevingadd 5y ago
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?
- thrdbndndn 5y ago
  It uploads fine with web version, so I doubt it's a routing issue (granted, they could use different datacenter.)
nailer 5y ago
Are you using the version of Windows with the fix mentioned in the article?
Groxx 5y ago
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 ಠ_ಠ
SaveTheRbtz 5y ago
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.
- thrdbndndn 5y ago
  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).
  - SaveTheRbtz 5y ago
    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.
    - thrdbndndn 5y ago
      Thank you for the hard work!
  - alternatetwo 5y ago
    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

drewg123 5y ago

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.

virtuallynathan 5y ago
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.
leadbase0 5y ago
QUIC is UDP, and TCP does not use CCA in userspace.
- dochtman 5y ago
  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.)
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - leadbase0 5y ago
    QUIC is a protocol... "...CCA in userspace" CCA stands for congestion control algorithm.
- AndrewDucker 5y ago
  QUIC absolutely uses congestion control. See section 6 here https://tools.ietf.org/id/draft-ietf-quic-recovery-26.html https://tools.ietf.org/id/draft-ietf-quic-recovery-26.html
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - tmashb 5y ago
    No denying in that.

pityJuke 5y ago

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= https://support.google.com/googleone/answer/10309431#zippy=

thrdbndndn 5y ago
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.

encryptluks2 5y ago

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

fletchowns 5y ago
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.
- vladvasiliu 5y ago
  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.
  - ripdog 5y ago
    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.
- encryptluks2 5y ago
  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?

Dylan16807 5y ago

> 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.

vladvasiliu 5y ago
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.
- Dylan16807 5y ago
  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.
  - Isthatablackgsd 5y ago
    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.
    - Dylan16807 5y ago
      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.

kevingadd 5y ago

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?

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

nailer 5y ago

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

Groxx 5y ago

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 ಠ_ಠ

SaveTheRbtz 5y ago

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.

thrdbndndn 5y ago
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).
- SaveTheRbtz 5y ago
  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.
  - thrdbndndn 5y ago
    Thank you for the hard work!
- alternatetwo 5y ago
  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