[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADVnQynpqRkkY8eYrDZkkHUwyRgQsahyqVoU=T89ggG4xZi-Ww@mail.gmail.com>
Date: Mon, 4 Aug 2014 13:08:51 -0400
From: Neal Cardwell <ncardwell@...gle.com>
To: Alexander.Steffen@...ineon.com
Cc: Netdev <netdev@...r.kernel.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Yuchung Cheng <ycheng@...gle.com>
Subject: Fwd: Fw: [Bug 81661] New: Network Performance Regression for large
TCP transfers starting with v3.10
On Mon, Aug 4, 2014 at 12:05 PM, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=81661
>
> Bug ID: 81661
> Summary: Network Performance Regression for large TCP transfers
> starting with v3.10
[sorry for re-send; fixing typo in e-mail address...]
Hi Alexander,
Thanks for the detailed report!
We think we have a sense of what might be happening, but the traces
are a little hard to interpret.
The capture-bad-site1 trace seems to be a sender-side trace that
shows SACK blocks with sequence numbers that are 613M bytes ahead of
what has actually been sent, suggesting perhaps a middlebox is
rewriting sequence numbers, but not SACK options, or vice versa.
The capture-bad-site2 trace seems well-formed, but seems to be taken
on the receiver side, which makes it difficult to interpret exactly
what is going wrong on the sending side.
Would you be able to reproduce the capture-bad-site2 case but take a
sender-side tcpdump trace?
Thanks!
neal
--
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