Dummynet and simulating random delay

[Luigi Rizzo]

On Wed, Jan 31, 2007 at 11:47:48AM -0500, Andresen, Jason R. wrote:
> From: Luigi Rizzo [mailto:rizzo at 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