Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boosting upload speed and improving Windows' TCP stack

dropbox.tech

Post reply on HN
Print view View original

51–60 of 127 posts

Re: Boosting upload speed and improving Windows' TCP stack

#51

Post by virtuallynathan »

drewg123 wrote: post #43
thrdbndndn wrote: post #8

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 sam…

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 al…

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.

Re: Boosting upload speed and improving Windows' TCP stack

#52

Post by Groxx »

thrdbndndn wrote: post #8

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 sam…

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

Re: Boosting upload speed and improving Windows' TCP stack

#53

Post by brundolf »

whatever_dude wrote: post #31
brundolf wrote: post #9

Dropbox always publishes such good technical blog posts. And as a user, it's reassuring to see how much they still care about technical excellence.

Do they? I constantly see DropBox taking days to sync files that are 30kb on size. Or doing dumbfounding things like download all files, then re-upload all files when I set sync to "online only" on a folder if just one of the files is not set to online only. Maybe they have grand academic visions and papers, but I've been using them for well over a decade and I feel the client quality has gone downhill over the past…

Maybe my usage stays in the golden path, but I've been using them for ten years too and I have no complaints about the core functionality. My only real complaint is that they've been adding lots of features I don't care about, getting slightly pushy about convincing you to try them, etc. But I haven't seen the core stuff actually go downhill.

Re: Boosting upload speed and improving Windows' TCP stack

#54

Post by leadbase0 »

drewg123 wrote: post #43
thrdbndndn wrote: post #8

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 sam…

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 al…

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

Re: Boosting upload speed and improving Windows' TCP stack

#55

Post by dochtman »

leadbase0 wrote: post #54
drewg123 wrote: post #43

Earlier quoted context omitted.

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 al…

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

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

Re: Boosting upload speed and improving Windows' TCP stack

#57

Post by AndrewDucker »

leadbase0 wrote: post #54
drewg123 wrote: post #43

Earlier quoted context omitted.

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 al…

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

Re: Boosting upload speed and improving Windows' TCP stack

#59

Post by toast0 »

mwcampbell wrote: post #41

I wonder how the Dropbox developers managed to get in contact with the Windows core TCP team. Maybe I'm too cynical, but I'm surprised that Microsoft would go out of their way to work with a competitor like this.

Even if OneDrive vs Dropbox is important, this is a win for Windows in general. People will switch OSes because the TCP throughput is better on the other side; it's easy to measure and easy to compare and makes a nice item in a pros and cons list.

Fixing something like this can help lots of use cases, but may have been difficult to spot, so I'm sure the Windows TCP team was thrilled to get the detailed, reproducible report.

Re: Boosting upload speed and improving Windows' TCP stack

#60

Post by CPAhem »

fletchowns wrote: post #17
encryptluks2 wrote: post #11

Earlier quoted context omitted.

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

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 chunk…

There are better Google Drive clients like SyncDocs that can actually restore properly.
Post reply on HN