From owner-freebsd-stable@FreeBSD.ORG Wed Jan 31 16:47:52 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 E128916A402 for ; Wed, 31 Jan 2007 16:47:51 +0000 (UTC) (envelope-from jandrese@mitre.org) Received: from smtp-mclean.mitre.org (smtpproxy2.mitre.org [192.80.55.71]) by mx1.freebsd.org (Postfix) with ESMTP id 9E87613C467 for ; Wed, 31 Jan 2007 16:47:51 +0000 (UTC) (envelope-from jandrese@mitre.org) Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l0VGlo76022957 for ; Wed, 31 Jan 2007 11:47:50 -0500 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 9E30E1BD7C for ; Wed, 31 Jan 2007 11:47:50 -0500 (EST) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l0VGlohv022943; Wed, 31 Jan 2007 11:47:50 -0500 Received: from IMCSRV6.MITRE.ORG ([129.83.20.237]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:47:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Jan 2007 11:47:48 -0500 Message-ID: <53B52415C756A84E8A169F0E3673A3290E979B@IMCSRV6.MITRE.ORG> In-Reply-To: <20070130123246.A46432@xorpc.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dummynet and simulating random delay thread-index: AcdErc7cyeL0Wg7HSoGRiyAnSwo10QAqRbxw 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> From: "Andresen, Jason R." To: "Luigi Rizzo" X-OriginalArrivalTime: 31 Jan 2007 16:47:50.0037 (UTC) FILETIME=[8B07E450:01C74557] 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 16:47:52 -0000 From: Luigi Rizzo [mailto:rizzo@icir.org]=20 > >On Tue, Jan 30, 2007 at 03:03:06PM -0500, Andresen, Jason R. wrote: >> >From: Luigi Rizzo [mailto:rizzo@icir.org]=20 >> > >> >On Wed, Jan 24, 2007 at 06:10:21PM +1100, Peter Jeremy wrote: >> >> On Tue, 2007-Jan-23 14:22:54 -0500, Andresen, Jason R. wrote: >> >> >I have a project that requires me to simulate a link with=20 >> >varying but >> >> >well defined delay. The link is guarenteed to deliver packets in >> >> >order, so I wish to maintain that behavior with Dummynet. >> >>=20 >> >> I don't think dummynet can do this in its current form. Based on >> > >> >actually dummynet never does reordering within a single pipe, even >> >if you change the delay on the fly. >> > >> >But this said, you should explain "varying but well defined delay", >> >because if you use TCP or similar as the source, then you >> >have no control on when the userland write->tcp transmission delay >> >anyways so the concept is a bit vague and probably not a meaningful >> >experiment. And even in any common network (from switched >> >ethernet to wireless to dsl...) you have some variance on the delay, >> >ranging from a fraction of a millisecond to much larger values, >> >due to queueing and/or protocol issues (e.g. MAC channel allocation) >> >and/or switch/router/operating system issues. >>=20 >> I'm trying to simulate a satellite link that has a normal delay of 1 >> second, but every 20-30 seconds or so the delay shoots up to 3.5 >> seconds for about 4 seconds and then settles back down to 1 second. >> >From what you said, I'm thinking that just twiddling the pipe on the >> fly will probably work. =20 > >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. =20 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 the output code independent of the queue than it should work perfectly. Thanks. =20