Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Apr 2003 11:44:42 -0500 (CDT)
From:      Mike Silbersack <silby@silby.com>
To:        Borje Josefsson <bj@dc.luth.se>
Cc:        David Gilbert <dgilbert@velocet.ca>
Subject:   Re: tcp_output starving -- is due to mbuf get delay? 
Message-ID:  <20030410114227.A472@odysseus.silby.com>
In-Reply-To: <200304101311.h3ADBgjY022790@samson.dc.luth.se>
References:  <200304101311.h3ADBgjY022790@samson.dc.luth.se>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 10 Apr 2003, Borje Josefsson wrote:

> What we did in NetBSD (-current) was to increase IFQ_MAXLEN in (their)
> sys/net/if.h, apart from that it's only "traditional" TCP tuning.
>
> My hosts are connected directly to core routers in a 10Gbps nationwide
> network, so if anybody is interested in some testing I am more than
> willing to participate. If anybody produces a patch, I have a third syste=
m
> that I can use for piloting of that too.
>
> --B=F6rje

This brings up something I've been wondering about, which you might want
to investigate:

From=20tcp_output:

=09=09if (error =3D=3D ENOBUFS) {
=09                if (!callout_active(tp->tt_rexmt) &&
                            !callout_active(tp->tt_persist))
=09                        callout_reset(tp->tt_rexmt, tp->t_rxtcur,
                                      tcp_timer_rexmt, tp);
=09=09=09tcp_quench(tp->t_inpcb, 0);
=09=09=09return (0);
=09=09}

That tcp_quench knocks the window size back to one packet, if I'm not
mistaken.  You might want to put a counter there and see if that's
happening frequently to you; if so, it might explain some loss of
performance.

Have you tried running kernel profiling yet?  It would be interesting to
see which functions are using up the largest amount of time.

Mike "Silby" Silbersack



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030410114227.A472>