I found a bug in iproute+tc that prevents rate correct calculation on IPQ, on BCM it was correct.
I just uploaded new builds, let me know how QOS changed.
Interesting why using ea8500 you do not face this issue...
Actually it is not bug in iproute+tc, I had time to look at this again, to fix it I created a workaround in iproute2 that works for most configs especially dd-wrt, but this bug also shows up on my desktop pc.
Thus it is not specific to this CPU and I already have an idea what's wrong, but it will take some time to go through all the kernel code. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Sun Feb 05, 2017 21:16 Post subject:
<Kong> wrote:
dissent wrote:
tatsuya46 wrote:
dissent wrote:
tatsuya46 wrote:
the new kong build fixes qos htb for this router
Wonder what's the reason
kong's pm:
<Kong> wrote:
I found a bug in iproute+tc that prevents rate correct calculation on IPQ, on BCM it was correct.
I just uploaded new builds, let me know how QOS changed.
Interesting why using ea8500 you do not face this issue...
Actually it is not bug in iproute+tc, I had time to look at this again, to fix it I created a workaround in iproute2 that works for most configs especially dd-wrt, but this bug also shows up on my desktop pc.
Thus it is not specific to this CPU and I already have an idea what's wrong, but it will take some time to go through all the kernel code.
will the fix be commited to bs builds across all ddwrt? _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Mon Feb 06, 2017 2:37 Post subject:
channel war update: qualcomm has upper upper/upper lower/lower upper/lower lower options now. but many are still invalidly listed, but there is also more valid options to pick from. info http://svn.dd-wrt.com/ticket/5699#comment:11
i think the +/- number is somewhat confusing & "lower upper" etc should fit in gui without abbreviation. took me a few mins to catch on to how bs is currently doing it but its easy now, but for an average or novice user its too sloppy in current wording (and options). _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
I found a bug in iproute+tc that prevents rate correct calculation on IPQ, on BCM it was correct.
I just uploaded new builds, let me know how QOS changed.
Interesting why using ea8500 you do not face this issue...
Actually it is not bug in iproute+tc, I had time to look at this again, to fix it I created a workaround in iproute2 that works for most configs especially dd-wrt, but this bug also shows up on my desktop pc.
Thus it is not specific to this CPU and I already have an idea what's wrong, but it will take some time to go through all the kernel code.
will the fix be commited to bs builds across all ddwrt?
Yes. Since I got to know the history of this problem and I think my fix is legit.
But if I commit now, then I get in trouble with my revs unless I intend to sync with latest svn, but I feel like I want to wait, BS is playing around with channel selection:-) _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Tue Feb 07, 2017 2:03 Post subject:
<Kong> wrote:
tatsuya46 wrote:
<Kong> wrote:
dissent wrote:
tatsuya46 wrote:
dissent wrote:
tatsuya46 wrote:
the new kong build fixes qos htb for this router
Wonder what's the reason
kong's pm:
<Kong> wrote:
I found a bug in iproute+tc that prevents rate correct calculation on IPQ, on BCM it was correct.
I just uploaded new builds, let me know how QOS changed.
Interesting why using ea8500 you do not face this issue...
Actually it is not bug in iproute+tc, I had time to look at this again, to fix it I created a workaround in iproute2 that works for most configs especially dd-wrt, but this bug also shows up on my desktop pc.
Thus it is not specific to this CPU and I already have an idea what's wrong, but it will take some time to go through all the kernel code.
will the fix be commited to bs builds across all ddwrt?
Yes. Since I got to know the history of this problem and I think my fix is legit.
But if I commit now, then I get in trouble with my revs unless I intend to sync with latest svn, but I feel like I want to wait, BS is playing around with channel selection:-)
thats good, & do u think u could help bs with channels? im still trying to convince him his builds needs channel reworkings for qualcomm, he thinks ur channel listing for vht80 is wrong & hes having a hard time understanding/believing my explanations to him about valid & invalid upper lower etc _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
thats good, & do u think u could help bs with channels? im still trying to convince him his builds needs channel reworkings for qualcomm, he thinks ur channel listing for vht80 is wrong & hes having a hard time understanding/believing my explanations to him about valid & invalid upper lower etc
Well he knows more units, thus he might be right. To me it looks like extension is not needed at all on qca and you do not need to set it in order to get the available channels, like on broadcom.
If that is the case I would completely remove the extension setting.
I mean it is super easy to just use the channel and then create the conf based on channel and width.
Anyways since I do not really publish any wrt builds right now I used this tree to peep on his changes, hopefully this is not the final result. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
