HFSC session vs queue behaviour
It's unfortunate that the post below is closed and nobody ever replied because I'm trying to get to grips with the very issue it raises.
Iam still a bit newbie to pfsense, so if iam wrong correct me
in 2.0-ALPHA-ALPHA ( built on Wed Sep 23 11:28:05 UTC 2009 ) the hfsc traffic shaper upper-limit parameters ( m1, d, m2 ) used to limit traffic per session, that if session started ( new connection ) it can have m1 KBytes for d miiliseconds then it will not take more than m2 KBytes for the remaining time, and if another session ( belongs to the same queue ) started it used to take the same m1 KBytes for d miiliseconds ( although the previous session is still getting m2 Kbytes only ) , this behaviour was so useful and fair , and i thought that this is what hfsc was all about.
But now in pfsense 2.0-BETA hfsc upper limit doesn't work per session biases ( as i tested it ) if a session started with its m1 KBytes for d miiliseconds then get limited to m2, any new session starts; gets only m2 directly, even if this session was from another ip ( but belongs to the same queue of course ).
i just wanted to know if this is a bug or this is the normal behavior,
I want per session service curves, not per queue.
I've just set up an experiment setting an upper limit curve on my default WAN->LAN queue of m1=100%,d=2000,m2=10% as per the attachment.
Downloads were performed using a couple Linux boxes using:
I see a single transfer throttle down as expected after two seconds, but then a subsequent connection started concurrently doesn't see any initial boost, but runs at the slower (m2) speed. This applies both to other downloads started on the same machine and the other one.
The upper-limit is thus clearly being applied to the whole queue, not per session. How do I control per session behaviour?
![Screen Shot 2014-06-07 at 11.39.13.png](/public/imported_attachments/1/Screen Shot 2014-06-07 at 11.39.13.png)
![Screen Shot 2014-06-07 at 11.39.13.png_thumb](/public/imported_attachments/1/Screen Shot 2014-06-07 at 11.39.13.png_thumb)