[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337699379.1698.30.camel@kjm-desktop.uk.level5networks.com>
Date: Tue, 22 May 2012 16:09:36 +0100
From: Kieran Mansley <kmansley@...arflare.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: Ben Hutchings <bhutchings@...arflare.com>, <netdev@...r.kernel.org>
Subject: Re: TCPBacklogDrops during aggressive bursts of traffic
On Tue, 2012-05-22 at 11:30 +0200, Eric Dumazet wrote:
> Also can you post a pcap capture of problematic flow ?
I'll email this to you directly. The capture is generated with netserver
on the system under test, and NetPerf sending from a similar server.
I've only included the first 1000 frames to keep the capture size down.
There are 7 retransmissions in that capture, and the TCPBacklogDrops
counter incremented by 7 during the test, so I'm happy to say they are
the cause of the drops.
The system under test was running net-next.
I've not tried with another NIC (e.g. tg3) but will see if I can find
one to test.
I've got a feeling that the drops might be easier to reproduce if I
taskset the netserver process to a different package than the one that
is handling the network interrupt for that NIC. This fits with my
earlier theory in that it is likely to increase the overhead of waking
the user-level process to satisfy the read and so increase the time
during which received packets could overflow the backlog. Having a
relatively aggressive sending TCP also helps, e.g. one that is
configured to open its congestion window quickly, as this will produce
more intensive bursts.
Kieran
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists