From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Tue, 12 Apr 2005 17:29:01 +0000 Subject: Re: [LARTC] HTB ATM MPU OVERHEAD (without any patching) Message-Id: <425C055D.2000306@dsl.pipex.com> List-Id: References: <001001c53ef2$d4a1d2f0$200fa8c0@DELTA> In-Reply-To: <001001c53ef2$d4a1d2f0$200fa8c0@DELTA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Chris Bennett wrote: > I know there is that handy patch available to very efficiently use ATM > bandwidth, but I was wondering what the best values to use with a > non-patched iproute2 would be. Anyone here care to check my logic in > coming up with these numbers and perhaps suggest better values? > > My transmit speed is 768kbps per ADSL line (I have two). Is it your sync speed or what speed it's advertised by ISP - they may be different and if you patch/allow for overhead properly you can approach sync speed. Most modems tell you this. Also bps means bytes/sec to TC I assume you mean kbit and depending on TC version old TC k or K = 1024, newer TC k00 I think K still 1024. > # create leaf classes > # ACKs, ICMP, VOIP > tc class add dev eth0 parent 1:1 classid 1:20 htb \ > rate 50kbit \ OK as long as you can be sure voip+ack+icmp never > 50kbit you will queue if other classes are full otherwise. > Here's the logic I used to come up with these numbers:: > > The maximum real bandwidth, assuming no waste of data, is 768 * 48 / 53 > = 695. This accounts for the fact that ATM packets are 53 bytes, with > bytes being overhead. So that's the overall rate that I'm working with. Depending on sync speed mentioned above that may be OK for ATM data rate .. > > I then set the MPU to 96 (2 * 48) since the minimum ethernet packet (64 > bytes) uses two ATM packets (each having 48 bytes of data). I use 48 > instead of 53 here because we already accounted for the ATM overhead in > the previous calculation. > > For the overhead I use 24, since nearly each ethernet packet HTB uses IP packet length, to which you then need to add your fixed overhead - for pppoe that may include eth header + other have a look at jesper's table in his thesis. http://www.adsl-optimizer.dk/ On top of that you need to account for the fact that depending on original packet length upto 47 bytes padding gets added to make up a complete cell. To be safe you need overhead alot bigger than 24. > I run some game servers so I was able to do a real world test. With the > game servers maxed out, I started an FTP upload... the latency for the > players went up slightly, but not too much.. maybe just 30ms or so. So > from that perspective this seems to be working well. You could tweak up htb and rules to help this. In net/sched/sch_htb.c there is a define hysteresis it defaults to 1, which makes htb dequeue packets in pairs even if you specify quantum = MTU on leafs. Setting it to 0 fixes this - and specifying quantum = MTU on leafs and burst/cburst 10b on bulk classes let's me never delay an interactive packet longer than the transmit time of a bulk size packet. Andy. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc