Messages in this thread | | | Date | Tue, 27 Apr 1999 12:36:35 -0400 | From | Kris Karas <> | Subject | Re: 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/
| |