Re: Bursty data transfer with Dummynet
Your queue is too large, 500K is a lot. The default is 50 slots. 100 slots usually works well as well. I would try first: ipfw pipe 1 config bw 500k -- Matthew Ahmed Hamza wrote: Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Bursty data transfer with Dummynet
I'm not sure if this would explain anything. But I am running DummyNet on a VirtualBox VM on an Ubuntu host. I have also experienced the same behaviour with both Frenzy (a FreeBSD based LiveCD) and Ubuntu guests. In the case of Frenzy, the tick was set to 1000Hz. But the host tick was 250Hz since it is an Ubuntu machine. Also, the delay between bursts is in order of seconds! My assumption about DummyNet is that while the queue is being drained new packets will be queued (i.e. there is no waiting to fill the queues before transmitting them using the specified bandwidth). On Tue, Nov 12, 2013 at 9:21 PM, Julian Elischer jul...@freebsd.org wrote: On 11/12/13, 9:06 PM, Ahmed Hamza wrote: On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer jul...@freebsd.org wrote: On 11/12/13, 6:35 PM, Ahmed Hamza wrote: Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. I would expect that that would give a queue kick every 4 mSec or so so you should get a burst every 4mSec or so. but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid you'll have to talk to Luigi to know what happens in such a case.. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte root@nsl-vm1:~/# ipfw show 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any 65535 2245577 2648958386 allow ip from any to any root@nsl-vm1:~/# ipfw pipe show 1: 500.000 Kbit/s0 ms 500 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.56.1/33547192.168.56.4/80238083 134515909 00 623 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Bursty data transfer with Dummynet
seriously? you expect that kind of precise timing running in a VM? -lee On 11/13/2013 16:29, Ahmed Hamza wrote: I'm not sure if this would explain anything. But I am running DummyNet on a VirtualBox VM on an Ubuntu host. I have also experienced the same behaviour with both Frenzy (a FreeBSD based LiveCD) and Ubuntu guests. In the case of Frenzy, the tick was set to 1000Hz. But the host tick was 250Hz since it is an Ubuntu machine. Also, the delay between bursts is in order of seconds! My assumption about DummyNet is that while the queue is being drained new packets will be queued (i.e. there is no waiting to fill the queues before transmitting them using the specified bandwidth). On Tue, Nov 12, 2013 at 9:21 PM, Julian Elischer jul...@freebsd.org wrote: On 11/12/13, 9:06 PM, Ahmed Hamza wrote: On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer jul...@freebsd.org wrote: On 11/12/13, 6:35 PM, Ahmed Hamza wrote: Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. I would expect that that would give a queue kick every 4 mSec or so so you should get a burst every 4mSec or so. but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid you'll have to talk to Luigi to know what happens in such a case.. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte root@nsl-vm1:~/# ipfw show 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any 65535 2245577 2648958386 allow ip from any to any root@nsl-vm1:~/# ipfw pipe show 1: 500.000 Kbit/s0 ms 500 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.56.1/33547192.168.56.4/80238083 134515909 00 623 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Bursty data transfer with Dummynet
On 11/13/13, 2:22 PM, Lee Dilkie wrote: seriously? you expect that kind of precise timing running in a VM? the fact that it is in a vm only just came out... still I'd expect better than several seconds.. -lee On 11/13/2013 16:29, Ahmed Hamza wrote: I'm not sure if this would explain anything. But I am running DummyNet on a VirtualBox VM on an Ubuntu host. I have also experienced the same behaviour with both Frenzy (a FreeBSD based LiveCD) and Ubuntu guests. In the case of Frenzy, the tick was set to 1000Hz. But the host tick was 250Hz since it is an Ubuntu machine. Also, the delay between bursts is in order of seconds! My assumption about DummyNet is that while the queue is being drained new packets will be queued (i.e. there is no waiting to fill the queues before transmitting them using the specified bandwidth). On Tue, Nov 12, 2013 at 9:21 PM, Julian Elischerjul...@freebsd.org wrote: On 11/12/13, 9:06 PM, Ahmed Hamza wrote: On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischerjul...@freebsd.org wrote: On 11/12/13, 6:35 PM, Ahmed Hamza wrote: Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. I would expect that that would give a queue kick every 4 mSec or so so you should get a burst every 4mSec or so. but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid you'll have to talk to Luigi to know what happens in such a case.. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte root@nsl-vm1:~/# ipfw show 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any 65535 2245577 2648958386 allow ip from any to any root@nsl-vm1:~/# ipfw pipe show 1: 500.000 Kbit/s0 ms 500 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.56.1/33547192.168.56.4/80238083 134515909 00 623 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail tofreebsd-ipfw-unsubscr...@freebsd.org ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Bursty data transfer with Dummynet
On Wed, Nov 13, 2013 at 6:06 AM, Ahmed Hamza ahmed@gmail.com wrote: On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer jul...@freebsd.org wrote: On 11/12/13, 6:35 PM, Ahmed Hamza wrote: Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte root@nsl-vm1:~/# ipfw show 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any 65535 2245577 2648958386 allow ip from any to any root@nsl-vm1:~/# ipfw pipe show 1: 500.000 Kbit/s0 ms 500 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.56.1/33547192.168.56.4/80238083 134515909 00 623 to debug the problem i'd first try removing/reducing the queue size, because you are queueing 8 seconds of data and that may interact badly with whatever flow control protocol you have implemented (even if you are using tcp underneath, you might have some logic in your app that decides when to send, etc.) Also, try to start with a very high bandwidth and gradually reduce it and see if there is a point where behaviour suddenly changes. As julian pointed out, dummynet works on a tick, but at the rates you are using the granularity should not matter much. And, to answer another poster, modern hardware is pretty good at running VMs with millisecond or less ticks. cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Bursty data transfer with Dummynet
On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer jul...@freebsd.org wrote: On 11/12/13, 6:35 PM, Ahmed Hamza wrote: Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte root@nsl-vm1:~/# ipfw show 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any 65535 2245577 2648958386 allow ip from any to any root@nsl-vm1:~/# ipfw pipe show 1: 500.000 Kbit/s0 ms 500 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.56.1/33547192.168.56.4/80238083 134515909 00 623 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Bursty data transfer with Dummynet
On 11/12/13, 6:35 PM, Ahmed Hamza wrote: Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. Thanks, -Ahmed ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Bursty data transfer with Dummynet
On 11/12/13, 9:06 PM, Ahmed Hamza wrote: On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer jul...@freebsd.org wrote: On 11/12/13, 6:35 PM, Ahmed Hamza wrote: Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. I would expect that that would give a queue kick every 4 mSec or so so you should get a burst every 4mSec or so. but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid you'll have to talk to Luigi to know what happens in such a case.. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte root@nsl-vm1:~/# ipfw show 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any 65535 2245577 2648958386 allow ip from any to any root@nsl-vm1:~/# ipfw pipe show 1: 500.000 Kbit/s0 ms 500 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.56.1/33547192.168.56.4/80238083 134515909 00 623 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
