Date: Thu, 19 Jan 1995 15:16:15 +1100 From: Bruce Evans <bde@zeta.org.au> To: davidg@Root.COM, olah@cs.utwente.nl Cc: hackers@FreeBSD.org, wollman@halloran-eldar.lcs.mit.edu Subject: Re: Netinet internals (Was: Patching a running kernel) Message-ID: <199501190416.PAA14811@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> Indeed, rfc1122 does say "SHOULD"...which makes this behavior not required. >The problem with acking this often is that on high speed, half-duplex networks >like ethernet, the collision rate caused by acks this frequently can consume a >large amount of the banwidth (measured 10-20%). > In the 4.4-lite TCP code, the acks every 2 packets was indirectly caused by >limiting the window to 4K. This had exceptionally bad side effects on long, >slow, high latency connections that are typical on the internet and usually >resulted in connection thrashing (my terminology) - i.e. the connection becomes >bursty and unable to stream. Perhaps the behaviour should depend more on the type of the interface. Do you remember me old bug report about it not being possible to saturate both directions of a SLIP interface? The two sides take turns in queueing acks behind so many sends that the acks don't get through before the other side stops sending. How is this supposed to work? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501190416.PAA14811>