From owner-freebsd-questions  Sat Jul  1 23:26:22 1995
Return-Path: questions-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id XAA18381
          for questions-outgoing; Sat, 1 Jul 1995 23:26:22 -0700
Received: from silver.sms.fi (silver.sms.fi [194.111.122.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA18375
          for <freebsd-questions@freefall.cdrom.com>; Sat, 1 Jul 1995 23:26:20 -0700
Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id JAA19099; Sun, 2 Jul 1995 09:26:13 +0300
Date: Sun, 2 Jul 1995 09:26:13 +0300
Message-Id: <199507020626.JAA19099@silver.sms.fi>
From: Petri Helenius <pete@sms.fi>
To: jleppek@suw2k.ess.harris.com (James Leppek)
Cc: freebsd-questions@freefall.cdrom.com
Subject: Re: tcpblast
In-Reply-To: <9507020111.AA00633@borg.ess.harris.com>
References: <9507020111.AA00633@borg.ess.harris.com>
Sender: questions-owner@FreeBSD.org
Precedence: bulk

James Leppek writes:
 > Pete,
 > 
 > You may have something there.
 > if I leave the mtu at 16384 I get a thruput of 2.1 Mbytes/s
 > but it drops to .1 after a few test. If I change the mtu
 > to 1500 a get a thruput of 1.3Mbytes/s but no stalls.
 >
Sounds more like it. The mecanics of tcp vary from implementation to another
but take a look at ftp://ftp.scs.leeds.ac.uk/atm/doc/tcp-deadlock.ps
for a review what might be happening. The document is not the whole truth,
I've seen the deadlock to appear even more easily. 

 > Would it be better to change the default mtu for lo0 to a smaller
 > value as a default??  If I use an mtu of 6000 the thruput is at 2Mbytes/s
 > with no stalls.
 >
Safe value half of the default window. I think window is 16384 in FreeBSD so
something around 8000 should work best. Some applications do lower or raise
the window to get special loading/throughput requirements filled. Raising
the default window is very bad idea. (not that I'm suggesting that you were
doing it)

 > Hmmm is this thread starting to belong in hackers :-)
 >
I that case, keep me in, unfortunately the general volume of it too much for
me to just watch the networking-related issues...

 > Jim
 > 

Pete