Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jan 2007 07:36:02 -0800
From:      Luigi Rizzo <rizzo@icir.org>
To:        "Andresen, Jason R." <jandrese@mitre.org>, freebsd-stable@freebsd.org
Subject:   Re: Dummynet and simulating random delay
Message-ID:  <20070124073602.B57678@xorpc.icir.org>
In-Reply-To: <20070124071021.GG874@turion.vk2pj.dyndns.org>; from peterjeremy@optushome.com.au on Wed, Jan 24, 2007 at 06:10:21PM %2B1100
References:  <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> <20070124071021.GG874@turion.vk2pj.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 varying but
> >well defined delay.  The link is guarenteed to deliver packets in
> >order, so I wish to maintain that behavior with Dummynet.
> 
> 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.

If your delay varies on a coarse timescale, you can just change
the pipe's delay as needed, and once things have settled
(because of the no-reordering) you know that your packets are
delayed by exactly what you specify, plus the

If you are interested in somewhat random delays (e.g. to model
the effect of interfering traffic) you do just that - fire
extra traffic to the same pipe, and then as a side effect of
the queueing, your traffic will be subject to variable delays.

Also keep in mind that the resolution of dummynet is 1/hz
so it is in the order of 1 millisecond.

	cheers
	luigi



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