Opened 23 months ago

Last modified 20 months ago

#22848 new defect

Increase default Tor buffer sizes on Windows

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: windows, performance, tor-relay, win32, 032-unreached
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:

Description

In #22798, a Windows relay operator discovered that setting

ConstrainedSockSize 262144

made inbound connections to their relay much faster. (Outbound connections are fast regardless.)

They suspect this is because Tor's networking calls turn Windows buffer auto-tuning off.

We should improve this default, because it will help Windows relays be faster. (It shouldn't affect Windows clients, because they only connect out.)

This might be an issue in Tor, or it might be in mingw-64.

Child Tickets

Change History (6)

comment:1 Changed 23 months ago by cypherpunks

This bug affects Windows Vista/Widows 7 send buffer size only (recv buffer size auto-tunes by OS), according to openvpn ticket Windows 8 or later no need any changes to default settings.

comment:2 Changed 23 months ago by nickm

Keywords: tor-relay win32 added
Milestone: Tor: unspecifiedTor: 0.3.2.x-final

comment:3 Changed 23 months ago by Vort

Solution, which uses "ideal send backlog", is more promising.
For example, it is hard to get Guard flag with static 0.25 MiB buffer.
It is small for such task. But for low latency connections, 0.25 MiB buffer will be an overkill.

comment:4 Changed 21 months ago by nickm

Is there a solution that you recommend here? Or should we just leave this alone for now?

comment:5 in reply to:  4 Changed 21 months ago by teor

Replying to nickm:

Is there a solution that you recommend here? Or should we just leave this alone for now?

On Windows 7/Vista (and earlier?) relays, set the equivalent of ConstrainedSockSize 262144.

comment:6 Changed 20 months ago by nickm

Keywords: 032-unreached added
Milestone: Tor: 0.3.2.x-finalTor: unspecified

Mark a large number of tickets that I do not think we will do for 0.3.2.

Note: See TracTickets for help on using tickets.