Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 06 May 2008 16:31:45 -0400
From:      Matthew Pope <>
To:        Luigi Rizzo <>
Subject:   Re: dummynet queue size relative to bw setting?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

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.

Want to link to this message? Use this URL: <>