[Cerowrt-devel] Cero 3.10.24-5 no longer supports multiple AQMs?
rocon46 at hotmail.com
Wed Dec 25 10:33:28 EST 2013
> Dave Taht <dave.taht <at> gmail.com> writes:
> I should do a lecture on all the useful stuff a practiced eye can see
> with them. That said, they are terribly noisy and an unpracticed eye
> often mis-interprets the peaks and valleys.
> > fq_codel does everything really well, and I had no idea fq_codel can still
> > differentiate between UDP EF traffic and UDP BE traffic w/o having to
> > prioritize them into different htb leafs first. I guess that kinda makes my
> > classification rules redundant, I suppose.
> No, presently fq_codel does not prioritize diffserv into different htb leaves.
> That is the "simple.qos" script doing that. "simplest.qos" doesn't. I
> have generally found that simplest does a pretty darn good job... but
> I strongly suspect prioritization at your bandwidth levels is required.
> Someday, perhaps, we'll pour this into c, and make something faster
> than htb. I have some thoughts towards doing that....
> Please feel free to try simplest.qos in your environment, though.
> > Anyway, I got the idea shaping inbound traffic didn't do much while I was
> > looking up about what Cero and fq_codel was about waaay back when I was
> > deciding on whether I should try it out. I'm not sure which forum I stumbled
> > upon, learning that particular bit of information, but that's all I took
> > from it. It's good to know I was wrong.
> I have spent a ton of time correcting websites. (I run a regular google
> search for bufferbloat but it doesn't catch everything)
> I wish it were possible
> to update the lart stuff, like the howtos - they are impossibly outdated
> and the first hits you get point to things that are massively wrong for
> todays environments, like wondershaper.
> Recently I spent some time fixing this script, for example. As posted
> originally it was just so terribly, terribly wrong.
> > Also, you don't have to bother looking at my script. Everything works as
> > well as I could hope for and I'm sure you have much more important things to
> > be focused on. Again, thanks for taking the time to help out a smuck
> No, I always learn things from how people do stuff differently. I
> ended up writing
> a bit of a rant on wondershaper while I looking at yours, in a weird
> sort of result.
> In your case I have a couple thoughts. I think there is a strong need,
> particularly at low bandwidths, to have
> some ability to strongly prioritize a given host's packets (gaming boxes being
> the most important) and that ability isn't in cero.
> I can be faulted for mostly testing at 20/4 mbit and above, since that's what
> I have, and the way the world is going... prioritization counts for much less
> then, and packetization helps ever more.
Ah. My mistake. I guess I got confused by the 'no classification' in the top
right corner of the aqm script result and just assumed otherwise.
Yeah, I always saw 'dtaht' pop in a lot, correcting misinformation and the
like, back when I was visiting websites looking into 3rd party firmware. I
think that's how I ended up finding out about Cero, actually.
Huh, while I was going through that page, I noticed that Cero's HTB quantum
setting doesn't include the 14 byte ethernet header. Is that intended? I
guess Cero could be rigged to work it out automatically, 'cause I remember a
discussion awhile back about the broken htb_stab mentioning something about
Well, maybe LUCI doesn't have a GUI option for it, but I always thought
writing a few lines and editing the scripts slightly yourself would do the
job. Creating a filter to dump the game console's ports in prio 0 seems to
do the job. Shame you can't specify an IP within the network for ifb0,
though. Works for all the other interfaces but never that one. Just doing
ports works fine as a workaround, and everything seems to works nicely...
(I'd post these next to their corresponding paragraphs, but I kept getting
an error message to prune quotes, so for now I've just given up.)
More information about the Cerowrt-devel