Subject: Re: TCP flow control - who can explain?
To: None <tech-net@netbsd.org>
From: Wolfgang Rupprecht <wolfgang@wsrcc.com>
List: tech-net
Date: 08/29/1999 13:12:37
drochner@zel459.zel.kfa-juelich.de (Matthias Drochner) writes:
> I've appended tcpdump logs for both directions. The NetBSD box (134.94.206.140)
> seems to wait for the (delayed) acks when it sends, while the Alpha
> (134.94.206.130) somehow manages to pump into the wire.
> 21:02:33.004760 134.94.206.140.5001 > 134.94.206.130.1046: . ack 16385 win 0
> 21:02:33.006183 134.94.206.140.5001 > 134.94.206.130.1046: . ack 16385 win 9728
> 21:02:33.006672 134.94.206.130.1046 > 134.94.206.140.5001: . 16385:25345(8960) ack 1 win 35840 (DF)
One problem is that your netbsd box's window is closing. You really
should make the window at least 64k (or more if window scaling is
available).
A quick check would be to bump up the window via:
sysctl -w \
"net.inet.tcp.recvspace=65536" \
"net.inet.tcp.sendspace=65536"
and then rerun the tests.
The above settings tend to waste quite a bit of memory, since every
program will get increased limits. A more conservative approach would
be to just to a SO_SNDBUG SO_RCVBUF ioctl on the sockets that
need to move things quickly.
-wolfgang
--
Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
http://www.wsrcc.com/wolfgang/
DGPS signals via the Internet http://www.wsrcc.com/wolfgang/gps/dgps-ip.html