Strange thing is that sender does not misbehave at the beginning when
receiver window is still small. Only after a while.
Just guessing, but when the receiver window is small, the sender cannot
get a large quantity of data out there at once, so any string of lost
packets will tend to be smal
On Thu, 2015-01-08 at 17:47 +, Erik Grinaker wrote:
> FWIW, I've done a bisection, and it’s triggered by this change:
>
> https://github.com/torvalds/linux/commit/4e4f1fc226816905c937f9b29dabe351075dfe0f
This totally makes sense, thanks for doing the bisection !
>
> > We are not going to
On 07 Jan 2015, at 21:33, Eric Dumazet wrote:
> On Wed, 2015-01-07 at 20:37 +, Erik Grinaker wrote:
> I agree. I have contacted Amazon about this, but am not too hopeful
>> for a quick fix; they have been promising SACK-support on their
>> loadbalancers since 2006, for example.
>>
>> That sai
On Wed, Jan 7, 2015 at 12:37 PM, Erik Grinaker wrote:
> On 07 Jan 2015, at 15:58, Eric Dumazet wrote:
>> On Wed, 2015-01-07 at 13:31 +, Erik Grinaker wrote:
>>> On 06 Jan 2015, at 22:00, Yuchung Cheng wrote:
On Tue, Jan 6, 2015 at 1:04 PM, Erik Grinaker wrote:
>
>> On 06 Jan 20
On Wed, 2015-01-07 at 20:37 +, Erik Grinaker wrote:
> I agree. I have contacted Amazon about this, but am not too hopeful
> for a quick fix; they have been promising SACK-support on their
> loadbalancers since 2006, for example.
>
> That said, since this change breaks a service as popular as
On 07 Jan 2015, at 15:58, Eric Dumazet wrote:
> On Wed, 2015-01-07 at 13:31 +, Erik Grinaker wrote:
>> On 06 Jan 2015, at 22:00, Yuchung Cheng wrote:
>>> On Tue, Jan 6, 2015 at 1:04 PM, Erik Grinaker wrote:
> On 06 Jan 2015, at 20:26, Erik Grinaker wrote:
This still doesn’t e
On Wed, 2015-01-07 at 13:31 +, Erik Grinaker wrote:
> On 06 Jan 2015, at 22:00, Yuchung Cheng wrote:
> > On Tue, Jan 6, 2015 at 1:04 PM, Erik Grinaker wrote:
> >>
> >>> On 06 Jan 2015, at 20:26, Erik Grinaker wrote:
> >> This still doesn’t explain why it works with older kernels, but not ne
On 06 Jan 2015, at 22:00, Yuchung Cheng wrote:
> On Tue, Jan 6, 2015 at 1:04 PM, Erik Grinaker wrote:
>>
>>> On 06 Jan 2015, at 20:26, Erik Grinaker wrote:
>> This still doesn’t explain why it works with older kernels, but not newer
>> ones. I’m thinking it’s
> probably some minor change, whic
On 07 Jan 2015, at 01:23, Lukas Tribus wrote:
>> This still doesn’t explain why it works with older kernels, but not newer
>> ones.
>
> Can you try the different 3.12-rc kernels? The information that this was
> introduced in 3.12-rc1 as opposed to a specific -rc>1 releases may help
> the guys he
> This still doesn’t explain why it works with older kernels, but not newer
> ones.
Can you try the different 3.12-rc kernels? The information that this was
introduced in 3.12-rc1 as opposed to a specific -rc>1 releases may help
the guys here to pinpoint what exactly caused the behavior change on
On Tue, Jan 6, 2015 at 1:04 PM, Erik Grinaker wrote:
>
>> On 06 Jan 2015, at 20:26, Erik Grinaker wrote:
>>
>>>
>>> On 06 Jan 2015, at 20:13, Eric Dumazet wrote:
>>>
>>> On Tue, 2015-01-06 at 19:42 +, Erik Grinaker wrote:
>>>
The transfer on the functioning Netherlands server does indee
> On 06 Jan 2015, at 20:26, Erik Grinaker wrote:
>
>>
>> On 06 Jan 2015, at 20:13, Eric Dumazet wrote:
>>
>> On Tue, 2015-01-06 at 19:42 +, Erik Grinaker wrote:
>>
>>> The transfer on the functioning Netherlands server does indeed use SACKs,
>>> while the Norway servers do not.
>>>
>>>
> On 06 Jan 2015, at 20:13, Eric Dumazet wrote:
>
> On Tue, 2015-01-06 at 19:42 +, Erik Grinaker wrote:
>
>> The transfer on the functioning Netherlands server does indeed use SACKs,
>> while the Norway servers do not.
>>
>> For what it’s worth, I have made stripped down pcaps for a singl
On Tue, 2015-01-06 at 19:42 +, Erik Grinaker wrote:
> The transfer on the functioning Netherlands server does indeed use SACKs,
> while the Norway servers do not.
>
> For what it’s worth, I have made stripped down pcaps for a single failing
> transfer as well as a single functioning transfe
On 06 Jan 2015, at 19:16, Rick Jones wrote:
>
>>> A packet dump [1] shows repeated ACK retransmits for some of the
>> TCP does not retransmit ACK ... do you mean DUPACKs sent by the receiver?
>>
>> I am trying to understand the problem. Could you confirm that it's the
>> HTTP responses sent
On 01/06/2015 11:16 AM, Rick Jones wrote:
I'm assuming one incident starts at XX:41:24.748265 in the trace? That
does look like it is slowly slogging its way through a bunch of lost
traffic, which was I think part of the problem I was seeing with the
middlebox I stepped in, but I don't think I s
> On 06 Jan 2015, at 19:18, Yuchung Cheng wrote:
>
> On Tue, Jan 6, 2015 at 11:01 AM, Erik Grinaker wrote:
>>
>>> On 06 Jan 2015, at 18:33, Yuchung Cheng wrote:
>>>
>>> On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker wrote:
> On 06 Jan 2015, at 17:20, Eric Dumazet wrote:
> On
On Tue, Jan 6, 2015 at 11:01 AM, Erik Grinaker wrote:
>
>> On 06 Jan 2015, at 18:33, Yuchung Cheng wrote:
>>
>> On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker wrote:
>>>
On 06 Jan 2015, at 17:20, Eric Dumazet wrote:
On Tue, 2015-01-06 at 16:11 +, Erik Grinaker wrote:
>> On 06
A packet dump [1] shows repeated ACK retransmits for some of the
TCP does not retransmit ACK ... do you mean DUPACKs sent by the receiver?
I am trying to understand the problem. Could you confirm that it's the
HTTP responses sent from Amazon S3 got stalled, or HTTP requests sent
from the receive
> On 06 Jan 2015, at 18:33, Yuchung Cheng wrote:
>
> On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker wrote:
>>
>>> On 06 Jan 2015, at 17:20, Eric Dumazet wrote:
>>> On Tue, 2015-01-06 at 16:11 +, Erik Grinaker wrote:
> On 06 Jan 2015, at 16:04, Eric Dumazet wrote:
> On Tue, 2015-0
On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker wrote:
>
>> On 06 Jan 2015, at 17:20, Eric Dumazet wrote:
>> On Tue, 2015-01-06 at 16:11 +, Erik Grinaker wrote:
On 06 Jan 2015, at 16:04, Eric Dumazet wrote:
On Tue, 2015-01-06 at 15:14 +, Erik Grinaker wrote:
> (CCing Yuchung
On Tue, 2015-01-06 at 18:17 +, Erik Grinaker wrote:
> Yes, pcap was taken on receiver (195.159.221.106).
>
> > If the sender is broken, changing the kernel on receiver wont help.
> >
> > BTW not using sack (on 54.231.132.98) is terrible for performance in
> > lossy environments.
>
> It may
> On 06 Jan 2015, at 17:20, Eric Dumazet wrote:
> On Tue, 2015-01-06 at 16:11 +, Erik Grinaker wrote:
>>> On 06 Jan 2015, at 16:04, Eric Dumazet wrote:
>>> On Tue, 2015-01-06 at 15:14 +, Erik Grinaker wrote:
(CCing Yuchung, as his name comes up in the relevant commits)
Af
On Tue, 2015-01-06 at 16:11 +, Erik Grinaker wrote:
> > On 06 Jan 2015, at 16:04, Eric Dumazet wrote:
> > On Tue, 2015-01-06 at 15:14 +, Erik Grinaker wrote:
> >> (CCing Yuchung, as his name comes up in the relevant commits)
> >>
> >> After upgrading from Ubuntu 12.04.5 to 14.04.1 we have
> On 06 Jan 2015, at 16:04, Eric Dumazet wrote:
> On Tue, 2015-01-06 at 15:14 +, Erik Grinaker wrote:
>> (CCing Yuchung, as his name comes up in the relevant commits)
>>
>> After upgrading from Ubuntu 12.04.5 to 14.04.1 we have begun seeing
>> intermittent TCP connection hangs for HTTP image
On Tue, 2015-01-06 at 15:14 +, Erik Grinaker wrote:
> (CCing Yuchung, as his name comes up in the relevant commits)
>
> After upgrading from Ubuntu 12.04.5 to 14.04.1 we have begun seeing
> intermittent TCP connection hangs for HTTP image requests against
> Amazon S3. 3-5% of requests will sud
26 matches
Mail list logo
