[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Windows buffer problems



On Fri, Dec 19, 2008 at 7:54 AM, Lee <ler762@xxxxxxxxx> wrote:
> ...
>  "Manipulating
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize
> and TcpWindowSize to 0xfaf00 (1027840) seemed to increase the time to
> failure when running Tor and BitTorrent."
>
> seems backwards.  Instead of buffering up to 16KB of data for each
> open connection you're telling the system to buffer up to 1MB of data
> for each open connection.  How can increasing system buffer usage help
> if the problem is insufficient buffer space?

this is a little odd.  there is a different option useful for virtual
servers (and seems to help with the WSAENOBUFS too) called
ConstrainedSockets.  this will use setsockopt()  to limit the size of
send and receive buffers associated with each socket.  the
ConstrainedSockSize parameter can lower or increase from the default
constrained size.

i wonder if the person reporting that behavior allowed TCP windows to
scale above 1M so constraining them to 1M limit helped (but still
seems high).


> So I'm wondering if the problem could be that the system runs out of
> available ports.

i don't think this is quite as common, and is reported as an error
distinct from the too many concurrent pending and buffer exhaustion
errors.


> XP defaults to using something like 4K ports and 240 seconds for
> keeping a closed socket in the timed wait state.  Has anyone tried
> bumping the allowable port numbers up to 64K and dropped the timed
> wait state time to 16 seconds?

dropping the time wait state is a good idea.  i have to do this for
other connect heavy applications in a different setting to keep within
global kernel limits for max open files.  by default this is usually
around 4 minutes.  that's a long time to tie up scarce kernel buffer
resources and/or file descriptors.  i don't know how useful this would
be for Tor servers; a good experiment for someone to try perhaps! :)

best regards,