From owner-freebsd-stable@FreeBSD.ORG Wed Jan 31 18:01:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88F5816A401 for ; Wed, 31 Jan 2007 18:01:20 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA9413C491 for ; Wed, 31 Jan 2007 18:01:20 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0VI1KoG060159; Wed, 31 Jan 2007 10:01:20 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0VI1J50060158; Wed, 31 Jan 2007 10:01:19 -0800 (PST) (envelope-from rizzo) Date: Wed, 31 Jan 2007 10:01:19 -0800 From: Luigi Rizzo To: "Andresen, Jason R." Message-ID: <20070131100119.B59626@xorpc.icir.org> References: <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> <20070124071021.GG874@turion.vk2pj.dyndns.org> <20070124073602.B57678@xorpc.icir.org> <53B52415C756A84E8A169F0E3673A3290E964A@IMCSRV6.MITRE.ORG> <20070130123246.A46432@xorpc.icir.org> <53B52415C756A84E8A169F0E3673A3290E979B@IMCSRV6.MITRE.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <53B52415C756A84E8A169F0E3673A3290E979B@IMCSRV6.MITRE.ORG>; from jandrese@mitre.org on Wed, Jan 31, 2007 at 11:47:48AM -0500 Cc: freebsd-stable@freebsd.org Subject: Re: Dummynet and simulating random delay X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2007 18:01:20 -0000 On Wed, Jan 31, 2007 at 11:47:48AM -0500, Andresen, Jason R. wrote: > From: Luigi Rizzo [mailto:rizzo@icir.org] ... > >yes but just curious, this is something so odd that i wonder > >if you couldn't try to reproduce the real reasons for the increase. > >Is the extra delay due to the device stopping handling stuff for > >2.5seconds, then catching up ? > >if that's the case you might try to change the bandwidth to a > >very low value for the period while the satellite is asleep, > >and then back to the normal value. I am not 100% sure but > >this should work and give a more accurate emulation of what happens, > >especially the recovery period. > > That will actually work? Wonderful! Although these links are already > low bandwith (2400bps), I guess dropping it down to 10bps or something > would work fine. > > I had thought originally that if I did that it might buffer an entire > packet and tag it with a "10 bps" speed, causing it to stall the > connection for an excessively long period of time. If it just twiddles you are almost surely right, the deadline for the next packet to send is computed based on its size and the current bw when the packet reaches the head of the queue. So changing the bandwidth simulates a 'stall' of variable length. You would really need a different function to operate on the pipe, something that 'stalls' the pipe for a predetermined amount of time (either inserting the stall at the head of the queue, or at the tail). Implementation is trivial in both cases, but you need to write a bit of code into 'usr/src/sbin/ipfw2.c' to parse the command and issue the setsockopt(), and then into /sys/netinet/ip_dummynet.c to interpret the command. cheers luigi