On Mon, Oct 05, 2009 at 03:20:58PM +0500, rihad wrote: > >>>Taildrop does not really help with this. GRED does much better. > >>i think the first problem here is figure out _why_ we have > >>the drops, as the original poster said that queues are configured > >>with a very large amount of buffer (and i think there is a > >>misconfiguration somewhere because the mbuf stats do not make > >>sense) > > > >That may be very simple, f.e. wide uplink channel and policy that > >dictates slower client speeds. Any taildrop queue would drop lots > >of packets. > > > If uplink is e.g. 100 mbit/s, but data is fed to client by dummynet at 1 > mbit/s, doesn't the _client's_ TCP software know to slow things down to > not overwhelm 1 mbit/s?
That's not client's TCP software feeding your router with traffic but server side. > Where has TCP slow-start gone? My router box > isn't some application proxy that starts downloading at full 100 mbit/s > thus quickly filling client's 1 mbit/s link. It's just a router. While there is no or little competition for bandwidth from the router to clients, TCP would work just fine. I suspect your shaping policy makes heavy competition between clients. In this case, TCP behaves not-so-well without help of router's good shaping algorythms and taildrop is not good one. > Although it doesn't yet make sense to me, I'll try going to GRED soon. "Works for me" :-) Eugene Grosbein _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
