Limiter with Burst or similar solution needed

jimp

We don't have a GUI knob for it, but Limiters are based on ipfw/dummynet pipes, and those do support a burst parameter:

From ipfw(8):

burst size
If the data to be sent exceeds the pipe's bandwidth limit (and
the pipe was previously idle), up to size bytes of data are
allowed to bypass the dummynet scheduler, and will be sent as
fast as the physical link allows. Any additional data will be
transmitted at the rate specified by the pipe bandwidth. The
burst size depends on how long the pipe has been idle; the effec-
tive burst size is calculated as follows: MAX( size , bw *
pipe_idle_time).

If someone wanted to hack together a patch, it may be possible to leverage that.

SeventhSon

So you could do this, just not in GUI, I don't know enough about doing this is CLI (well, mostly, how to do it properly to make it stick across reboots/reloads of the firewall). Maybe someone else can help with that.

jimp

It might actually be easier for someone to add a field to the limiter config to do that than it would to hack it in manually.

foxale08

Got tired of waiting so I did it myself. I make no promises it works completely right. It can be cleaned up a bit and put into 2.1 if desired.

shaper_burst.patch.txt

eri--

Seems correct implementation so i committed in snapshots.
Just test it with new coming snapshots or gitsync

xbipin

problem with the patch is it doesnt upgrade the config, meaning if the old snapshot didnt have a burst value and u upgraded then u get errors in the system log untill u goto the limiter page and feed in a burst value and hit save

jimp

xbipin - I just committed a fix for that: https://github.com/pfsense/pfsense/commit/f1a17b1a085ca65fafbe28e7c36cf9fc0018f2b0
https://github.com/pfsense/pfsense/commit/e43fa2ac995158553a47a0169bfd4946fe44a81b
https://github.com/pfsense/pfsense/commit/c32e058108193d17da7085623775c94d21a8bd96

xbipin

i quiet dont understand how this burst thing works, firstly, after the patch can we set a burst as zero or blank and secondly if burst is set to 1mb and the pipe also to 1mb and the link supports 2mb then how would it actually work?

jimp

Burst is an amount of data, it is not a rate

Setting a burst of blank/0 is OK and what most people will do to not allow bursting.

If you have a 1Mbit/s limit and a 1MB burst, then the user will get 1MB of data at full speed, then be limited to 1Mbit/s.

In this example, with no burst set, the user will be limited to 1Mbit/s at all times.

xbipin

so wouldnt it be better to put some description on that page saying burst is actual data and not rate and secondly the rules.limiter file shows me this


pipe 1 config  bw 480Kb burst 480Kb

pipe 3 config  bw 400Kb burst 400Kb

isnt the burst supposed to be KB and not Kb and also the interface doesnt allow to specify the unit separately for rate and burst

jimp

@xbipin:

so wouldnt it be better to put some description on that page saying burst is actual data and not rate and secondly the rules.limiter file shows me this
pipe 1 config  bw 480Kb burst 480Kb
 

pipe 3 config  bw 400Kb burst 400Kb
isnt the burst supposed to be KB and not Kb and also the interface doesnt allow to specify the unit separately for rate and burst

The description could be better, yes. I don't know about the ipfw syntax.

foxale08

Has anyone been able to make burst work as expected? Speed tests have not shown evidence of the bursting parameter on the child queues in my config. My current assumptions are that either the "pipe_idle_time" is impossibly low as burst values many orders of magnitude higher produce no results and/or the burst only applies to the first packet sent through an idle link. (I took a quick glance at the current dummynet source, I have limited understanding of C/C++ syntax at present.) Some online have suggested changing the kern.hz parameter in /boot/loader.conf (/boot/loader.conf.local). Additionally, would an expire of 1 cause a link to never be considered idle as it is removed so quickly (net.inet.ip.dummynet.expire=1). What do you guys think?

pipe 1 config  bw 14Mb burst 80Mb
queue 1 config pipe 1 mask dst-ip6 /128 dst-ip 0xffffffff
queue 2 config pipe 1 mask dst-ip6 /128 dst-ip 0xffffffff
queue 3 config pipe 1 mask dst-ip6 /128 dst-ip 0xffffffff

pipe 2 config  bw 2.5Mb burst 40Mb
queue 4 config pipe 2 mask src-ip6 /128 src-ip 0xffffffff
queue 5 config pipe 2 mask src-ip6 /128 src-ip 0xffffffff
queue 6 config pipe 2 mask src-ip6 /128 src-ip 0xffffffff

*bw values are half of ISP provided bandwidth.

Edit: Burst does work, but I can only prove it at a 'bw' of 25Kb using ping…

stephenminta

foxale08 did you ever get any further with this, I am seeing exactly the same results as you with regards to the burst setting.

Thanks

eri--

The burst setting will not be applied unless the queue is congested.

So unless you fill the pipe you will not see the effect of bursting.

stephenminta

Thanks Ermal. Am I correct in saying then that if I use the settings in the attached screen shot each ip address using more than 2mb of bandwidth (i.e. congesting the queue) will be allowed to burst to the max bandwidth available on the interface until it has passed 10mb of data and then it will drop back to the 2mb rate. In real world use should this not mean that if I run a speedtest from say speedtest.net I should see it burst above 2mb then back equally if I run jperf there should be an initial burst followed by a consistent 2mb.

Many thanks

traffic_limit.jpg_thumb

eri--

It is per session.

So you have to congest the link with bittorrent or similar and then run speed test.
Probably there you will see the burst.

rmssf

Burst setting does not work.
I've set up a limiter with bw 2Mb and 20MB burst, however didnt see any initial burst, bw limited at 2Mb all the time since start.
I wonder if Ermal did any test at all using the burst setting, or have just assumed the other users got it all wrong.

eri--

It seems this is getting a trend in this forum about accusing people of implementation.

Good luck with it since you earned my silence.

rmssf

Can't believe no one here can test and verify that the burst setting in LIMITER pipes is NOT working!
Yet the updates keep mentioning this feature…

@ermal:

It is per session.

So you have to congest the link with bittorrent or similar and then run speed test.
Probably there you will see the burst.

Here's the official FreeBSD documentation about this setting, no mention whatsoever about "link congestion":

burst size
If the data to be sent exceeds the pipe's bandwidth limit (and
the pipe was previously idle), up to size bytes of data are
allowed to bypass the dummynet scheduler, and will be sent as
fast as the physical link allows. Any additional data will be
transmitted at the rate specified by the pipe bandwidth. The
burst size depends on how long the pipe has been idle; the effec-
tive burst size is calculated as follows: MAX( size , bw * pipe_idle_time).

Instead, it states that there will be a burst only if the pipe was idle (which makes sense), instead of congested.

Note: I'm using pfsense 2.1.4 - i386 version.

mhohman

We are seeing the same issue of the burst parameter being ignored.

100mbit pipe. Limiting to 12mbit per session with a 20 in the burst field. All sessions limited to 12mbit each. I have even tried a 9999 in the burst field with no result. Turning off the limiter I see a full 94mbit.

I really wish this feature worked as advertised it would be a huge win for us.