On Mon, 2006-03-13 at 19:49 -0500, Jason Boxman wrote: > So, instead of > > PPPoA + VC/Mux: tc class add htb … overhead 10 atm > PPPoA + VC/LLC: tc class add htb … overhead 18 atm > PPPoE + VC/Mux: tc class add htb … overhead 34 atm > PPPoE + VC/LLC: tc class add htb … overhead 42 atm > > we have? > > PPPoE + VC/Mux: tc class add htb … overhead 20 atm ? > PPPoA + ?: tc class add htb … overhead ? atm ? The complete table, for the _outbound_ direction going over an Ethernet link is: PPPoA + VC/Mux: tc class add htb … overhead -8 atm PPPoA + VC/LLC: tc class add htb … overhead 4 atm PPPoE + VC/Mux: tc class add htb … overhead 20 atm PPPoE + VC/LLC: tc class add htb … overhead 28 atm The complete table for incoming traffic on the IMQ device, regardless of the type of connection, is: PPPoA + VC/Mux: tc class add htb … overhead 10 atm PPPoA + VC/LLC: tc class add htb … overhead 18 atm PPPoE + VC/Mux: tc class add htb … overhead 34 atm PPPoE + VC/LLC: tc class add htb … overhead 42 atm I don't know what the outbound table would be for a USB ADSL modem - but it is probably one of the two above. Unfortunately the driver for USB ADSL modems varies between devices, and it will depend on whether the USB connection looks like an ATM connection or an Ethernet connection. BTW, if it isn't already obvious, avoid VC/LLC unless you have no choice. > What's the implication of a negative overhead value for PPPoA? Does that > reduce the overhead per MTU such that it positively compensates for the > standard 5 byte overhead per ATM cell for each packet? If the 5 byte overhead were per packet sent by the Linux box it wouldn't be a problem. Unfortunately, it is 5 bytes per 48 bytes (or part thereof) sent by the Linux box. There is no way to allow for it using the overhead parameter if the device is sending different size packets. This is one reason why the "atm" patch is needed. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
