I would like it if we had a couple per-provider recomendations and relevant discussion.
On Sat, Dec 28, 2013 at 11:36 PM, Sebastian Moeller <[email protected]> wrote: > Rich Brown <[email protected]> wrote: >>QUESTION #2: How does CeroWrt use info gleaned from the link layer >>adaptation? > > The link layer adaptations work in correcting the kernels estimate of a > packets behavior on the wire. In the tc_stab case the kernel calculates the > effective size of the packet on the wire, that is it pretends the packet is > larger than it really is, so for a given bandwidth it estimates the correct > time it takes for that packet to be actually transmitted. In the htb_private > case the kernel keeps the packet's size (more or less) intact but adjusts its > estimate of the packets transmit rate. Both methods boil down to the same > idea, make sure the packet scheduler will only send packet N+1 after packet N > has just cleared the wire. > >> >>Specifically, the link layer adaptation all seem to be designed to >>compute the actual time it takes to transmit a packet, accounting for >>Ethernet & PPPoE header bytes, other overhead, and ATM 48-in-53 >>framing. > > And the annoying size dependent padding of the last ATM cell. > >> >>How does CeroWrt use this time calculation? Does it simply make sure >>that the target time doesn’t get too low for a particular flow’s queue? > > Thanks to the link layer adjustments (lla) cero now estimates the > correct time each packet takes and will not send any faster than the shaped > rate allows. If no lla is performed cero would overestimate the link > capacity, send more than expected and potentially fill the modems bloated > buffers. Traditionally people tried to reduce their shaped rate by >10% to at > least account for the 48 in 53 framing, but failed miserably for small > packets since overhead and padding can more than double the wire size of a > packet. Note that ACQ packets typically are small as are voice over IP > packets. > > I hope this helps > Sebastian > >>(I could imagine that a short packet over ATM would take 2x the (naive) >>expected/calculated time for a packet of that length, and that flow >>would be penalized. Is there more to it?) >>_______________________________________________ >>Cerowrt-devel mailing list >>[email protected] >>https://lists.bufferbloat.net/listinfo/cerowrt-devel > > Hi Rich > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
