Date: Tue, 30 Jan 2007 12:32:46 -0800 From: Luigi Rizzo <rizzo@icir.org> To: "Andresen, Jason R." <jandrese@mitre.org> Cc: freebsd-stable@freebsd.org Subject: Re: Dummynet and simulating random delay Message-ID: <20070130123246.A46432@xorpc.icir.org> In-Reply-To: <53B52415C756A84E8A169F0E3673A3290E964A@IMCSRV6.MITRE.ORG>; from jandrese@mitre.org on Tue, Jan 30, 2007 at 03:03:06PM -0500 References: <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> <20070124071021.GG874@turion.vk2pj.dyndns.org> <20070124073602.B57678@xorpc.icir.org> <53B52415C756A84E8A169F0E3673A3290E964A@IMCSRV6.MITRE.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 30, 2007 at 03:03:06PM -0500, Andresen, Jason R. wrote: > >From: Luigi Rizzo [mailto:rizzo@icir.org] > > > >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. > > 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. 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. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070130123246.A46432>