Date: Fri, 1 Nov 2002 11:20:01 -0500 From: Fran Lawas-Grodek <Fran.Lawas-Grodek@grc.nasa.gov> To: Bakul Shah <bakul@bitblocks.com> Cc: Cindy.Tran@grc.nasa.gov, freebsd-net@FreeBSD.ORG, Mark.Allman@grc.nasa.gov Subject: Re: Problem in High Speed and Long Delay with FreeBSD Message-ID: <20021101112001.E3259@grc.nasa.gov> In-Reply-To: <200211010301.WAA03036@thunderer.cnchost.com>; from bakul@bitblocks.com on Thu, Oct 31, 2002 at 07:01:30PM -0800 References: <20021031135601.B23802@grc.nasa.gov> <200211010301.WAA03036@thunderer.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Bakul, Your suggestion of increasing the -l seems to have made a positive impact -- tests this morning with a higher buffer length size of 8192 gave us a better throughput of 44Mbps. Now the time sequence plot shows a window usage of 1.5MB as opposed to the previous 1MB usage. We still don't understand as to why we are not getting a larger window usage when we are requesting a 3MB socket buffer. (BTW, a typo in my example testing commands, left out a "0" in the "-b".) Any other thoughts would be greatly appreciated. Fran Lawas-Grodek Cindy Tran NASA Glenn Research Center ________________________________________________________________ Frances J. Lawas-Grodek | NASA Glenn Research Center | phone: (216) 433-5052 21000 Brookpark Rd, MS 142-4 | fax : (216) 433-8000 Cleveland, Ohio 44135 | email: fran@grc.nasa.gov ________________________________________________________________ On Thu, Oct 31, 2002 at 07:01:30PM -0800, Bakul Shah wrote: > > Testing commands used: > > receiver> ttcp -b 312500 -l 1024 -r -s > > sender> ttcp -b 312500 -l 1024 -n 100000 -s -t receiverhost > > Pure speculation: > > Since you are writing 1K at a time, could it be an N^2 effect > while appending mbufs? Since you can have many MBs in the > pipe due to large delay*BW, you can potentially have many > many mbufs. The Nth write will have to traverse O(N) mbuf > chains to append the new data. One way to test is to > increase the -l parameter value to something large and see if > the throughput improves. If this is the case, FreeBSD will > have to optimize this common case for stream protocols. > > Note that I haven't even looked at the relevant FreeBSD code! > For all I know it may already be doing this. > > -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021101112001.E3259>