On 2011/10/30 15:41, Daniel Melameth wrote: > On Sun, Oct 30, 2011 at 2:37 PM, Christopher Zimmermann > <madro...@zakweb.de> wrote: > > Bandwidth shaping on PPPoE links is difficult, because you don't know > > what the modem will do to you packets. > > > > On my DSL PPPoE links the DSL modem sends the ethernet frames over an > > ATM circuit and adds additional, but not constant overhead to each > > packet in the process. > > > > The consequence is that the raw IP throughput (which is limited by the > > traffic shaper) which will saturate the link is smaller for small IP > > packets and larger for large IP packets. > > > > Now, one could determine the ATM bandwidth needed by a certain packet > > by calculating the number of ATM cells needed to encapsulate the > > packet. > > > > I made some measurements on my upstream link (224 kbaud). The extreme > > cases are: > > > > 261pps of very small (56 byte) TCP/IP packets. > > This makes 14.27 kbps of IP traffic. > > But 527 ATM cells are used per second. > > > > 17pps of the largest possible (1448 byte) TCP/IP packets. > > This makes 24.04 kbps of IP traffic. > > But 522 ATM cells are used per second. > > > > So the number of used ATM cells would be a better measure for traffic > > shaping on PPPoE(oA) links. > > > > I'm thinking of adding an option to altq that would estimate bandwidth > > usage by calculating the number of needed ATM cells. Is this the right > > approach and is there a chance to get this into the tree? > > sthen@ created a patch a while back that addresses > this--http://ns2.spacehopper.org/openbsd/base/altq_tbradapt.diff--but > I have not used it in a while. >
That diff needs rewriting to be configurable from userland rather than just having a few preset options in the kernel, but seeing as altq is being replaced I think it makes sense to wait until the new prioritisation code can limit output to a rate less than the interface bandwidth.
