Hi Dave,
On Oct 15, 2014, at 19:28 , Dave Taht <dave.t...@gmail.com> wrote:
> 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?
So when shaping on pppoe-ge00 one does not see the LLC packets at all
(tested with tcpdump -i pppoe-ge00), since they are added after the shaping.
(tcpdump -i ge00 does see th dllc packets) I have no idea whether pppd issues
these with higher priority or not.
>
> 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,
Well, but how to do this, I know of no safe way, except testing
availability of modules for a known set of qdiscs, but what if the qdiscs are
built into a monolithic kernel? Does anyone here have a good idea of how to
detect all qdiscs available to the running kernel?
Best Regards
Sebastian
> 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
