On Wed, Nov 8, 2017 at 12:29 PM, Eric Dumazet wrote:
> Please do not top post on netdev.
Right - apologies for that.
>
> On Wed, 2017-11-08 at 11:04 -0500, Vitaly Davidovich wrote:
>> So this issue is somehow related to setting SO_RCVBUF *after*
>> connecting the socket (from the client). The sys
Please do not top post on netdev.
On Wed, 2017-11-08 at 11:04 -0500, Vitaly Davidovich wrote:
> So this issue is somehow related to setting SO_RCVBUF *after*
> connecting the socket (from the client). The system is configured
> such that the default rcvbuf size is 1MB, but the code was shrinking
So this issue is somehow related to setting SO_RCVBUF *after*
connecting the socket (from the client). The system is configured
such that the default rcvbuf size is 1MB, but the code was shrinking
this down to 75Kb right after connect(). I think that explains why
the window size advertised by the
On Fri, 2017-11-03 at 14:28 -0400, Vitaly Davidovich wrote:
> So Eric, while I still have your interest here (although I know it's
> waning :)), any code pointers to where I might look to see if a
> specific small-ish rcv buf size may interact poorly with the rest of
> the stack? Is it possible so
On Fri, Nov 3, 2017 at 1:58 PM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 13:23 -0400, Vitaly Davidovich wrote:
>> On Fri, Nov 3, 2017 at 12:05 PM, Eric Dumazet wrote:
>> > On Fri, 2017-11-03 at 11:13 -0400, Vitaly Davidovich wrote:
>> >> Ok, an interesting finding. The client was originally r
On Fri, 2017-11-03 at 13:23 -0400, Vitaly Davidovich wrote:
> On Fri, Nov 3, 2017 at 12:05 PM, Eric Dumazet wrote:
> > On Fri, 2017-11-03 at 11:13 -0400, Vitaly Davidovich wrote:
> >> Ok, an interesting finding. The client was originally running with
> >> SO_RCVBUF of 75K (apparently someone deci
On Fri, Nov 3, 2017 at 12:05 PM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 11:13 -0400, Vitaly Davidovich wrote:
>> Ok, an interesting finding. The client was originally running with
>> SO_RCVBUF of 75K (apparently someone decided to set that for some
>> unknown reason). I tried the test with
On Fri, 2017-11-03 at 11:13 -0400, Vitaly Davidovich wrote:
> Ok, an interesting finding. The client was originally running with
> SO_RCVBUF of 75K (apparently someone decided to set that for some
> unknown reason). I tried the test with a 1MB recv buffer and
> everything works perfectly! The cli
Ok, an interesting finding. The client was originally running with
SO_RCVBUF of 75K (apparently someone decided to set that for some
unknown reason). I tried the test with a 1MB recv buffer and
everything works perfectly! The client responds with 0 window alerts,
the server just hits the persist
On Fri, Nov 3, 2017 at 9:39 AM, Vitaly Davidovich wrote:
> On Fri, Nov 3, 2017 at 9:02 AM, Eric Dumazet wrote:
>> On Fri, 2017-11-03 at 06:00 -0700, Eric Dumazet wrote:
>>> On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
>>> > Hi Eric,
>>> >
>>> > Ran a few more tests yesterday with p
On Fri, Nov 3, 2017 at 9:02 AM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 06:00 -0700, Eric Dumazet wrote:
>> On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
>> > Hi Eric,
>> >
>> > Ran a few more tests yesterday with packet captures, including a
>> > capture on the client. It turns
On Fri, Nov 3, 2017 at 9:00 AM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
>> Hi Eric,
>>
>> Ran a few more tests yesterday with packet captures, including a
>> capture on the client. It turns out that the client stops ack'ing
>> entirely at some point in th
On Fri, 2017-11-03 at 06:00 -0700, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
> > Hi Eric,
> >
> > Ran a few more tests yesterday with packet captures, including a
> > capture on the client. It turns out that the client stops ack'ing
> > entirely at some poi
On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
> Hi Eric,
>
> Ran a few more tests yesterday with packet captures, including a
> capture on the client. It turns out that the client stops ack'ing
> entirely at some point in the conversation - the last advertised
> client window is not
Hi Eric,
Ran a few more tests yesterday with packet captures, including a
capture on the client. It turns out that the client stops ack'ing
entirely at some point in the conversation - the last advertised
client window is not even close to zero (it's actually ~348K). So
there's complete radio si
On Wed, 2017-11-01 at 22:22 +, Vitaly Davidovich wrote:
> Eric,
>
> Yes I agree. However the thing I’m still puzzled about is the client
> application is not reading/draining the recvq - ok, the client tcp
> stack should start advertising a 0 window size. Does a 0 window size
> count agains
On Wed, 2017-11-01 at 21:45 +, Vitaly Davidovich wrote:
> Hi Eric,
>
>
> First, thanks for replying. A couple of comments inline.
>
> On Wed, Nov 1, 2017 at 4:51 PM Eric Dumazet
> wrote:
>
> On Wed, 2017-11-01 at 13:34 -0700, Eric Dumazet wrote:
> > On Wed, 2017-11-01 at 1
On Wed, 2017-11-01 at 13:34 -0700, Eric Dumazet wrote:
> On Wed, 2017-11-01 at 16:25 -0400, Vitaly Davidovich wrote:
> > Hi all,
> >
> > I'm seeing some puzzling TCP behavior that I'm hoping someone on this
> > list can shed some light on. Apologies if this isn't the right forum
> > for this type
On Wed, 2017-11-01 at 16:25 -0400, Vitaly Davidovich wrote:
> Hi all,
>
> I'm seeing some puzzling TCP behavior that I'm hoping someone on this
> list can shed some light on. Apologies if this isn't the right forum
> for this type of question. But here goes anyway :)
>
> I have client and serve
Hi all,
I'm seeing some puzzling TCP behavior that I'm hoping someone on this
list can shed some light on. Apologies if this isn't the right forum
for this type of question. But here goes anyway :)
I have client and server x86-64 linux machines with the 4.1.35 kernel.
I set up the following tes
20 matches
Mail list logo
