> 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".)
Since *something* is making a difference, you may wish to try changing one independent parameter at a time. For instance, do you get different throughput numbers with -l = 16k, 32k, and so on? What is the limit? You will want to decrease the -n parameter correspondingly so as to not keep waiting longer and longer! Similarly try changing other limits one at a time. If you can, try to use the *same* non-FreeBSD machine at one end and characterize send and recv performance of FreeBSD separately. This ought to help you figure out where the bottleneck may be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
