Dummynet and simulating random delay

[Andresen, Jason R.]

From: Luigi Rizzo [mailto:rizzo at icir.org] 
>
>On Tue, Jan 30, 2007 at 03:03:06PM -0500, Andresen, Jason R. wrote:
>> >From: Luigi Rizzo [mailto:rizzo at 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.

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
the output code independent of the queue than it should work perfectly.
Thanks.