Re: Linux TCP - unexpected retransmissions

On May 29, 9:15 pm, Dan N <d...@xxxxxxxxxxxxx> wrote:
On Tue, 29 May 2007 06:15:00 -0700, Francois wrote:
We
suspect that under certain conditions (heavy burst of messages, or
messages arriving at the same time), the stack drops or postpones
processing of events (holding locks, buffering) causing timers to
trigger retransmissions.

That sounds like a reasonable explanation to me. Or the link layer drops
data because of timing constraints and/or limited resource, so the tcp
stack never sees it.

Others have suggested using link layer protocol only, but what about using
udp?

Dan

We have considered using UDP. Although feasible, it would be a
significant of work, not so much to implement but to prove for
correctness. Rightly or wrongly, we made a number of assumptions early
on in the design that were driven by the fact that we used TCP thus
there would be a need to implement additional services on top of UDP
and prove correctness.

We first wanted to isolate the root cause of this latency. As
described above, we suspect the problem related the TCP stack but we
have not proven this yet. We were hoping someone on the net would
confirm that either the current design of the Linux TCP stack could
result in such behaviour, or that this a bug and even better point us
towards a fix.

Thanks
Francois

.

Relevant Pages

  • Re: Linux TCP - unexpected retransmissions
    ... messages arriving at the same time), ... buffering) causing timers to ... stack never sees it. ... Others have suggested using link layer protocol only, ...
    (comp.os.linux.networking)
  • Re: End of the line....
    ... Is the current stack so bad as that it needs it, ... CPU cycles. ... want the controller to raise an interrupt for. ... Though I suspect they shoudn't be a significant amount of load. ...
    (comp.sys.acorn.misc)
  • Re: System.StackOverflowException
    ... Most stack overflows are caused by infinite recursion loops. ... The imprudent use of structs in .NET. ... I would first suspect that you have an infinite recursive loop. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Help me for a typical problem regarding KeAquireSpinLock which is not Locking other Thread in Sa
    ... variable on the stack. ... I suspect there are other problems but that is the obvious first one. ... For that matter why are you allocating these at all, KIRQL and KSPIN_LOCK are both <= sizeof? ...
    (microsoft.public.development.device.drivers)
  • Re: Ada.Command_Line and wildcards
    ... nothing in RM requires or implies that. ... Past experience. ... but I suspect it's more often the case then not. ... because GNAT has heap larger than stack. ...
    (comp.lang.ada)