[LARTC] Re: Modems: Cable or DSL digital blunders that lartc may help with.

2004-06-24 Thread Greg Stark
Ed Wildgoose <[EMAIL PROTECTED]> writes: > You need something which works at IP level or above. TCP (level higher) has > some stuff, but (I repeat) it basically involves dropping traffic until the > sender slows down. There are protocols like ECN, but they are broadly > unsupported. ICMP stuff

[LARTC] Re: Shaping incoming traffic on the other interface

2004-06-10 Thread Greg Stark
Andreas Klauer <[EMAIL PROTECTED]> writes: > I think there was a patch on the BT mailing list a few weeks ago > that solves this random port problem (on your side). Other clients > of course can choose whatever ports they like. Why does bittorrent need to use more than one port in the first plac

[LARTC] Re: Shaping incoming traffic on the other interface

2004-06-10 Thread Greg Stark
Matteo Brusa <[EMAIL PROTECTED]> writes: > tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 > tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 I'm using sfq as well. But I'm wondering if I wouldn't be better off with pfifo with a short queue. One of the entries in the HTB f

[LARTC] Re: Shaping incoming traffic on the other interface

2004-06-10 Thread Greg Stark
Matteo Brusa <[EMAIL PROTECTED]> writes: > Hi, > I have a typical configuration for my firewall/gateway box: single network > card, with a pppoe connection to the DSL modem. > I'm already successfully shaping the uplink (how come that the > wondershaper.htb doesn't use the ceil parameter? It shou

[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

2004-06-09 Thread Greg Stark
Sanjay Arora <[EMAIL PROTECTED]> writes: > Sorry to interrupt the flow, especially being a newbie, but won´t the > sender just retransmit the dropped packets at the same rate? no. > I am not so thorogh with TCP/IP, but is there something in the protocol that > speeds or slows the transmission.

[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

2004-06-09 Thread Greg Stark
Jason Boxman <[EMAIL PROTECTED]> writes: > On Tuesday 08 June 2004 23:33, Greg Stark wrote: > > > > Well ultimately all shaping works by dropping packets. Merely delaying > > transmission isn't going to slow down anything in the long run, just > > increase t

[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Greg Stark
Damion de Soto <[EMAIL PROTECTED]> writes: > Greg, > > For some reason that hadn't occurred to me. That should work just fine. I > > guess I should mark the packets in iptables to avoid throttling traffic from > > gateway itself, or does match see the external ip? > > The only (common) time you ne

[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Greg Stark
Damion de Soto <[EMAIL PROTECTED]> writes: > You can create different ingress policers that only match specific ports, and > give them different priorities, but that still won't work as well as using IMQ, > or if your box is a gateway (and you are only shaping traffic going through it), > then yo

[LARTC] how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Greg Stark
[I sent this earlier but I guess the list is subscriber-only?] I just set up wondershaper, it has a simple filter on the downstream direction to limit the bandwidth usage: tc qdisc add dev $DEV handle : ingress tc filter add dev $DEV parent : protocol ip prio 50 u32 match ip src \ 0.0