From: Svein Ove Aas <svein.ove@aas.no>
To: Mika Liljeberg <mika.liljeberg@welho.com>
Subject: Re: TCP send behaviour leads to cable modem woes
Date: Sat, 28 Jun 2003 16:04:51 +0200
User-Agent: KMail/1.5.2
Cc: linux-kernel@vger.kernel.org
References: <200306272020.57502.svein.ove@aas.no> <200306272145.22008.svein.ove@aas.no> <1056743877.681.5.camel@hades>
In-Reply-To: <1056743877.681.5.camel@hades>
MIME-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <200306281604.52876.svein.ove@aas.no>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1323
Lines: 35

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fredag 27. juni 2003, 21:57, skrev Mika Liljeberg:
> On Fri, 2003-06-27 at 22:45, Svein Ove Aas wrote:
> > Incidentally, while googling I heard someone saying that only works if
> > it's enabled on both ends? Of course, that might be if upload/download
> > are 'both' affected, in which case it wouldn't apply to me.
>
> It's a sender side only algorithm, so enabling it at your end should be
> enough to help the uploads. For downloads it needs to be on at the other
> end, of course.

Well, it doesn't appear to have any effect.
(What is it *supposed* to do? Something about spurious retransmission 
timeouts, was it?)

I'm going to research this a bit more on my own, if none of you have any 
further ideas. If I find a solution it should probably be in a HOWTO 
somewhere, so I'll get back to you if/when that happens.

- - Svein Ove Aas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+/aCD9OlFkai3rMARAtzFAKCyfXKjWF9yA6wuQZiJvo11RsIs9gCcCBW/
Si1UTkOPaDEtXz5Pq+U64NM=
=kjUX
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/