Re: dummynet queue size relative to bw setting?
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 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dummynet queue size relative to bw setting?
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 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dummynet queue size relative to bw setting?
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 Hello, I've been reading about dummynet for 2 weeks, including the seminal ACM paper & I'm very impressed. I've configured and run some preliminary simulations that have my colleagues quite interested too. However, I'm finding my delay settings are yielding delays of about two orders of magnitude larger that requested. I believe I don't understand the relationship very well that defines the setting of the queue size to relative to the bandwidth setting (and plr?) Can someone explain or point me to a source for this? I recall reading that with lower bandwidths one should use lower queue sizes to avoid long queuing delays. So I presume that is why my delays are so long. So I've run some tests with various queue sizes. With Queue sizes of 100, 80, 60, 40, 10 slots on a pipe with a bw of 48Kbits/s, delay of 5ms, and plr 0.025 defined in each direction, I'm consistently getting RT delays of 500-600ms with a ping test, packet loss does come out around 5%. The target I'm pinging is normally a 40 ms latency. At Queue size 120 I get 100% packet loss (but I can ignore that). I am not a networking specialist, so I realize my question is ignorant :-) I'm running this in VMWare Server on a dual core 2 GHz with 2 GB RAM using a modification of the dummynet test network design described at codefromthe70s.org Thanks, Matthew ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dummynet queue size relative to bw setting?
Hello, I've been reading about dummynet for 2 weeks, including the seminal ACM paper & I'm very impressed. I've configured and run some preliminary simulations that have my colleagues quite interested too. However, I'm finding my delay settings are yielding delays of about two orders of magnitude larger that requested. I believe I don't understand the relationship very well that defines the setting of the queue size to relative to the bandwidth setting (and plr?) Can someone explain or point me to a source for this? I recall reading that with lower bandwidths one should use lower queue sizes to avoid long queuing delays. So I presume that is why my delays are so long. So I've run some tests with various queue sizes. With Queue sizes of 100, 80, 60, 40, 10 slots on a pipe with a bw of 48Kbits/s, delay of 5ms, and plr 0.025 defined in each direction, I'm consistently getting RT delays of 500-600ms with a ping test, packet loss does come out around 5%. The target I'm pinging is normally a 40 ms latency. At Queue size 120 I get 100% packet loss (but I can ignore that). I am not a networking specialist, so I realize my question is ignorant :-) I'm running this in VMWare Server on a dual core 2 GHz with 2 GB RAM using a modification of the dummynet test network design described at codefromthe70s.org Thanks, Matthew ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
