Date: Sun, 30 Dec 2001 18:26:12 +0000 From: Josef Karthauser <joe@tao.org.uk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Alexander Haderer <alexander.haderer@charite.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? Message-ID: <20011230182612.D5642@tao.org.uk> In-Reply-To: <200112300644.fBU6iVG10959@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Dec 29, 2001 at 10:44:31PM -0800 References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <20011130231802.E99520@tao.org.uk> <200111302345.fAUNjLI27798@apollo.backplane.com> <20011228153330.A11251@tao.org.uk> <200112300644.fBU6iVG10959@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 29, 2001 at 10:44:31PM -0800, Matthew Dillon wrote: >=20 > Ok, there's packet loss. From this extract you can see > that the client receives through sequence 641, then the > next packet it receives starts at sequence 993. >=20 > 15:28:09.879928 transwarp.tao.org.uk.telnet > genius.tao.org.uk.kpop: P 6= 09:641(32) ack 64 win 33304 <nop,nop,timestamp 152269835 86 > 8399> (DF) [tos 0x10] > 15:28:09.881926 transwarp.tao.org.uk.telnet > genius.tao.org.uk.kpop: P 9= 93:1025(32) ack 64 win 33304 <nop,nop,timestamp 152269835 8 > 68402> (DF) [tos 0x10] >=20 > If you look at the server you can see the (tiny) packets > being transmitted: >=20 > 15:28:18.255648 transwarp.telnet > genius.kpop: P 609:641(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868399> (DF) [tos 0x10] > 15:28:18.255775 transwarp.telnet > genius.kpop: P 641:673(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868399> (DF) [tos 0x10] > 15:28:18.255864 genius.kpop > transwarp.telnet: . ack 97 win 33288 <nop,n= op,timestamp 868402 152269835> (DF) [tos 0x10] > 15:28:18.255955 transwarp.telnet > genius.kpop: P 673:705(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.256084 transwarp.telnet > genius.kpop: P 705:737(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.256223 transwarp.telnet > genius.kpop: P 737:769(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.256351 transwarp.telnet > genius.kpop: P 769:801(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.256479 transwarp.telnet > genius.kpop: P 801:833(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.256607 transwarp.telnet > genius.kpop: P 833:865(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.256734 transwarp.telnet > genius.kpop: P 865:897(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.256884 transwarp.telnet > genius.kpop: P 897:929(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.257011 transwarp.telnet > genius.kpop: P 929:961(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.257138 transwarp.telnet > genius.kpop: P 961:993(32) ack 64 win = 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.258068 transwarp.telnet > genius.kpop: P 993:1025(32) ack 64 win= 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10] > 15:28:18.258221 transwarp.telnet > genius.kpop: P 1025:1057(32) ack 64 wi= n 33304 <nop,nop,timestamp 152269835 868402> (DF) [tos 0x10 >=20 > The first one is through 641. The server then sends 11 packets > (641 through 993) that the client misses completely. The > next packet the client sees is the 993:1025 packet. >=20 > So there is nothing wrong with the TCP protocol. The question > now is whether this is packet loss due to the physical layer > or whether it is a queueing problem. What kind of network > cards do these machines have and what kind of switching > infrastructure is between them? No switching infrastructure. It's a 10mb/s half duplex ethernet network, with two hubs between the two machines. > One thing that doesn't make sense is that the client > is responding to each packet with its own ack but > the server doesn't see the acks until it finishes > transmitting a big stream of data packets. This > implies half-duplex operation. Yes, it is half-duplex. Joe --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwvXEMACgkQXVIcjOaxUBZHjwCghfZji9aP3orlwZkowo9E8Fpm 0ucAoIfeHe2SnD1MAko6lPAaM/mXbXX6 =uNPR -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011230182612.D5642>