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>