> On Jan 20, 2016, at 7:06 AM, Alan Jenkins wrote: > > > No offense to your work on sqm-scripts. > > > 1) It's just in case the problem is *outside* of sqm-scripts, it could be useful to try the minimum commands necessary to demonstrate the problem. Maybe it's unfair but I assumed running on a PC is also a less tested case, as well as the "firewall on a stick" part. > > Equally, since AFAICT Brandon hasn't had a working AQM setup on this box before. It could be useful if the Gentoo script works, to prove that AQM + fq_codel can work correctly on Brandon's box. > > If the Gentoo script _wasn't_ working, that's when I'd suggest tearing it down e.g. to eliminate fq_codel as an issue. Rather than specify fifo explicitly, just don't run the fq_codel command (assuming that actually does something sensible, which can be checked using `tc qdisc`). > > > 2) More specifically, you didn't mention trying "simplest.qos". This would i) simplify the setup we're trying to debug, and ii) it might show if there's a bug with the more complex bandwidth calculations / assignments in "simple.qos". > > > And again - I suggest starting by checking `tc class show dev eth0.666`, because it's not a 100% obvious command, and we don't want to miss if there are bad rates there :). > > > Alan Wow, thanks for all the ideas and feedback. I did indeed find the Gentoo wiki script and gave it a shot - basically the same behavior as sqm-scripts. I’m really thinking my on-a-stick topology is tying things in knots as my traffic is on the same interface twice in inverse directions. I have another NIC in the box used for some back end NFS stuff - I can steal him temporarily to rejigger my interfaces. My goal is to get eth0.666 to just be eth0 (public wan, no dot1q). I’ll post my results from this - and barring any great success there - will loop back to this thread and try what folks have mentioned. We are snowed in today so the kids are home from school - I’m sure I’ll get plenty of feedback from them - ‘dad the internet is down’. :)