Date: Tue, 6 May 2008 22:06:51 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Matthew Pope <mpope@oanda.com> Cc: freebsd-ipfw@freebsd.org Subject: Re: dummynet queue size relative to bw setting? Message-ID: <20080506200651.GA57251@onelab2.iet.unipi.it> In-Reply-To: <4820B2BF.6090608@oanda.com> References: <4820AB8F.2000204@oanda.com> <4820B2BF.6090608@oanda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080506200651.GA57251>