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: [EMAIL PROTECTED] ________________________________________________________________ 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 [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
