Re: R: Kernel bug handling TCP_RTO_MAX?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






      I believe the very large BSD number was based on the large
granularity of the timer (500ms for slowtimeout), designed for use on a VAX
780. The PC on my desk is 3500 times faster than a VAX 780, and you can
send a lot of data on Gigabit Ethernet instead of sitting on your hands for
an enormous min timeout on modern hardware. Switched gigabit isn't exactly
the same kind of environment as shared 10 Mbps (or 2 Mbps) when that stuff
went in, but the min timeouts are the same.
      I think the exponential back-off should handle most issues for
underestimated timers, and the min RTO should be the timer granularity.
Variability in that is already accounted for by the RTT estimator.
      I certainly agree it needs careful investigating, but it's been a pet
peeve of mine for years on BSD systems that it forced an arbitrary minimum
that had no accounting for hardware differences over the last 20 years.

                                    +-DLS


"David S. Miller" <davem@redhat.com>@vger.kernel.org on 12/12/2002 09:23:35
PM

Sent by:    linux-net-owner@vger.kernel.org


To:    matti.aarnio@zmailer.org
cc:    niv@us.ltcfwd.linux.ibm.com, alan@lxorguk.ukuu.org.uk,
       stefano.andreani.ap@h3g.it, linux-kernel@vger.kernel.org,
       linux-net@vger.kernel.org
Subject:    Re: R: Kernel bug handling TCP_RTO_MAX?



   From: Matti Aarnio <matti.aarnio@zmailer.org>
   Date: Fri, 13 Dec 2002 05:39:28 +0200

   On Thu, Dec 12, 2002 at 06:26:45PM -0800, Nivedita Singhvi wrote:
   > Assuming you are on a local lan, your round trip
   > times are going to be much less than 200 ms, and
   > so using the TCP_RTO_MIN of 200ms ("The algorithm
   > ensures that the rto cant go below that").

     The RTO steps in only when there is a need to RETRANSMIT.
     For that reason, it makes no sense to place its start
     any shorter.

Actually, TCP_RTO_MIN cannot be made any smaller without
some serious thought.

The reason it is 200ms is due to the granularity of the BSD
TCP socket timers.

In short, the repercussions are not exactly well known, so it's
a research problem to fiddle here.
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux