Bursty data transfer with Dummynet

[Lee Dilkie]

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 <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
>>>
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"