lkml.org 
[lkml]   [1999]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: select()/socket has problems under 2.2.x.
    Date sent:      	Tue, 09 Mar 1999 00:43:41 -0500
    From: Kris Karas <ktk@ktk.bidmc.harvard.edu>
    To: Andi Kleen <ak@muc.de>
    Copies to: Alan Cox <alan@lxorguk.ukuu.org.uk>, Andrea Arcangeli <andrea@e-mind.com>,
    davem@redhat.com, linux-kernel@vger.rutgers.edu,
    niles@axp745.gsfc.nasa.gov
    Subject: Re: select()/socket has problems under 2.2.x.

    > Andi Kleen wrote:
    >
    > > Alan writes:
    > > > Umm not quite. We always have to honour the _ack_ data provided
    > >
    > > It could be nice though to send an ack when out of order data arrived, even
    > > when the data is dropped (to kick fast retransmit on the other side and to
    > > get the window update there).
    >
    > Speaking of which... Could this (an out-of-order condition) be the cause of the
    > dropped packets on the sending side which I have seen? I.e. one portion assuming
    > this can't happen so not cleaning up, but another portion of the substrate
    > reordering, perhaps as the result of MRU/MTU (over PPP) not being easily
    > divisible into the internal size of SKB's and such? This is not an educted
    > guess, just a random musing. But the problem is real.
    >
    > For DaveM and other folks who have not heard my reports of this before, a quick
    > recap:
    >
    > I have demonstrated with simultaneous tcpdump output from both ends of a Linux
    > 2.2 <--> Linux 2.2 connection that under certain circumstances (large
    > transport-layer latency with sender perceiving shrunk window sizes as a result of
    > delays in getting acks back to sender) the sender will simply forget to send a
    > particular packet. Repeated acks from receiver get things going again, but not
    > until (sometimes multi-second) latency lets those acks get though.
    >
    > The trivially-reproducible test case is when both boxes communicate using ppp0
    > via error-correcting modems. Verbose byte-level dumps of the ppp/lcp packets
    > shows no loss or misframing of bytes/packets due to serial errors; this is
    > confirmed by tcpdump on the sending side, which clearly shows lost packets before
    > they ever go out over the interface (or wherever tcpdump hooks into the layer).
    > Throughput is roughly 50% or slightly better with 36Kb modems (for example).

    So this might be the problem which causes Linux to have horrible
    throughput via modem. Any fix available.

    Best Regards
    Kari Laine




    LinuxWare Oy Mail: kari@linuxware.fi
    Hiidenmäenkuja 15 buster@klaine.pp.fi
    03100 NUMMELA Tel. +358-(0)19-334618/334659
    FINLAND Fax +358-(0)19-334627

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site