--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 02, 2005 at 05:25:09PM +0000, Matthias Scheler wrote:
> In article <20050602062721.GB1972@netbsd.org>,
> 	Bill Studenmund <wrstuden@NetBSD.org> writes:
> > Thoughts?
>=20
> PR/29971 perhaps? Your 3.99.1 kernel still has that problem.

I don't think so. I don't think my problem is that packets are getting=20
mis-handled, but that they aren't being sent.

So I tried enabling both IP and TCP checksumming over loopback, and it had=
=20
only a minor impact. It did seem to help SOME, but I still saw stalls that=
=20
gave me outrageously large times.

I think what's happening is that the sender is running but the receiver
isn't (because they are both being scheduled on the same uniprocessor
box), and that that's why the window starts shrinking. With checksumming
on, it takes a bit longer to send, so we're ever-so-slightly more likely
to let the receiver run.

But the multi-second wait is still there.

Take care,

Bill

--zYM0uCDKw75PZbzx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCn3Z+Wz+3JHUci9cRArTWAJ9/lvZbkWGeqswsxoIWzTiUPLkI+wCfVFFm
1AiIVvF2ST3N14eryAHqJ/s=
=YayB
-----END PGP SIGNATURE-----

--zYM0uCDKw75PZbzx--