Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Apr 2003 16:07:43 +0200
From:      Borje Josefsson <bj@dc.luth.se>
To:        Mattias Pantzare <pantzer@ludd.luth.se>
Cc:        David Gilbert <dgilbert@velocet.ca>
Subject:   Re: tcp_output starving -- is due to mbuf get delay? 
Message-ID:  <200304111407.h3BE7hKl086838@dc.luth.se>
In-Reply-To: Your message of Fri, 11 Apr 2003 15:58:55 %2B0200. <3E96CA1F.4070000@ludd.luth.se> 

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Apr 2003 15:58:55 +0200 Mattias Pantzare wrote:

> Terry Lambert wrote:
> > Mattias Pantzare wrote:
> > =

> >>>The products that Jeffrey Hsu and I and Alfred and Jon Mini
> >>>worked on at a previous company had no problems at all on a
> >>>1Gbit/S saturating the link, even through a VLAN trunk through
> >>>Cisco and one other less intelligent switch (i.e. two switches
> >>>and a VLAN trunk).
> >>
> >>A key factor here is that the testst where on a link with a 20ms
> >>round-tip time, and using a singel TCP connection. So the switches
> >>where in addition to a few routers on a 10Gbit/s network.
> > =

> > =

> > Sorry, but tis is not a factor.  If you think it is, then you
> > are running with badly tuned send and receive maximum window
> > sizes.
> > =

> > Latency =3D pool retention time =3D queue size
> =

> Then explain this, FreeBSD to FreeBSD on that link uses all CPU on the =

> sender, the reciver is fine, but performance is not. NetBSD to FreeBSD =

> fills the link (1 Gbit/s). On the same computers. MTU 4470. Send and =

> receive maximum windows where tuned to the same values on NetBSD and =

> FreeBSD.

I should add that I have tried with MTU 1500 also. Using NetBSD as sender=
 =

works fine (just a little bit higher CPU load). When we tried MTU1500 wit=
h =

FreeBSD as sender, we got even lower performance.

Somebody else in this thread said that he had got full GE speed between =

two FreeBSD boxes connected back-to-back. I don't question that, but that=
 =

doesn't prove anything. The problem arises when You are trying to do this=
 =

long-distance and have to handle a large mbuf queue.

--B=F6rje



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