Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 08 Oct 2001 11:21:51 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        anderson@centtech.com
Cc:        Danny Braniss <danny@cs.huji.ac.il>, freebsd-hackers@freebsd.org, stable@freebsd.org
Subject:   Re: strange network performace
Message-ID:  <3BC1EEBF.3FB5B52F@mindspring.com>
References:  <E15qawr-0000An-00@pampa.cs.huji.ac.il> <3BC1B2D2.E42F3704@centtech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson wrote:
> 
> Oh, well, I thought you said "10mb/s", not "10MB/s" .. that makes
> it a bit different.  I wonder if it could still be a tcp window
> size or something.. Try these sysctl's on C:
> vfs.nfs.gatherdelay=0
> vfs.nfs.async=1
> vfs.vmiodirenable=1

Alfred stated that he had seen some strangeness with this.

> kern.ipc.maxsockbuf=2097152
> kern.ipc.somaxconn=8192

This won't work, unless it's done at boot time, since that's
where the zone sizes are initialized (should be read-only).

> kern.ipc.maxsockets=16424

Also boot time (should be read-only) -- note that these
things are strange, as the UDP and TCP allocations don't
occur from the same space, so there are some which size
per-protocol structures, while others size per-system
structures.  The distinction between global vs. protocol
specific isn't really clearly documented.

> kern.maxfiles=65536

Also boot time (should be read-only).

> kern.maxfilesperproc=32768

Just a soft limit -- can be done any time.

> net.inet.tcp.rfc1323=1
> net.inet.tcp.delayed_ack=0
> net.inet.tcp.sendspace=65535
> net.inet.tcp.recvspace=65535
> net.inet.udp.recvspace=65535

Cranking up the space and the connections simultaneously will
make you need more than 2G of memory, max, for the sockets
for the window data, should the windows be full.  Be very
careful, since it's possible to run out of memory and crash
the box doing this... for it to work, you'd need to have 4G
of RAM, and set the KVA space up to 3G (from the default of
1G).  THere are some bugs in /sys/i386/machdep.c as regards
overallocation with an alomost full memory map (mostly swap
related stuff for page tables that will no longer fit in the
address space, along with everything else).

This is a good suggestion, but is fraught with peril, if the
system networking load goes very high (e.g. DDOS or other
attack).


> net.inet.udp.maxdgram=57344

Probably no change for his application.

> net.local.stream.recvspace=65535
> net.local.stream.sendspace=65535

No change (UNIX domain sockets only).


The other suggestions are good.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BC1EEBF.3FB5B52F>