lkml.org 
[lkml]   [1999]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: select()/socket has problems under 2.2.x.
Kari Laine wrote:

> > Andi Kleen wrote: [actually that was me -ktk]

> > 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.
>
> So this might be the problem which causes Linux to have horrible
> throughput via modem. Any fix available.

Hmm. My father, a nationally-honored ME and industrial designer here in the US, loves to work on
cars in his spare time; one of his favorite rules of thumb is that "if it doesn't run well, it's most
likely due to more than one individual problem." In that spirit, believe I have identified three
problems that plagued me, one of which is not Linux's:

1. When txqueuelen is set low (e.g. <=10) the queue into the ppp0 device overflows and packets are
occasionally lost. This explains the mysterious missing-packet problem I provided tcpdumps for.
Increasing txqueuelen "fixed" that problem.

2. After initial establishment of the modem link, telephone line noise causes a flurry of missed
bits, requiring the modems to retransmit and ultimately degrade DCE-DCE speed. Prior to each
retrain, which lasts a few seconds each, the errored bits cause an internal modem retransmit,
delaying logical delivery of the data to Linux by a few hundred milliseconds at a time. This timing
variability, which is not Linux's fault, exacerbates (I hypothesize) a third problem:

3. Extended latency of transmission, often due to large serial buffers in external modems, seems to
trigger an unwanted nagle-like response, introducing gratuitous delays in transmission even when the
serial buffers have emptied and the acks have made their way home.

So my hunch is that the combination of 1, 2, and 3 above conspires to reduce throughput to a fraction
of what it otherwise could be.

Alan, Dave: I'm curious about one thing: if memory serves, the recommendation to drop txqueuelen on
ppp interfaces was to limit the queue such that interactive processes wouldn't be rendered useless by
bulk transfers. How, then does the protocol (or interaction of TCP substrate and transmission layer)
arrange to supposedly not drop packets? If txqueuelen=2 or 4, shouldn't the link adapt somehow to
ensure that packets aren't dropped due to overflows of the outgoing buffer? If not, wouldn't it be
better to keep txquueuelen high and just grin and bear the latency for interactive use?

Kris



-
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    [W:0.300 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site