From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leonardo Balliache Date: Sat, 12 Jul 2003 19:17:28 +0000 Subject: Re: [LARTC] hardware requirements Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Hi, Nickola: At 02:44 p.m. 11/07/03 +0300, you wrote: >The only problem I'm experiencing is with heavy udp traffic, f.e. Counter = >Strike >and Bnetd (Diablo, DiabloII, {Star|War}Craft) game play. Then the machine = >is reaching >some really high load averages, like 8 to 10. Have no idea how this >could be avoided. > >I'd appreciate any suggestions. UDP traffic is very difficult to control because the protocol is=20 unresponsive. Then the only way to put it under control is by killing its=20 packets. This doesn=B4t mean that it is going to lowering its rate, just th= at=20 you kill all packets that violate an upper level. You could do that at ingress using something like this: tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 1 u32 \ match ip protocol 17 0xff police rate 1200kbit \ burst 75kb drop flowid :1 Here UDP traffic is policed to 1200kbit. Then using tcindex you can filter them again when leaving to select an=20 output class for these "bad citizen" flows. UDP transports RTP that is always a problem. Application flows travelling=20 on it are very sensitive to latency and jitter. Some multimedia protocols, = like MPEG, are also very sensitive to packet dropping because when you=20 lose an I-decode frame you lose too a GOP (group of pictures); really a=20 problem. Using a policer you at least guarantee yourself they are not going to=20 starve other (TCP good citizen) flows and your servers. But packet masacre = generates then quality problem to the multimedia applications. Perhaps the = best solution is overprovisioning. Check how many flows of this type you=20 have on peak hours, check the bandwidth requirement of each of them, and=20 supercharge your servers to support the storm. RED, or GRED even better, can help too. This case the control is less=20 agressive and, perhaps, things go better. It=B4s just a matter to have time= =20 and patient to make some tests. You can search for more information on my site, below. Best regards, Leonardo Balliache Practical QoS http://opalsoft.net/qos _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/