Boosting upload speed and improving Windows' TCP stack • Hacker News Board

Re: Boosting upload speed and improving Windows' TCP stack

#101

Post by SaveTheRbtz » Wed, May 19, 2021, 2:00 AM UTC

slowstart wrote: post #87

I lead the Windows TCP team. We blogged about recent TCP advancements which is very relevant: https://techcommunity.microsoft.com/t5/networking-blog/algor...

A couple of questions:

* What are the reasons for disabling TCP timestamps by default? (If you can answer) will they be eventually enabled by default? (The reason I'm asking is that Linux uses TS field as storage for syncookies, and without it will drop WScale and SACK options greatly degrading Windows TCP perf in case of a synflood.[1])

* I've noticed "Pacing Profile : off" in the `netsh interface tcp show global` output. Is that the same as tcp pacing in fq qdisc[2]? (If you can answer) will it be eventually enabled by default?

[1] https://elixir.bootlin.com/linux/v5.13-rc2/source/net/ipv4/s... [2] https://man7.org/linux/man-pages/man8/tc-fq.8.html

Re: Boosting upload speed and improving Windows' TCP stack

#102

Post by drummer » Wed, May 19, 2021, 2:33 AM UTC

slowstart wrote: post #87

I lead the Windows TCP team. We blogged about recent TCP advancements which is very relevant: https://techcommunity.microsoft.com/t5/networking-blog/algor...

I have a question, why is it that when opening two sockets on Windows and connecting them through TCP, there is about a 40% difference in transfer rate when sending from socket A to B, compared to sending from B to A?

Re: Boosting upload speed and improving Windows' TCP stack

#103

Post by slowstart » Wed, May 19, 2021, 2:51 AM UTC

drummer wrote: post #102

slowstart wrote: post #87

I lead the Windows TCP team. We blogged about recent TCP advancements which is very relevant: https://techcommunity.microsoft.com/t5/networking-blog/algor...

I have a question, why is it that when opening two sockets on Windows and connecting them through TCP, there is about a 40% difference in transfer rate when sending from socket A to B, compared to sending from B to A?

That's not expected. Are you using loopback sockets or are these sockets on different endpoints? Is this unidirectional or bidirectional traffic, i.e. are you doing both transfers from A to B and B to A simultaneously?

Re: Boosting upload speed and improving Windows' TCP stack

#104

Post by SaveTheRbtz » Wed, May 19, 2021, 2:55 AM UTC

slowstart wrote: post #88

lowleveldesign wrote: post #35

If you’re on recent Windows system, you should have pktmon [1] available. I believe it’s the „netsh trace” successor and has much nicer command line. And you no longer need an external tool to convert the trace to .npcap format. [1] https://docs.microsoft.com/en-us/windows-server/networking/t...

PktMon is the next generation tool in newer Windows 10 versions and brings many of the same benefits referred to in this blog - particularly being able to view packet captures and traces together in the same text file.

Thanks! Added it back to the blogpost (seems like we accidentally lost the `pktmon` reference during the editing process =)

Re: Boosting upload speed and improving Windows' TCP stack

#105

Post by drummer » Wed, May 19, 2021, 2:56 AM UTC

slowstart wrote: post #103

drummer wrote: post #102

Earlier quoted context omitted.

I have a question, why is it that when opening two sockets on Windows and connecting them through TCP, there is about a 40% difference in transfer rate when sending from socket A to B, compared to sending from B to A?

That's not expected. Are you using loopback sockets or are these sockets on different endpoints? Is this unidirectional or bidirectional traffic, i.e. are you doing both transfers from A to B and B to A simultaneously?

I see the issue both on the same computer, so loopback, as well as on two computers on the same LAN. I tested with unidirectional traffic. Pretty easy to test for yourself. The problem appears to be with the TCP protocol implementation. For UDP transmission speed is the same both ways.

Re: Boosting upload speed and improving Windows' TCP stack

#106

Post by slowstart » Wed, May 19, 2021, 2:57 AM UTC

SaveTheRbtz wrote: post #101

slowstart wrote: post #87

I lead the Windows TCP team. We blogged about recent TCP advancements which is very relevant: https://techcommunity.microsoft.com/t5/networking-blog/algor...

A couple of questions: * What are the reasons for disabling TCP timestamps by default? (If you can answer) will they be eventually enabled by default? (The reason I'm asking is that Linux uses TS field as storage for syncookies, and without it will drop WScale and SACK options greatly degrading Windows TCP perf in case of a synflood.[1]) * I've noticed "Pacing Profile : off" in the `netsh interface tcp show global` o…

Windows historically defaulted to accepting timestamps when negotiated by the peer but didn't initiate the negotiation. There are benefits to timestamps and one downside (12 bytes overhead per packet). Re. syncookies, that's an interesting problem but under a severe syn attack, degraded performance is not going to be the biggest worry for the server. We might turn them on but for the other benefits, no committed plans. Re. pacing profile, no that's pacing implemented at the TCP layer itself (unlike fq disc) and is an experimental knob off by default.

Re: Boosting upload speed and improving Windows' TCP stack

#107

Post by encryptluks2 » Wed, May 19, 2021, 3:02 AM UTC

fletchowns wrote: post #98

encryptluks2 wrote: post #30

Earlier quoted context omitted.

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.

Re: Boosting upload speed and improving Windows' TCP stack

#108

Post by alternatetwo » Wed, May 19, 2021, 3:04 AM UTC

thrdbndndn wrote: post #78

SaveTheRbtz wrote: post #74

Earlier quoted context omitted.

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

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, Receiv…

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

Re: Boosting upload speed and improving Windows' TCP stack

#109

Post by SaveTheRbtz » Wed, May 19, 2021, 3:10 AM UTC

Agingcoder wrote: post #69

Excellent article ! I got hit by the exact same issue which is described in the fermilab paper, namely packet reordering caused by intel drivers. It took me several days to diagnose the problem. Interestingly enough, the problem virtually disappeared when running tcpdump, which, after a lot of reading on the innards of the linux TCP stack, and prodding with ebpf, eventually led me to conjecture that it was a scheduli…

> tcpdump ... linux TCP stack ... ebpf

> Networks are not my specialty

I wish all network non-specialist were like you!

Re: Boosting upload speed and improving Windows' TCP stack

#110

Post by pjmlp » Wed, May 19, 2021, 4:55 AM UTC

encryptluks2 wrote: post #11

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…

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

It does indeed take forever to upload most stuff.