Anders Fugmann writes:
> The best solution would be to install some sort of traffic shaping on
> the remove side (you ISP), but that is often(/always) not a possible
> solution.
>
> The second best solution is to simple drop packets comming in too
> quickly from the interface. By this, the sending machine will slow down
> transmission. The idea is to keep the queues at you ISP empty.
>
> To do this you can use ingress scheduler.
>
> Something like:
> tc qdisc add dev eth0 handle ffff: ingress
> tc filter add dev etc0 parent ffff: protocol ip prio 50 u32 \
> match ip src 0.0.0.0/0 police \
> rate 232kbit burst 10k drop flowid :1
Rather than dropping packets, causing retransmits that
eat into your bandwidth, you could try the new ECN bits.
If you're downloading from a Linux box, it ought to slow
down a bit when you claim to be suffering congestion.
ftp://ftp.isi.edu/in-notes/rfc3168.txt
http://www.faqs.org/rfcs/rfc3168.html
http://www.aciri.org/floyd/ecn.html
http://gtf.org/garzik/ecn/
http://www.tux.org/lkml/#s14-2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:30 EST