Hi Kevin,
On Jun 6, 2015, at 15:38 , Kevin Darbyshire-Bryant
<[email protected]> wrote:
> Hi Chaps,
>
> Guess who :-) Following on from my probably rash assertion that BT here in
> the UK probably aren't as bad at bufferbloat from them to end user due to
> rate limiting as I think, it has reminded me of my parents' situation and
> efforts to help them.
>
> Scenario is: ADSL very long line (hopefully they've got the copper repaired
> now) so on a good day the ADSL sync is something like 2Mbit down, 512kbit up.
> I bought them a Netgear DGN3500 which is now running OpenWrt CC (+cake) This
> is not my preferred solution in hardware terms but it has a supported
> built-in ADSL modem so is a one box solution.
>
> The problem I have is setting outbound rate limiting. I was hoping that
> 'cake' without the 'bandwidth' parameter would work on the 'backpressure'
> from the ATM(?) driver, sadly this wasn't the case and so setting a bandwidth
> limit (I'm not in a position to test the new keywords for ATM encapsulation
> etc yet) was the only way forward.
This is rather important to get right, ATM’s arcane 48/53 encapsulation
only leaves 100*48/53 = 90.5% of the sync rate for useable bits, and even those
need to contain all the headers specific to your line (plus AAL5’s unfortunate
choice of fitting each packet into an integer number of ATM cells), mean that
without AQM taking the link layer encapsulation into account you need to aim
for roughly 80-85% of the sync rates on and ATM link. With a link that
disappears often I currently would recommend sqm-scripts as weapon of choice
(you should be able to get cake into sqm-scripts) as the IFB needs to be set up
again after the “connected” interface reappears, which current sqm-scripts
should do for you...
> Unfortunately the ADSL link isn't rock solid stable so the negotiated rates
> for in & out flap around a bit. So a few questions:
That is bad and will need special care; on the positive side we might
be able to include your solution for this issue into sqm-scripts so that this
only needs solving/working-around once ;)
>
> 1) ATM interface 'backpressure' - is this Byte Queue Limits? (ifxmips_atm)
Is there actual backpreassure from your ATM diver at all? As rar as I
know france’s free had their boxes ATM driver modified to keep buffering low,
and I believe David Woodhouse dd some work on another driver/the generic ATM
layer, but I am not sure that any ATM driver actually defaults to sane
buffering and sane back pressure.
> 2) Do byte queue limits apply to outbound only?
Don’t know, they certainly affect outbound on drivers that actually
implement that feature, as far as I know all ethernet so far.
> 3) Horrid thought - this probably isn't just the ATM driver as IP is
> provisioned over PPP. PPP driver needs BQL too?
Don’t think so, I have cerowrt terminating a PPPoE link and outbound
shaping just works as expected. Then again I actually have a shaper set to 95%
of the sync rate, but that is caused by my ISP being daft and implementing a
throttle at the BRAS level which I need to target for shaping, but that’s why I
do not reach 100% on egress ;) YMMV.
>
>
> So another approach is to query the ATM interface on every IF up (which
> should get reflected into the the PPP interface up) for its current
> negotiated sync rates and use those as input into the SQM scripts.
That sounds like a decent approach, but why not simply do this every
hour instead/in addition?
>
> There's a question here that's niggling me at the back of my mind: How is
> this supposed to work with a two box modem and router solution? I guess the
> modem should ideally be running some sort of outbound AQM and dropping
> packets on its ethernet interface that just won't fit/queue too long.
How this is supposed to work? In an ideal work the CPE and the DSLAM
would not over-buffer and www would not have to dedicate grey matter to work
around their sort-commings ;) But as far as I can tell DSL sync rates for many
lines are stable over weeks to months, so setting the shaper rarely is
sufficient. Like when you notice that latency under load got worse…
Best Regards
Sebastian
>
> Sorry, too many questions and I've not enough programming experience let
> alone linux kernel experience to be able to help. I'll try if someone can
> point me in a direction.
>
> Kevin
>
>
>
> _______________________________________________
> Bloat mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
