[Top] [All Lists]

recent TCP changes adversive on slow links

To: netdev@xxxxxxxxxxx
Subject: recent TCP changes adversive on slow links
From: Aki M Laukkanen <amlaukka@xxxxxxxxxxxxxx>
Date: Wed, 31 May 2000 17:40:53 +0300 (EET DST)
Cc: iwtcp@xxxxxxxxxxxxxx, jmanner@xxxxxxxxxxxxxx
Sender: owner-netdev@xxxxxxxxxxx
Hi, it seems the changes to tcp_write_space() in 2.3.99-pre5 or
thereabouts had some adversive effects on slow links. The accompanying
tcpdump is from a 9600 bps connection with a rather large transmission
delay. Take a look with tracedump and the burstiness at the sender end
becomes apparent. The reason for this seems to be that the incoming acks
are so delayed that they can not provide feedback for TCP when to wakeup
the sender.

The following patch in will make the old behaviour come back. I assume
this change was made to prevent over-scheduling and thus the patch as it
is might not be acceptable. Maybe a variant which tests against 
(sk->sndbuf - WATERMARK) could be? 

Aside from the rather crude looking tcpdumps, the transmission speed with
ttcp (and tools alike) is not much worse withthe current behaviour. However 
real-world apps might not be able to shuffle new packets to the stack at
will so the burst will be gentler.

--- linux-2.4.0-test1-ac6.bak/net/ipv4/tcp.c    Mon Apr 24 23:59:57 2000
+++ linux-2.4.0-test1-ac6/net/ipv4/tcp.c        Wed May 31 17:22:41 2000
@@ -546,7 +546,7 @@
        struct socket *sock;
-       if ((sock = sk->socket) != NULL && atomic_read(&sk->wmem_alloc) == 0) {
+       if ((sock = sk->socket) != NULL) {
                if (test_bit(SOCK_NOSPACE, &sock->flags)) {
                        if (sk->sleep && waitqueue_active(sk->sleep)) {
                                clear_bit(SOCK_NOSPACE, &sock->flags);


Attachment: tcpdump.gz
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>