dummynet queue size relative to bw setting?
Matthew Pope
mpope at oanda.com
Tue May 6 20:31:47 UTC 2008
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
More information about the freebsd-ipfw
mailing list