Hi Michael,
On Nov 17, 2014, at 18:39 , Michael Richardson <m...@sandelman.ca> wrote:
>
> Richard Mortimer <richm+open...@oldelvet.org.uk> wrote:
>> I think I saw something similar when I was using an ADSL connection.
>
>> When the connection was under full load (I don't remember whether it
>> was upstream, downstream or both) the LCP echo requests that PPPD does
>> seem to get dropped somewhere in the ADSL infrastructure. The link is
>> however working fine passing "real" traffic.
>
> Sounds like the something a proper BQL limit on the etherne/ATM part of the
> PPPoE coud fix. For PPPoE, traffic shapping should occur on the PPP
> interface
Note SQM does not care too much where you put the shaper,but if you
shape one the pppoe device the pop maintenance packets are never seen by SQM so
they will not be dropped. Shaping on the raw ATM device (in your case) should
also work (never tested this myself as I have no open dsl-router), but almost
all packets will end up in the default queue (I think) as the packet
classification can not see through the pop encapsulation. Also if you want to
go that route you shold make sure the PPP maintenance packets get their own
highest priority queue… (as dropping enough of those will most likely drop your
connection, luckily they do not cost a lot of bandwidth...)
> and should probably run at no more than 99% of the real link
> capacity (if you can determine it...sigh),
In my limited experience the link speed as reported by the modem was
always the correct brute link speed that SQM’s link layer adjustments could
work with, so maybe just taking the values the modem part of your router
reports and subtract say 3% on egress and 10% on ingress should be a decent
starting point.
> the LCP messages should bypass that part.
Unless you shape on the ATM device ;)
> DSL with the modem built-in ought to auto-adjust the bandwdth viaBQL
> perfectly…
For egress/upstream (I really hope we will get something like that in
the future); bit for ingress/downlink you still need a properly configured
shaper until the DSLAMs/MSANs/BRASs learn BQL fq_codel (which might take a
while)
Best Regards
Sebastian
>
> --
> ] Never tell me the odds! | ipv6 mesh networks
> [
> ] Michael Richardson, Sandelman Software Works | network architect
> [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
> [
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
