Date: Mon, 9 Apr 2001 17:59:11 -0700 (PDT) From: Pete Carah <pete@ns.altadena.net> To: stable@freebsd.org Subject: Re: Answer found: TCP New Reno Algorithm Message-ID: <200104100059.f3A0xB873820@ns.altadena.net>
next in thread | raw e-mail | index | archive | help
I seem to have the same problem that someone else noted here, but here
is a big difference; it is an almost-unloaded 100-base-t switched network,
with both systems running -stable cvsup-d on Sunday afternoon/evening.
This appears to be a driver or stack problem, since New-reno on or off
on either end has no effect. The (cheap) switch is entirely
autoconfig'd (but used to work fine with these same two cards, switch, and
cables), and both interfaces (both fxp) show full-duplex 100baseT.
pelican# ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.167.2 netmask 0xffffff00 broadcast 192.168.167.255
inet6 fe80::202:b3ff:fe04:1ed1%fxp0 prefixlen 64 scopeid 0x1
ether 00:02:b3:04:1e:d1
media: 100baseTX <full-duplex> status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
-----------------
portable% ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::a00:46ff:fe06:2fdb%fxp0 prefixlen 64 scopeid 0x1
inet 192.168.167.22 netmask 0xffffff00 broadcast 192.168.167.255
ether 08:00:46:06:2f:db
media: autoselect (100baseTX <full-duplex>) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
Apparently this isn't a new-reno problem. It *is* new with the latest
-stable; things worked fine before.
pelican has one of the newer fxp boards identifying as a 559. The portable
is a Sony Z505HS; I don't know the intel chip rev.
This is a transfer using rsync of a directory of 65 or so 1-meg
jpgs, to an empty directory.
Performance from the default case:
.....
010409/dscn1418.jpg
010409/dscn1419.jpg
010409/dscn1420.jpg
010409/dscn1421.jpg
010409/dscn1422.jpg
010409/info.txt
./
010409/
wrote 65491864 bytes read 1076 bytes 8648.79 bytes/sec
total size is 229631336 speedup is 3.51
----------------------------------------------
(total size includes 4 other directories but "wrote" is the test move).
-------------------------------
TCPdump on receiving end shows:
(sender is dhcp22, receiver is pelican)
17:50:19.452868 dhcp22.home-lan.altadena.net.1219 > pelican.home-lan.altadena.net.ssh: . 14600:16060(1460) ack 1 win 17520 (DF) [tos 0x8]
17:50:19.452988 dhcp22.home-lan.altadena.net.1219 > pelican.home-lan.altadena.net.ssh: . 16060:17520(1460) ack 1 win 17520 (DF) [tos 0x8]
17:50:19.453023 pelican.home-lan.altadena.net.ssh > dhcp22.home-lan.altadena.net.1219: . ack 17520 win 11680 (DF) [tos 0x8]
17:50:19.453049 truncated-ip - 762 bytes missing!dhcp22.home-lan.altadena.net.1219 > pelican.home-lan.altadena.net.ssh: . 17520:18980(1460) ack 1 win 17520 (DF) [tos 0x8]
17:50:19.454499 pelican.home-lan.altadena.net.ssh > dhcp22.home-lan.altadena.net.1219: . ack 17520 win 17520 (DF) [tos 0x8]
17:50:19.454871 dhcp22.home-lan.altadena.net.1219 > pelican.home-lan.altadena.net.ssh: . 18980:20440(1460) ack 1 win 17520 (DF) [tos 0x8]
17:50:19.454946 pelican.home-lan.altadena.net.ssh > dhcp22.home-lan.altadena.net.1219: . ack 17520 win 17520 (DF) [tos 0x8]
17:50:19.454970 truncated-ip - 133 bytes missing!dhcp22.home-lan.altadena.net.1219 > pelican.home-lan.altadena.net.ssh: . 20440:21900(1460) ack 1 win 17520 (DF) [tos 0x8]
This truncated-ip is something I've not seen before
-- Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104100059.f3A0xB873820>