Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 05 Oct 2009 22:33:15 +0500
From:      rihad <rihad@mail.ru>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-net@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it>
Subject:   Re: dummynet dropping too many packets
Message-ID:  <4ACA2DDB.50809@mail.ru>
In-Reply-To: <4ACA2A52.4050704@elischer.org>
References:  <4AC8A76B.3050502@mail.ru>	<20091005025521.GA52702@svzserv.kemerovo.su>	<20091005061025.GB55845@onelab2.iet.unipi.it>	<4AC9B400.9020400@mail.ru>	<20091005090102.GA70430@svzserv.kemerovo.su>	<4AC9BC5A.50902@mail.ru>	<20091005095600.GA73335@svzserv.kemerovo.su>	<4AC9CFF7.3090208@mail.ru>	<20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <4ACA2A52.4050704@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> rihad wrote:
>> Luigi Rizzo wrote:
>>> On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote:
>>>> Eugene Grosbein wrote:
>>>>> On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
>>>>>
>>>>>> Still not sure why increasing queue size as high as I want doesn't 
>>>>>> completely eliminate drops.
>>>>> The goal is to make sources of traffic to slow down, this is the only
>>>>> way to descrease drops - any finite queue may be overhelmed with 
>>>>> traffic.
>>>>> Taildrop does not really help with this. GRED does much better.
>>>>>
>>>> Alright, so I changed to gred by adding to each config command:
>>>> ipfw ... gred 0.002/900/1000/0.1 queue 1000
>>>> and reconfigured. Still around 300-400 drops per second, which was 
>>>> typical at this load level before with taildrop anyway. There are 
>>>> around 3-5 mbit/s being wasted according to systat -ifstat.
>>>>
>>>> Should I now increase slots to 5-10-20k?
>>>> Very strange.
>>>>
>>>> "ipfw pipe show" correctly shows that gred is at work. For example:
>>>> 00512: 512.000 Kbit/s    0 ms  1000 sl. 79 queues (64 buckets)
>>>>           GRED w_q 0.001999 min_th 900 max_th 1000 max_p 0.099991
>>>>     mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
>>>> ...
>>>
>>> you keep omitting the important info i.e. whether individual
>>> pipes have drops, significant queue lenghts and so on.
>>>
>> Sorry. Almost everyone has 0 in the last Drp column, but some have 
>> above zero. I'm not just sure how this can be helpful to anyone.
> 
> 
> This tells us there are just a few sessions with VERY LARGE WINDOWS
> that are trying to push the link too fast. They are flooding the 
> firewall and geting all the drops.  (unless the problem is that the 
> hash/mask is putting a lot of session on the same slot.)
> 
> 
All masks are dst-ip 0xffffffff. I doubt very strongly that it's due to 
such offenders, because all the way from 4a.m. to 10a.m. at the load of 
200-330 mbit/s there are zero drops. There are no doubt heavy 
downloaders leaving their PCs on in the night. The drops begin as soon 
as the load crosses 340-360 mbit/s or some such, and it only worsens as 
the load approaches 500-530 mbit/s.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ACA2DDB.50809>