Shaper Bug
-
Well, let me correct myself. It's not 4 UpLoad Queues. Its 4 Queues that r used to address the upload, e.g.: Bulk, and High Prio.
So I put in the MAIN upload a hard limit of 4MBits. Then each one of the Queues that r used for Upload will use 4MBits, summing up 16MBits.
Example: Bulk Queue will take advantage of 4MBits and High Prio Queue more 4MBits, simultaneously. This happens, despite the fact that 4MBits SHOULD be the hard limit shared by every and all Queues.
Again, this fenomenon happens just for UPLOAD, the DownLoad shaping is working right.
Perhaps for this reason so many users report a messed Shaping, as according to various tests we conducted, the pfsense shaper performs mostly very well.
Att, SharingZee.
-
Where are you seeing this? In the queue graphs?
The main purpose of the "sub"-queues that are a part of the main queues is to guarantee or restrict bandwidth for a certain type of traffic withing the main queue.
-
Well, let me correct myself. It's not 4 UpLoad Queues. Its 4 Queues that r used to address the upload, e.g.: Bulk, and High Prio.
So I put in the MAIN upload a hard limit of 4MBits. Then each one of the Queues that r used for Upload will use 4MBits, summing up 16MBits.
Example: Bulk Queue will take advantage of 4MBits and High Prio Queue more 4MBits, simultaneously. This happens, despite the fact that 4MBits SHOULD be the hard limit shared by every and all Queues.
Hrm…the *up queues are setup identical to the *down queues and the way ALTQ works, a subqueue can't possibly exceed the bandwidth assigned to the parent queue. If the parent is set to 4Mbit, no child should ever be able to exceed 4Mbit. I'm not sure why (or how) you're seeing this.
--Bill
PS. if your line speed is 4Mbit, no way in hell can ALTQ let you upload at 8Mbit - this feels more like a display bug if you're seeing this.
-
No, no, no. My Upload connection is 40MBit, and the Upload Shaper is really screwed. It IS pushing 16MBit Upload.
-
Well, let me correct myself. It's not 4 UpLoad Queues. Its 4 Queues that r used to address the upload, e.g.: Bulk, and High Prio.
So I put in the MAIN upload a hard limit of 4MBits. Then each one of the Queues that r used for Upload will use 4MBits, summing up 16MBits.
Example: Bulk Queue will take advantage of 4MBits and High Prio Queue more 4MBits, simultaneously. This happens, despite the fact that 4MBits SHOULD be the hard limit shared by every and all Queues.
Hrm…the *up queues are setup identical to the *down queues and the way ALTQ works, a subqueue can't possibly exceed the bandwidth assigned to the parent queue. If the parent is set to 4Mbit, no child should ever be able to exceed 4Mbit. I'm not sure why (or how) you're seeing this.
--Bill
PS. if your line speed is 4Mbit, no way in hell can ALTQ let you upload at 8Mbit - this feels more like a display bug if you're seeing this.
There is no child queue exceeding 4MBit. The sum of them all: 4x 4MBit, exceeds 4MBit, since 4x4=16, right? There is the bug, they r being SUMMED UP.
-
There is no child queue exceeding 4MBit. The sum of them all: 4x 4MBit, exceeds 4MBit, since 4x4=16, right? There is the bug, they r being SUMMED UP.
No, these are child queues of a parent queue which holds the bandwidth settings.
-
No, no, no. My Upload connection is 40MBit, and the Upload Shaper is really screwed. It IS pushing 16MBit Upload.
So what's the download being shaped at? And is it working as advertised?
–Bill
-
So, lets put it another way:
How can the pfSense user limit the TOTAL UPLOAD to 4MBit? Who has achieved this feat (for REAL)?Att, SharingZee.
PS.: Of course: 4MBit dinamically shared by the children Queues.
-
So, lets put it another way:
How can the pfSense user limit the TOTAL UPLOAD to 4MBit? Who has achieved this feat (for REAL)?Att, SharingZee.
PS.: Of course: 4MBit dinamically shared by the children Queues.
We just found a major bug that has been present since 0.94ish.
The bug is in the kernel and really wrecks traffic shaping. Please wait until the next version and test again.
-
Yeah, I've tested 0.96.4. The bug remains intact.
-
Uh, it wasn't fixed in 0.96.4.