Hi Simo, I’ve just started to take
a look into tcng. Looks promising, but I’m not sure that I have the
time to spend fully investigating the tool. Plus I haven’t had much luck
getting tcsim to compile as I am running a 2.6.9 kernel and tcsim is currently
targeted at a 2.5.4 kernel. What would be very helpful is something complete
that I can fiddle with and customize to my needs. I don’t believe I
mentioned this already but it is for a client that has only recently been
having issues since they have begun using RDP clients. They are looking at
VOIP at a later stage but I would like to have something at least in place to
prioritize packets. Kind regards, Rangi PS. I am still rather new to tc
in linux. From: Simo
[mailto:simo@xxxxxxxxxx] Hi Rangi, if i have understoud, what do you mean. I´ll say, you need to use
the PRIO queuing descipline. With this qdisc you can define an amount of Bands
(priority FIFOs) to serve the network packets and you don´t need to devide the
bandwidth. Here a link to an illustration: http://www.linux-ip.net/articles/Traffic-Control-HOWTO/images/pfifo_fast-qdisc.png
The Problem by this qdisc is, if too many high priority Packets in
the qdisc were enqued, the rest of the traffic in the other low priority bands
or FIFOs will be ignored und will have a high latency…That´s why you can
use the prio qdisc combined with tbf qdisc. I think
that will solve your problem… How do you use the linux traffic control system? Do you use the
tcng tool? If so, i can send you a script for your problem, and we can simulate
this with the tcsim component of tcng tool befor use… Sorry for my english, i´m from morocco and i´m studying in germany
;)… Kind regards Simo Von:
lartc-bounces@xxxxxxxxxxxxxxx [mailto:lartc-bounces@xxxxxxxxxxxxxxx] Im
Auftrag von Rangi Biddle HI Simo, Thanks for the info. Very
interesting read. I forgot to mention in the post that I am still
relatively new to traffic shaping with Linux but was still able to more than
comprehend the info in that document. Many thanks again. One thing that I am slightly
uncertain of though is that I would prefer not to divide the bandwidth between
x amount of people but rather designate a priority that packets take over each
other which that info doesn’t cover. Is it still possible using
HFSC to accomplish this? Kind regards, Rangi From: Simo
[mailto:simo@xxxxxxxxxx] Hi Rangi, Bandwidth ist important, but
VoIP needs more than this. Voice traffic needs low latency of packets.
That’s why traffic shaping maybe not lose your problem.
in this a HFCS queuing
descipline is used instead of HTB, because this can separate between bandwidth
and delay. For more Information about this can you find here: http://linux-ip.net/articles/hfsc.en/ bye Simo Von: lartc-bounces@xxxxxxxxxxxxxxx
[mailto:lartc-bounces@xxxxxxxxxxxxxxx] Im Auftrag von Rangi Biddle Dear List, I am wanting to perform some traffic shaping as the subject
of this email suggests. What I am wanting to do is this; I would like to have
traffic shaping performed on the following protocols: HTTP, RDP, GRE,
PPTP, SIP and IAX. Obviously I would like to have highest priority set
for voice packets so much so that the general http traffic does not impede on
the voice packets. I would like to have ample bandwidth available for RDP
so that I am able to connect to a remote site and not have too much lag but
ample enough that most tasks can be done. HTTP traffic would possibly
have the lowest priority of all the protocols that I have listed. So to
clarify priority would be something such as this: 1. IAX 2. SIP 3. GRE 4. PPTP 5. RDP 6. HTTP I have a linux gateway that I will use for performing the
traffic shaping and is setup in the following way:
-------------
------------
---------
| ADSL | <---------->
| LINUX | <----------> |
LAN |
-------------
------------
--------- I plan to have the ADSL router forward all traffic to the
linux gateway using something similar to a BIMAP rule where all incoming and
outgoing traffic is made to appear to come from the public IP address. I
welcome any and all suggestions but would possibly prefer the most elegant of
solutions J Many thanks in advance Rangi |
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc