[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mldonkey-users] No buffer space available on FreeBSD
From: |
Bernd Walter |
Subject: |
Re: [Mldonkey-users] No buffer space available on FreeBSD |
Date: |
Mon, 4 Nov 2002 20:12:35 +0100 |
User-agent: |
Mutt/1.5.1i |
On Mon, Nov 04, 2002 at 01:01:17PM -0500, Stephane Goulet wrote:
> Hi Jonas,
>
> Already had problems with these myself, if i remember well, next step
> would be to tweak sysctl ( man sysctl ).
>
> I put those in /etc/sysctl personally, maybe someone can tell me if i should
> not had put such high values ;)
>
> net.inet.tcp.recvspace=65535
This might create a communicationproblem with broken implementations
interpreting this as -1.
> net.inet.tcp.sendspace=65535
This is already default
> net.inet.ip.maxqueue=65535
> net.inet.udp.recvspace=65535
> net.inet.udp.sendspace=65535
These values are problematic as you can fill much more data, but as it
doesn't change your line speed you just degrade responisiveness.
This is just like the shop scenario at the cash desk - if many people
are waiting there it takes a long time before they get serviced.
It's better to limit the queue and tell them - no sense to wait - come
back later if you like.
An application can't wait forever for the response to a packet.
If the overall time is to long it's belied lost and resend.
Also keep in mind that bigger buffers also raise memory requirements.
> kern.maxfiles=65535
It's much better to reduce the number of filehandles used by mldonkey.
I'm using max_opened_connections = 300 which is absolutely enough.
> (maxing out x.recvspace helps general net performance, i read that
> somewhere...)
Say you have a network delay of 100mS multiplied with a line bandwidth
of 100kBytes/s.
That means a single connect can have up to 10kBytes on the line, which
requieres a receivebuffer of at least 10k.
Every byte more is just a waste of memory.
In the mldonkey case you share the bandwidth with several connects so
the requirements for each individual socket are even lower.
The typical reason for increasing receive buffers are long latency
highspeed connects.
The typical reason for increasing send buffers are slow applications.
The system values of the socket buffers are only defaults and every
socket can have it's own values definied.
It's possible that mldonkey doesn't inherit the system defaults anyway.
--
B.Walter COSMO-Project http://www.cosmo-project.de
address@hidden Usergroup address@hidden