Thossapron Apinyapanha wrote:
tc class add dev eth2 parent 1: classid 1:1 hfsc sc m2 10000kbit
If it's really 10mbit eth, 10mbit rate is too high.
tc class add dev eth2 parent 1:11 classid 1:199 hfsc rt m1 3500kbit d 10s m2 500kbit ls m2 3500kbit ul m2 3500kbit
tc qdisc add dev eth2 handle 199: parent 1:199 sfq
sfq is really for bulk, with the added complication that it won't quite
be right on an hfsc rt class - if backlogged hfsc rt de/re queues to get
the next packet length, but sfq (as I read it) doesn't reset the "turn
pointer" when it requeues. Probably OK if you really need it I suppose -
but then rt classes should probably not get backlogged (excepting bursts
maybe)
Real time class guarantee rate: 3500kbit max rate: 10000kbit
VoIP guarantee rate: 200kbit max rate: 3500kbit
MMS guarantee rate: 1300kbit max rate: 3500kbit
Telnet guarantee rate: 1500kbit max rate: 3500kbit
Default guarantee rate: 500kbit max rate: 3500kbit
They are not going to be rt as such once over their guaranteed rates.
2. Is it true about HFSC can’t manage traffic load more than 1Mbit ??
The problem is I think, your use of default - If you don't use it hfsc
will drop unclassified traffic, htb will let it through unshaped, so it
is in someways needed more on hfsc (though you can filter non ip).
You could use it but not send any ip traffic to it, or you could
explicitly filter arp (& other non ip) to a dedicated rt class with
enough bandwidth. Delaying/dropping arp is not something you should do...
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
