Date: Tue, 06 May 2008 16:31:45 -0400 From: Matthew Pope <mpope@oanda.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-ipfw@freebsd.org Subject: Re: dummynet queue size relative to bw setting? Message-ID: <4820C031.4000707@oanda.com> In-Reply-To: <20080506200651.GA57251@onelab2.iet.unipi.it> References: <4820AB8F.2000204@oanda.com> <4820B2BF.6090608@oanda.com> <20080506200651.GA57251@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > On Tue, May 06, 2008 at 03:34:23PM -0400, Matthew Pope wrote: > >> I must correct my test parameters: In one of the two pipes, the bw was >> 4K, not 48K as stated. >> When I just now moved it up to 48K to match the other pipe size, my ping >> times plummeted to 129-139ms throughout the Queue sizes listed below, >> again with Q=120 getting total packet loss. >> I thought a ping sent packets slowly, so that the 4K bw on the one pipe >> would not slow things down, but it seems I was wrong. Still I'm >> wondering why the measured delay is 130, without dummynet its 40, and >> I've set it to 5ms in each direction, so it should be measured as 50, >> not 130. Thx, Matthew >> > > part of the delay is the time it takes for the bits of the packet > to go through the bandwidth-limited channel - this is called > "transmission delay" and is > > transmission_delay = packet_size_in_bits/bandwidth_in_bits_per_second > > Also, depending on how you configure dummynet, your ping request > and response can go through a pipe multiple times (for a proper > configuration, usually you traverse one pipe downstream and one > pipe upstream; if the system is misconfigured, e.g. as a router > with dummynet intercepting traffic on both interfaces, > you will traverse two pipes on each direction). > > > The typical ping packet is around 64 bytes or 512 bits, at 48Kbit/s > this makes an additional 12ms each way, so you should see > no less than 40+(5+12)*2 = 74 ms for a proper configuration, and > 40+(5+12)*4 = 108 ms if misconfigured, the latter is very similar to > the numbers you are seeing. > > On top of this, VMware doesn't emulate well enough the timing, > so it is likely that the clock ticks every 10ms instead of the 1ms > expected by the hardware, so some of the individual delays > (5ms for the pipe, 12ms for the transmission time) could be > further rounded to the next multiple of the clock tick, > which would increase the delay even further. > > cheers > luigi > > Thanks so much Luigi! This little tutorial (and VMWare comment) is exactly what I needed to understand what was going on. And thank you for Dummynet, a very significant contribution to multi-cast routing and simulation. Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4820C031.4000707>