Hi Alexey,
On Sat, 3 Sep 2005, Alexey Kuznetsov wrote:
Well, take a look at the double acks for 84439343, 84440447 and 84441059,
they seem pretty much identical to me.
It is just a little tcpdump glitch.
19:34:54.532271 < 10.2.20.246.33060 > 65.171.224.182.8700: . 44:44(0) ack 84439343
win
Hello!
> Well, take a look at the double acks for 84439343, 84440447 and 84441059,
> they seem pretty much identical to me.
It is just a little tcpdump glitch.
19:34:54.532271 < 10.2.20.246.33060 > 65.171.224.182.8700: . 44:44(0) ack
84439343 win 24544 (DF) (ttl 64, id
60946)
Hi Alexey,
On Fri, 2 Sep 2005, Alexey Kuznetsov wrote:
This is where things start going bad. The window starts shrinking from
15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
many duplicate acks that serve no purpose
These are not duplicate, TCP_NODELAY sender just
Hello!
> This is where things start going bad. The window starts shrinking from
> 15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
> many duplicate acks that serve no purpose
These are not duplicate, TCP_NODELAY sender just starts flooding
tiny segments, and those are
On Fri, 2 Sep 2005, John Heffner wrote:
If it is window clamping, then you should be asymptotically approaching a
ratio between receive buffer and window that corresponds (with a fudge
factor) to the ratio between TCP segment data size and allocated packet size.
If you make the receive buffer
Hello!
> I wonder if clamping the window though is too harsh. Maybe just
> setting the rcv_ssthresh down is better?
It is too harsh. This was invented before we learned how to collapse
received data, that time tiny segments were fatal and clamping was
the last weapon against misbehaving
On Sep 2, 2005, at 10:33 AM, [EMAIL PROTECTED] wrote:
On Fri, 2 Sep 2005, John Heffner wrote:
Have you tried increasing the size of the receive buffer yet?
Actually, I just did. I changed rmem_max and rmem_default to 4MB and
tcp_rmem to "64k 4MB 4MB". It did seem to help, but I'm wondering
On Fri, 2 Sep 2005, John Heffner wrote:
Have you tried increasing the size of the receive buffer yet?
Actually, I just did. I changed rmem_max and rmem_default to 4MB and
tcp_rmem to "64k 4MB 4MB". It did seem to help, but I'm wondering if
that's simply because it has a _lot_ of memory now
On Sep 2, 2005, at 9:48 AM, Alexey Kuznetsov wrote:
Hello!
If you overflow the socket's memory bound, it ends up calling
tcp_clamp_window(). (I'm not sure this is really the right thing to
do
here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather
On Sep 2, 2005, at 9:52 AM, Alexey Kuznetsov wrote:
Hello!
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no
On Sep 2, 2005, at 10:05 AM, [EMAIL PROTECTED] wrote:
This particular Win2k sender sends _only_ real-time data, it's not
capable of rewinding. So it's always sending small packets, from start
to finish, yet the problem still occurs.
Note that even real-time data can end up generating a
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
From: John Heffner <[EMAIL PROTECTED]>
Date: Thu, 1 Sep 2005 22:51:48 -0400
I have an idea why this is going on. Packets are pre-allocated by the
driver to be a max packet size, so when you send small packets, it
wastes a lot of memory.
Hello!
> I experienced the very same problem but with window size going all the
> way down to just a few bytes (14 bytes). dump files available upon
> requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no matter
how hard network device or peer try to
On Fri, 2 Sep 2005, Guillaume Autran wrote:
I experienced the very same problem but with window size going all the way
down to just a few bytes (14 bytes). dump files available upon requests :)
Ion, how were you able to reproduce the issue ? Can the same type of traffice
always reproduce the
Hello!
> If you overflow the socket's memory bound, it ends up calling
> tcp_clamp_window(). (I'm not sure this is really the right thing to do
> here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather an emergency measure.
So, tcp collapses queue, when
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
Ion, how were you able to reproduce the issue ? Can the same type of
traffice always reproduce the issue or is it more intermittent ?
Best
On Fri, 2 Sep 2005, Noritoshi Demizu wrote:
By the way, if tcpdump does not track the window scale option, the right
edge (ack + real win) does not change between the following two ACKs.
11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win 15340
(DF)
(259 ACKs are
From: John Heffner <[EMAIL PROTECTED]>
Date: Thu, 1 Sep 2005 22:51:48 -0400
> I have an idea why this is going on. Packets are pre-allocated by the
> driver to be a max packet size, so when you send small packets, it
> wastes a lot of memory. Currently Linux uses the packets at the
>
> By the way, if tcpdump does not track the window scale option, the right
> edge (ack + real win) does not change between the following two ACKs.
>
> > 11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win
> > 15340 (DF)
> (259 ACKs are omitted here)
> > 11:34:54.611769
By the way, if tcpdump does not track the window scale option, the right
edge (ack + real win) does not change between the following two ACKs.
11:34:54.337167 10.2.20.246.33060 10.2.224.182.8700: . ack 84402527 win
15340 nop,nop,timestamp 226080473 99717814 (DF)
(259 ACKs are omitted
From: John Heffner [EMAIL PROTECTED]
Date: Thu, 1 Sep 2005 22:51:48 -0400
I have an idea why this is going on. Packets are pre-allocated by the
driver to be a max packet size, so when you send small packets, it
wastes a lot of memory. Currently Linux uses the packets at the
beginning of
On Fri, 2 Sep 2005, Noritoshi Demizu wrote:
By the way, if tcpdump does not track the window scale option, the right
edge (ack + real win) does not change between the following two ACKs.
11:34:54.337167 10.2.20.246.33060 10.2.224.182.8700: . ack 84402527 win 15340
nop,nop,timestamp
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
Ion, how were you able to reproduce the issue ? Can the same type of
traffice always reproduce the issue or is it more intermittent ?
Best
Hello!
If you overflow the socket's memory bound, it ends up calling
tcp_clamp_window(). (I'm not sure this is really the right thing to do
here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather an emergency measure.
So, tcp collapses queue, when it
On Fri, 2 Sep 2005, Guillaume Autran wrote:
I experienced the very same problem but with window size going all the way
down to just a few bytes (14 bytes). dump files available upon requests :)
Ion, how were you able to reproduce the issue ? Can the same type of traffice
always reproduce the
Hello!
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no matter
how hard network device or peer try to confuse
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
From: John Heffner [EMAIL PROTECTED]
Date: Thu, 1 Sep 2005 22:51:48 -0400
I have an idea why this is going on. Packets are pre-allocated by the
driver to be a max packet size, so when you send small packets, it
wastes a lot of memory.
On Sep 2, 2005, at 10:05 AM, [EMAIL PROTECTED] wrote:
This particular Win2k sender sends _only_ real-time data, it's not
capable of rewinding. So it's always sending small packets, from start
to finish, yet the problem still occurs.
Note that even real-time data can end up generating a
On Sep 2, 2005, at 9:52 AM, Alexey Kuznetsov wrote:
Hello!
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no
On Sep 2, 2005, at 9:48 AM, Alexey Kuznetsov wrote:
Hello!
If you overflow the socket's memory bound, it ends up calling
tcp_clamp_window(). (I'm not sure this is really the right thing to
do
here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather
On Fri, 2 Sep 2005, John Heffner wrote:
Have you tried increasing the size of the receive buffer yet?
Actually, I just did. I changed rmem_max and rmem_default to 4MB and
tcp_rmem to 64k 4MB 4MB. It did seem to help, but I'm wondering if
that's simply because it has a _lot_ of memory now to
On Sep 2, 2005, at 10:33 AM, [EMAIL PROTECTED] wrote:
On Fri, 2 Sep 2005, John Heffner wrote:
Have you tried increasing the size of the receive buffer yet?
Actually, I just did. I changed rmem_max and rmem_default to 4MB and
tcp_rmem to 64k 4MB 4MB. It did seem to help, but I'm wondering
Hi Alexey,
On Sat, 3 Sep 2005, Alexey Kuznetsov wrote:
Well, take a look at the double acks for 84439343, 84440447 and 84441059,
they seem pretty much identical to me.
It is just a little tcpdump glitch.
19:34:54.532271 10.2.20.246.33060 65.171.224.182.8700: . 44:44(0) ack 84439343
win
Hello!
I wonder if clamping the window though is too harsh. Maybe just
setting the rcv_ssthresh down is better?
It is too harsh. This was invented before we learned how to collapse
received data, that time tiny segments were fatal and clamping was
the last weapon against misbehaving
On Fri, 2 Sep 2005, John Heffner wrote:
If it is window clamping, then you should be asymptotically approaching a
ratio between receive buffer and window that corresponds (with a fudge
factor) to the ratio between TCP segment data size and allocated packet size.
If you make the receive buffer
Hello!
This is where things start going bad. The window starts shrinking from
15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
many duplicate acks that serve no purpose
These are not duplicate, TCP_NODELAY sender just starts flooding
tiny segments, and those are
Hi Alexey,
On Fri, 2 Sep 2005, Alexey Kuznetsov wrote:
This is where things start going bad. The window starts shrinking from
15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
many duplicate acks that serve no purpose
These are not duplicate, TCP_NODELAY sender just
Hello!
Well, take a look at the double acks for 84439343, 84440447 and 84441059,
they seem pretty much identical to me.
It is just a little tcpdump glitch.
19:34:54.532271 10.2.20.246.33060 65.171.224.182.8700: . 44:44(0) ack
84439343 win 24544 nop,nop,timestamp 226080638 99717832 (DF)
> > Since the TCP Window Scale options are exchanged,
> > the window size field contains shifted value except SYNs.
>
> Be careful, tcpdump may be tracking the window scale and reporting
> scaled values. Seems unlikely since with a window scale of 2, and odd
> window size would be impossible.
I
On Fri, 02 Sep 2005 13:51:38 +0900 (JST)
Noritoshi Demizu <[EMAIL PROTECTED]> wrote:
> Below may not be directly related to the cause of the problem.
> But I think some window sizes in your mail need to be re-evaluated.
>
> > 11:29:54.961998 10.2.20.246.33060 > 10.2.224.182.8700: S
> >
Below may not be directly related to the cause of the problem.
But I think some window sizes in your mail need to be re-evaluated.
> 11:29:54.961998 10.2.20.246.33060 > 10.2.224.182.8700: S
> 1972343059:1972343059(0) win 5840 0,nop,wscale 2> (DF)
> 11:29:54.983334 10.2.224.182.8700 >
On Sep 1, 2005, at 6:53 PM, Ion Badulescu wrote:
A few minutes later it has finally caught up to present time and it
starts receiving smaller packets containing real-time data. The TCP
window is still 16534 at this point.
[tcpdump output removed]
This is where things start going bad. The
On 9/2/05, Ion Badulescu <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> On Thu, 1 Sep 2005, David S. Miller wrote:
>
> > Thanks for the empty posting. Please provide the content you
> > intended to post, and furthermore please post it to the network
> > developer mailing list,
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
First of all, thanks for the reply (even to an empty posting :).
From: Jesper Juhl <[EMAIL PROTECTED]>
Date: Fri, 2 Sep 2005 00:49:20 +0200
> Hmm, I see plenty of content in the post. Want me to farward you a
> copy off list ?
Please do, I didn't see anything.
It still needs to be reposted to netdev@vger.kernel.org
anyways :)
-
To unsubscribe from this list:
On 9/2/05, David S. Miller <[EMAIL PROTECTED]> wrote:
>
> Thanks for the empty posting. Please provide the content you
> intended to post, and furthermore please post it to the network
> developer mailing list, netdev@vger.kernel.org
>
Hmm, I see plenty of content in the post. Want me to
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On 9/2/05, David S. Miller [EMAIL PROTECTED] wrote:
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
Hmm, I see plenty of content in the post. Want me to farward you a
From: Jesper Juhl [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 00:49:20 +0200
Hmm, I see plenty of content in the post. Want me to farward you a
copy off list ?
Please do, I didn't see anything.
It still needs to be reposted to netdev@vger.kernel.org
anyways :)
-
To unsubscribe from this list:
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
First of all, thanks for the reply (even to an empty posting :).
On 9/2/05, Ion Badulescu [EMAIL PROTECTED] wrote:
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
First
On Sep 1, 2005, at 6:53 PM, Ion Badulescu wrote:
A few minutes later it has finally caught up to present time and it
starts receiving smaller packets containing real-time data. The TCP
window is still 16534 at this point.
[tcpdump output removed]
This is where things start going bad. The
Below may not be directly related to the cause of the problem.
But I think some window sizes in your mail need to be re-evaluated.
11:29:54.961998 10.2.20.246.33060 10.2.224.182.8700: S
1972343059:1972343059(0) win 5840 mss 1460,sackOK,timestamp 225781001
0,nop,wscale 2 (DF)
On Fri, 02 Sep 2005 13:51:38 +0900 (JST)
Noritoshi Demizu [EMAIL PROTECTED] wrote:
Below may not be directly related to the cause of the problem.
But I think some window sizes in your mail need to be re-evaluated.
11:29:54.961998 10.2.20.246.33060 10.2.224.182.8700: S
Since the TCP Window Scale options are exchanged,
the window size field contains shifted value except SYNs.
Be careful, tcpdump may be tracking the window scale and reporting
scaled values. Seems unlikely since with a window scale of 2, and odd
window size would be impossible.
I am sorry
56 matches
Mail list logo
