Hi, I want to make a dedicated bridging traffic control machine using ebtables and HTB. The requirements will be to shape a 10 Mbit link to 1000 users. Is anyone have experience regarding the needed (estimated) hardware for this (processor/memory/type of network cards) ? Thanks, Alex _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Fri, 11 Jul 2003 13:08:03 +0300
alexandru matei <alex@qb.ro> wrote:
: Hi,
: I want to make a dedicated bridging traffic control machine using
: ebtables and HTB. The requirements will be to shape a 10 Mbit link to
: 1000 users. Is anyone have experience regarding the needed (estimated)
: hardware for this (processor/memory/type of network cards) ?
Hey, Alex,
For a similar setup (except that users are doubled and I''m not using
bridge),
I have a PIII/1GHz with two Interl EEpro100 cards. Works fine, at least for now.
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.
--
________________________________________________________________________
So long, and thanks for all the fish!
Nickola
> 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.How many filters?> Nickola--- Catalin(ux) BOIE catab@deuroconsult.ro _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Fri, 11 Jul 2003 14:56:42 +0300 (EEST)
Catalin BOIE <util@deuroconsult.ro> 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.
:
: How many filters?
:
Almost the same as the count of classes, i.e. aroung 2000. But not all of them
are playing
Couter Strike, probably not more than 20-30.
--
________________________________________________________________________
So long, and thanks for all the fish!
Nickola
> Almost the same as the count of classes, i.e. aroung 2000. But not all of them are playing > Couter Strike, probably not more than 20-30.Try to use hashes for filters.> > -- > ________________________________________________________________________ > > So long, and thanks for all the fish! > > Nickola >--- Catalin(ux) BOIE catab@deuroconsult.ro _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.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 unresponsive. Then the only way to put it under control is by killing its packets. This doesn´t mean that it is going to lowering its rate, just that 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 output class for these "bad citizen" flows. UDP transports RTP that is always a problem. Application flows travelling on it are very sensitive to latency and jitter. Some multimedia protocols, like MPEG, are also very sensitive to packet dropping because when you lose an I-decode frame you lose too a GOP (group of pictures); really a problem. Using a policer you at least guarantee yourself they are not going to 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 have on peak hours, check the bandwidth requirement of each of them, and supercharge your servers to support the storm. RED, or GRED even better, can help too. This case the control is less agressive and, perhaps, things go better. It´s just a matter to have time 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/