[Bloat] ADSL, ATM drivers, bloat, education & confusion

[Kevin Darbyshire-Bryant]

On 06/06/15 15:29, Sebastian Moeller wrote:
> 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.
That was my sort of point.  On 'planet Kevin' (don't go there) the ATM 
driver would *know* the link is busy, or how many bytes it still had to 
shove over it and could offer some clue back up the stack to not bloat.  
I thought that's what BQL was supposed to do.  Or another way of 
viewing:  If ethernet interfaces ideally implement BQL why shouldn't ATM?

>
>
> 	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…
Well again on 'planet Kevin' the CPE is OpenWrt.  Apparenly it's under 
my control but I'm fighting my own lack of abilities, trying to sprint a 
marathon before I can even crawl.  Looking at kernel sources when I can 
barely get 'hello world' to compile & run is asking for trouble :-)  
About a day ago I didn't know what an SKB was. 
https://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ 
has been a revelation.
>
> Best Regards
> 	Sebastian
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4791 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150606/3a25c013/attachment-0002.bin>