Date: Fri, 11 May 2007 19:39:10 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: suvashrestha@wlink.com.np Cc: freebsd-net@freebsd.org Subject: Re: bridge query Message-ID: <20070511093910.GG826@turion.vk2pj.dyndns.org> In-Reply-To: <SCEtVlql.1178860963.0544890.suvashrestha@wlink.com.np> References: <mailman.6487.1178613103.783.freebsd-net@freebsd.org> <SCEtVlql.1178860963.0544890.suvashrestha@wlink.com.np>
next in thread | previous in thread | raw e-mail | index | archive | help
--+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-May-11 10:22:43 +0500, suvashrestha@wlink.com.np wrote: >I am using TCP sockets to measure packet transfer. And I am also not >looking to optimise the link. I just want to know if this is the usual >behaviour of the freeBSD TCP or bridge when we apply delay and packet >loss. This is nothing to do with FreeBSD and is expected behaviour for TCP. The TCP sender has to buffer data until the receiver acknowledges it. The default buffer is 64KB. With a 250msec delay in each direction, this gives you a theoretical maximum thruput of 128KBps. >The throughtput falls from around 8 Mbps (8000 Kbps) to just 80 Kbps. >This is very significant. Increasing PLR above 0 will reduce the theoretical throughput: A lost ACK will block the sender until the next ACK is received. A lost data packet means the receiver won't ACK it. SACK makes things slightly better because only the lost packet will be re-transmitted but the very long RTT will still have a major impact on throughput. --=20 Peter Jeremy --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGRDm+/opHv/APuIcRAlAHAKCPG+LksfR2KDcTz2sANd+lu6wHXgCfQc9L copgOlHUOOTFE0bKTq/ucT4= =lUa5 -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511093910.GG826>