Bursty data transfer with Dummynet

[Ahmed Hamza]

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 <julian at freebsd.org> wrote:
> On 11/12/13, 9:06 PM, Ahmed Hamza wrote:
>>
>> On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer <julian at 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 at vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte
>>
>> root at 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 at nsl-vm1:~/# ipfw pipe show
>> 00001: 500.000 Kbit/s    0 ms  500 KB 1 queues (1 buckets) droptail
>>      mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
>> BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes
>> Pkt/Byte Drp
>>    0 tcp     192.168.56.1/33547    192.168.56.4/80    238083 134515909
>> 0    0 623
>>
>