Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Apr 2003 09:32:51 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        bj@dc.luth.se
Cc:        David Gilbert <dgilbert@velocet.ca>
Subject:   Re: tcp_output starving -- is due to mbuf get delay?
Message-ID:  <3E96EE33.FAF4FABB@mindspring.com>
References:  <200304111624.h3BGO9Kl087165@dc.luth.se>

next in thread | previous in thread | raw e-mail | index | archive | help
Borje Josefsson wrote:
> > A good thing to look at at this point would be:
> >
> >       o       Clean boot of FreeBSD target
> >       o       Run NetBSD against it
> >       o       Save statistics
> 
> What type of statistics do You mean?

Dropped packets; frags; delayed acks.  The stuff you get from
"netstat -s" and "netstat -m".

> > You mean "bandwidth delay product".  Yes, assuming you have packet
> > loss.  From your description of your setup, packet loss should not
> > be possible, so we can discount it as a factor.
> 
> Of cause packet loss is possible on a nationwide network. If I loose a
> packet on the (expected) 10 second test (with NetBSD), recovering from
> that drops performance from 900+ to ~550 Mbps. Thos shows very clearly if
> I run "netstat 1".

You are running these tests over .se's nationwide network?

> > You may want to
> > disable fast restart on the FreeBSD sender.
> 
> Which OID is that?

See other posting; I listed a bunch of OIDs to play with.

One other, if you are running -CURRENT, would be:

	net.isr.netisr_enable		-> 1

This basically implements part 1 of 3 of LRP, which should
reduce your per packet latency by about 50ms +/- 50ms.

Note:	The logic here is inverted; you'd expect "0=No NETISR",
but it's just the opposite.


> As a side note, I tried to set tcp.inflight_enable, but that made things
> much worse.

It's less useful on GigE than elsewhere (IMO).  Use netisr_enable
instead.

-- Terry



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