lkml.org 
[lkml]   [1998]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Very poor TCP/SACK performance
    Date
    > > No. With a 32K window and set for a 64K limit 2.1.x should be fine by
    > > default. Looking at the 2.1.x code Im a bit confused it seems to be offering
    > > window == free space or am I missing something ?
    >
    > Offering window can't shrink.
    > So when the socket buffer memory usage pattern has been changed
    > we offer more than we have. If the application eats
    > the data slowly and we receive more data than the available space
    > the queue is pruned...

    Only out of order data should be pruned so this is fine. We have a situation
    where we are out of resources, we wish the other end to slow down and we need
    to flag the situation but cannot shrink the window. Dropping a frame is
    exactly that.

    In fact I found it worked extremely well because it also tended to cause
    silly window avoidance and get the other end back sending MTU sized blocks
    as the stall gave the sender time to build full blocks of data.

    The only really important thing for current code will be that rx_copybreak
    is > about 2/3rds of the MTU of the device using it.

    Alan


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/faq.html

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:2.993 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site