From owner-freebsd-net@FreeBSD.ORG  Sun Jul  3 19:56:50 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D15361065673
	for <freebsd-net@freebsd.org>; Sun,  3 Jul 2011 19:56:50 +0000 (UTC)
	(envelope-from egrosbein@rdtc.ru)
Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5])
	by mx1.freebsd.org (Postfix) with ESMTP id 45D248FC08
	for <freebsd-net@freebsd.org>; Sun,  3 Jul 2011 19:56:50 +0000 (UTC)
Received: from eg.sd.rdtc.ru (localhost [127.0.0.1])
	by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p63JungM004613;
	Mon, 4 Jul 2011 02:56:49 +0700 (NOVST)
	(envelope-from egrosbein@rdtc.ru)
Message-ID: <4E10C97C.2030200@rdtc.ru>
Date: Mon, 04 Jul 2011 02:56:44 +0700
From: Eugene Grosbein <egrosbein@rdtc.ru>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU;
	rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7
MIME-Version: 1.0
To: Adrian Minta <gygy@stsnet.ro>
References: <f9d8cfb9ee20ba5ab730820fc5c45962.squirrel@mail.stsnet.ro>
	<4E10C8F3.2050006@rdtc.ru>
In-Reply-To: <4E10C8F3.2050006@rdtc.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Jul 2011 19:56:50 -0000

>> After looking in the mpd log file I found out that this message appear
>> when calls are dropped:
>> Jul  3 21:21:21 lns mpd: Daemon overloaded, ignoring request.
>> Jul  3 21:21:22 lns mpd: Daemon overloaded, ignoring request.
>> Jul  3 21:21:23 lns mpd: Daemon overloaded, ignoring request.
>> Jul  3 21:21:23 lns mpd: Daemon overloaded, ignoring request.
>> Jul  3 21:21:24 lns mpd: Daemon overloaded, ignoring request.
>> Jul  3 21:21:24 lns mpd: Daemon overloaded, ignoring request.
>>
>> Does anybody knows where this limit is set in mpd5 ?
>>
> 
> There is internal queue of messages in the mpd-5.5 with length 8129.
> Messages are generated based on various events and enqueued there, then processed.
> 
> Mpd uses GRED algorithm to prevent overload: it accepts all new L2TP connections
> when queue has 10 or less slots occupied (unprocessed events).
> 
> It drops all connections then it has over 60 slots occupied.

s/all/new incoming/

> In between, it drops new message with probability equal to (q-10)*2 percents

s/message/L2TP connection/

> where q is number of occupied queue slots. These constants are hardcoded in its src/ppp.h
> 
> Each time it decided to ignore incoming L2TP requests it notes that in the log,
> as you have already seen.

Eugene Grosbein