From owner-freebsd-net@FreeBSD.ORG Tue Jun 21 17:13:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B24CF16A41F for ; Tue, 21 Jun 2005 17:13:46 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (129pc197.sshunet.nl [145.97.197.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F0E43D55 for ; Tue, 21 Jun 2005 17:13:45 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [195.16.84.90] (serkoon@jura.thelostparadise.com [195.16.84.90] (may be forged)) by mail.thelostparadise.com (8.12.11/8.12.8) with ESMTP id j5LHDidF023178; Tue, 21 Jun 2005 19:13:44 +0200 (CEST) (envelope-from pieter@thedarkside.nl) Message-ID: <42B84AC8.7050802@thedarkside.nl> Date: Tue, 21 Jun 2005 19:13:44 +0200 From: Pieter de Boer User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <42B722EF.2090203@thedarkside.nl> <20050620135044.B35720@xorpc.icir.org> <42B731CD.1040104@thedarkside.nl> <20050621075247.D63359@xorpc.icir.org> In-Reply-To: <20050621075247.D63359@xorpc.icir.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Issues with a Large Fat pipe Network simulation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2005 17:13:46 -0000 Luigi Rizzo wrote: >>However.. when I deleted the pipe rules on 'network', the speed suddenly >>went up to around 800mbit/s too! I remade them, and voila, 200mbit/s. > network emulation is a tricky job :) It sure is, so I'm happy you're trying to help out :) > in any case i believe what happens is the following. > > The pipe has a default size of 50 slots, which at 1500 bytes is > little above 64k. If the sender is bursting a large number of packets, > it may well overflow the pipe's queue causing a backoff (which > may simply be immediate, or delayed, depending on how you configure > various things). > > I believe setting the queue size in the pipe to a value larger than > the window should fix things. I had the same thought, so I already fiddled with it a bit. Because you brought it up I tested the following this evening: send/recv spaces at 128KB 00001: unlimited 0 ms 50 sl. 1 queues (1 buckets) droptail 00002: unlimited 0 ms 50 sl. 1 queues (1 buckets) droptail I'm getting 300-400mbit/s (which is higher than yesterday; it seems the speed creeps up a bit after a while). 00001: unlimited 0 ms 100 sl. 1 queues (1 buckets) droptail 00002: unlimited 0 ms 100 sl. 1 queues (1 buckets) droptail I'm getting 300-400mbit/s. There doesn't seem to be a direct relation between the pipe's queuing slots and the throughput. Setting the send/recvspaces to 65535 again does give me an immediate throughput of >800mbit/s, though. Hope you still have some other ideas, since I'm a bit puzzled here.. -- Pieter