hmm. The pppoe LLC packets are sparse and should already be optimized by fq_codel, but I guess I'll go look at the construction of those headers. Perhaps they need to be decoded better in the flow_dissector code?
I also made some comments re the recent openwrt pull request. https://github.com/dtaht/ceropackages-3.10/commit/b9e3bafdabb3c5aa47f8f63eae2ecfe34c361855 SQM need not require the advanced qdiscs package, if it checks for availability of the other qdiscs, and even then nobody's proposed putting the new nfq_codel stuff into openwrt - as it's still rather inadaquately tested, and it's my hope that cake simplifies matters significantly when it's baked. I already have patches for sqm for it, but it's just not baked enough... Also I think exploring policing at higher ingres bandwidths is warrented... On Wed, Oct 15, 2014 at 6:39 AM, Sebastian Moeller <moell...@gmx.de> wrote: > Hi Edwin, > > > On Oct 15, 2014, at 14:02 , Török Edwin <edwin+ml-cero...@etorok.net> wrote: > >> On 10/15/2014 03:03 AM, Sebastian Moeller wrote: >>> I guess it is back to the drawing board to figure out how to speed up >>> the classification… and then revisit the PPPoE question again… >> >> FWIW I had to add this to /etc/config/network (done via luci actually): >> option keepalive '500 30' >> >> Otherwise it uses these default values from /etc/ppp/options, and then I >> hit: https://dev.openwrt.org/ticket/7793: >> lcp-echo-failure 5 >> lcp-echo-interval 1 >> >> The symptomps are that if I start a large download after half a minute or so >> pppd complains that it didn't receive reply to 5 LCP echo packets and >> disconnects/reconnects. > > I have not yet seen these in the logs, but I will keep my eyes open. > >> Sounds like the LCP echo/reply packets should get prioritized, but I don't >> know if it is my router that is dropping them or my ISP. > > I think that is something we should be able to teach SQM (as long as > the shaper is running on the lower ethernet interface and not the pppoe > interface). > >> >> When you tested PPPoE did you notice pppd dropping the connection and >> restarting, cause that would affect the timings for sure… > > Nope, what I see is simply more variance in bandwidth and latency > numbers and a less step slope on a right shifted ICMP CDF… I assume that the > disconnect reconnects should show up as periods without any data transfer…. > > Mmmh, I will try to put the PPP service packets into the highest priority > class and see whether that changes things, as well as testing your PPP > options. > > Thanks for your help > > Sebastian > >> >> Best regards, >> --Edwin >> >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
