mldonkey-users
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]