Thanks for the tips Brian,
    Actually, I have many sorts of links, line PPOE ADSL, PPPOA ADSL 
which a use PPTP over PPOA relay, radio links that connect in the  
ethernet interface and cable modems.
    To change the SFQ queue size I must recompile de kernel? I think a 
saw some messages talking about that.
    One other thing, I have the 1:10 a   1:20 class, let''s assume there
is no voip traffic and all bandwidth is being consumed and it is in the 
other class. When the voip traffic starts, there is  a inicial delay 
untill the 1:20 class starts to free bandwidth to the 1:10 class, as 
I''ve noticed. Should I change the burst and cburst parameters to get a 
better response or just make de queues smaller?
      Thanks.
Brian Carrig wrote:
On 16 Jul 2004 at 13:35, Alessandro Ren wrote:
> Hello Brian,
>
> This is the basis for the wshaper.
> I have only two classes and I put voip on the 1:10 class and the rest in
the 1:20. I
>  
>
am not 
>listing here, but I have the rule marking packets and sorting then into
classes,
>  
>
actually, I just put 
>one port into the 1:10 class, that''s the voip port and nothing
else. I really want to
>  
>
keep the best 
>quality I can for voip, without bandwidth waste., because, if a page takes 1
>  
>
seconds longer do 
>load is ok, but if a voip packet starts to get delay, we got a problem,
> I think, I must have no queue for voip packets, all packtes should be
forwarded as
>  
>
soon as 
>they get to the box, right?
>  
>
You do actually have a queue for VoIP, as you implement SFQ for both the 1:10
and
1:20 classes. To the best of my knowledge the default setting for this queue is
128
packets. This may be too large for VoIP if latency is a concern so I would
suggest
making this queue much smaller (limit option). Unfortunately without knowing the
particulars of your link I am unable to suggest a figure but have play around
and see
what suits.
Regards
Brian
  
>#
>tc qdisc add dev $DEV root handle 1: htb default 20
>
># shape everything at $UPLINK speed - this prevents huge queues in your
># DSL modem which destroy latency:
>
>tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
>
># high prio class 1:10:
>
>tc class add dev $DEV parent 1:1 classid 1:10 htb rate $[4*$UPLINK/10]kbit \
> burst 6k prio 1
>
># bulk & default class 1:20 - gets slightly less traffic,
># and a lower priority:
>
>tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[6*$UPLINK/10]kbit \
> ceil $[10*$UPLINK/10]kbit burst 6k prio 2
>
># all get Stochastic Fairness:
>tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
>tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
>
>
>Brian Carrig wrote:
>    We run something similar allowing customers to place traffic into gold,
silver or
>    bronze classes. I reserve a fixed amount of bandwidth for each class and
allow
>  
>
them 
>    to borrow (I hate the idea of bandwidth going to waste). However, excess
>  
>
bandwidth 
>    is offered preferrentially to gold, then silver before being offered to
bronze.
>    Because p2p and other bw consuming traffic are unlikely to be in the
gold and
>  
>
silver 
>    classes (they cost more) there haven''t been any problems.
>    I haven''t really looked at the wondershaper script in much
detail, how is voip
>  
>
traffic 
>    prioritised?
>    
>    Regards
>    Brian
>    
>    On 16 Jul 2004 at 12:19, Alessandro Ren wrote:
>    
>      
>    
>     I''ve been using a altered version of the wshaper script to
priorize voip traffic for
>        
>    my 
>      
>    customers.
>     I''d like to know if someone in the list has any tips on QoS
for voip, if someone
>        
>    has done some 
>      
>    experimentation.
>     I am using HTB and if someone on the LAN uses a p2p program, I started
to
>        
>    noticed in the 
>      
>    voip, with cuts, jitter and lag. If a reserve a fixed amount of
bandwitdh not letting
>        
>    anyonbe 
>      
>    borrow, it works fine, but then if noone is using voip, I have bandwidth
going to
>        
>    waste.
>      
>     I think I need some fine tunning oin the HTB parameters, but I am not
sure sure
>        
>    about that.
>