From: Luigi Rizzo [mailto:[EMAIL PROTECTED] > >On Tue, Jan 30, 2007 at 03:03:06PM -0500, Andresen, Jason R. wrote: >> >From: Luigi Rizzo [mailto:[EMAIL PROTECTED] >> > >> >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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
