* [patch 2.6.13-git3 1/5] sis190: unmask the link change events
From: Francois Romieu @ 2005-09-02 22:54 UTC (permalink / raw)
To: netdev
Cc: pascal.chapperon, lars.vahlenberg, Alexey Dobriyan, apatard,
jgarzik, akpm
In-Reply-To: <20050902225224.GA25687@electric-eye.fr.zoreil.com>
link changes reporting does not work when the driver masks its irq event
Signed-off-by: Arnaud Patard <apatard@mandriva.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
diff -puN a/drivers/net/sis190.c~sis190-170 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-170 2005-09-02 23:27:18.621147267 +0200
+++ b/drivers/net/sis190.c 2005-09-02 23:27:18.643143712 +0200
@@ -360,7 +360,7 @@ MODULE_VERSION(DRV_VERSION);
MODULE_LICENSE("GPL");
static const u32 sis190_intr_mask =
- RxQEmpty | RxQInt | TxQ1Int | TxQ0Int | RxHalt | TxHalt;
+ RxQEmpty | RxQInt | TxQ1Int | TxQ0Int | RxHalt | TxHalt | LinkChange;
/*
* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
@@ -923,6 +923,7 @@ static void sis190_phy_task(void * data)
BMSR_ANEGCOMPLETE)) {
net_link(tp, KERN_WARNING "%s: PHY reset until link up.\n",
dev->name);
+ netif_carrier_off(dev);
mdio_write(ioaddr, phy_id, MII_BMCR, val | BMCR_RESET);
mod_timer(&tp->timer, jiffies + SIS190_PHY_TIMEOUT);
} else {
_
^ permalink raw reply
* [2.6 patch] net/atm/ioctl.c should #include "common.h"
From: Adrian Bunk @ 2005-09-02 21:24 UTC (permalink / raw)
To: chas; +Cc: linux-atm-general, netdev, linux-kernel
Every file should #include the header files containing the prototypes of
it's global functions.
common.h contains the prototype for vcc_ioctl().
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-mm1-full/net/atm/ioctl.c.old 2005-09-02 23:01:46.000000000 +0200
+++ linux-2.6.13-mm1-full/net/atm/ioctl.c 2005-09-02 23:17:06.000000000 +0200
@@ -21,6 +21,7 @@
#include "resources.h"
#include "signaling.h" /* for WAITING and sigd_attach */
+#include "common.h"
static DECLARE_MUTEX(ioctl_mutex);
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-02 21:18 UTC (permalink / raw)
To: Ion Badulescu
Cc: Alexey Kuznetsov, Ion Badulescu, David S. Miller, linux-kernel,
linux-net, netdev
In-Reply-To: <Pine.LNX.4.61.0509021609430.6083@guppy.limebrokerage.com>
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) (ttl 64, id 60946)
19:34:54.532432 < 10.2.20.246.33060 > 65.171.224.182.8700: . 44:44(0) ack 84439343 win 24544 <nop,nop,timestamp 226080638 99717832> (DF) (ttl 64, id 60946)
It is one ACK (look at IP ID), shown twice. This happens sometimes
with our packet socket.
> >I still do not know how the value of 184 is possible in your case,
> >I would expect 730 as an absolute possible minumum. I see 9420 (2355*4).
>
> The numbers I mentioned are straight from the tcpdump and are not scaled,
I understood. I expect when 184*4, when you said 184. But minimum is
still 730 (unscaled 1460*2). If you really saw values lower than 730
(unscaled 1460*2), there is another more severe problem and the suggested
patch will not solve it.
Alexey
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-02 21:08 UTC (permalink / raw)
To: Guillaume Autran
Cc: Alexey Kuznetsov, John Heffner, Ion Badulescu, David S. Miller,
linux-net, netdev
In-Reply-To: <4318A06A.1000702@mrv.com>
Hello!
> The server socket sockopt are all default, except for the
> TCP_WINDOW_CLAMP which is set to 1400 (application specific).
It is definitely not all. If you do not fiddle with SO_RCVBUF also,
you will always have receiver advertising window of 1400.
11:15:00.922119 IP 10.10.10.3.1150 > 10.10.10.2.3200: S 2246605788:2246605788(0) win 6144 <mss 1460,nop,wscale 0,nop,nop,timestamp 3248699 0>
11:15:00.922791 IP 10.10.10.2.3200 > 10.10.10.3.1150: S 3863556410:3863556410(0) ack 2246605789 win 1400 <mss 1460,nop,nop,timestamp 268188460 3248699,nop,wscale 0>
11:15:00.923118 IP 10.10.10.3.1150 > 10.10.10.2.3200: . ack 1 win 6144 <nop,nop,timestamp 3248699 268188460>
11:15:00.923486 IP 10.10.10.3.1150 > 10.10.10.2.3200: P 1:7(6) ack 1 win 6144 <nop,nop,timestamp 3248699 268188460>
11:15:00.924143 IP 10.10.10.2.3200 > 10.10.10.3.1150: . ack 7 win 1394 <nop,nop,timestamp 268188460 3248699>
cannot happen. SO_RCVBUF is not default.
Alexey
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Ion Badulescu @ 2005-09-02 20:57 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: Ion Badulescu, David S. Miller, linux-kernel, linux-net, netdev
In-Reply-To: <20050902183656.GA16537@yakov.inr.ac.ru>
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 starts flooding
> tiny segments, and those are normal ACKs acking those segments, note
> ACK field is not the same.
Well, take a look at the double acks for 84439343, 84440447 and 84441059,
they seem pretty much identical to me.
> I still do not know how the value of 184 is possible in your case,
> I would expect 730 as an absolute possible minumum. I see 9420 (2355*4).
The numbers I mentioned are straight from the tcpdump and are not scaled,
so they need to be multiplied by 4. But even 9420, combined with a RTT of
20ms, results in a total usable bandwidth of about 3.75 Mbps, not enough
for this real-time stream at peak times.
Besides, it often gets even worse than 2355, all it takes is a few
application slowdowns.
> Anyway, ignoring this puzzle, the following patch for 2.4 should help.
>
>
> --- net/ipv4/tcp_input.c.orig 2003-02-20 20:38:39.000000000 +0300
> +++ net/ipv4/tcp_input.c 2005-09-02 22:28:00.845952888 +0400
> @@ -343,8 +343,6 @@
> app_win -= tp->ack.rcv_mss;
> app_win = max(app_win, 2U*tp->advmss);
>
> - if (!ofo_win)
> - tp->window_clamp = min(tp->window_clamp, app_win);
> tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
> }
> }
That makes perfect sense...
I'll test it out on Tuesday, when I can connect again to the real-time
streams that we use.
Thanks a lot!
-Ion
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Guillaume Autran @ 2005-09-02 18:56 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: John Heffner, Ion Badulescu, David S. Miller, linux-net, netdev
In-Reply-To: <20050902173228.GA15925@yakov.inr.ac.ru>
The server socket sockopt are all default, except for the
TCP_WINDOW_CLAMP which is set to 1400 (application specific).
Guillaume.
Alexey Kuznetsov wrote:
>Hello!
>
>
>
>>Do you think this will also fix Ion's issue with small window size never
>>going back up ?
>>
>>
>
>I was wrong even about this one. That bad case, which I rememebered,
>is not triggered here. And even if packet lengths and windows were modified
>to trigger it, the effect would not be so pathological.
>
>
>12:23:24.474506 IP 10.10.10.3.3560 > 10.10.10.2.3200: P 13323:14703(1380) ack 1 win 6144 <nop,nop,timestamp 3256371 268597947>
>12:23:24.508950 IP 10.10.10.2.3200 > 10.10.10.3.3560: . ack 14703 win 14 <nop,nop,timestamp 268598804 3256371>
>
>This value for window is OK, we adverised 1394, so we have to reply with 14.
>
>But where is the ACK opening full window after receiver application
>reads data from buffer? It is the puzzle. It looks like rcvbuf is still
>full.
>
>Now sender cannot send anything due to SWS avoidance.
>
>12:23:29.362161 IP 10.10.10.3.3560 > 10.10.10.2.3200: . 14703:14717(14) ack 1 win 6144 <nop,nop,timestamp 3256380 268597947>
>
>I interpret this as SWS avoidance override timer.
>
>12:23:29.362791 IP 10.10.10.2.3200 > 10.10.10.3.3560: . ack 14717 win 14 <nop,nop,timestamp 268599289 3256380>
>
>This is impossible. :-) Well, it is possible, if rcv_mss is 14. It is what
>I thought, but it is impossible. :-)
>
>Honestly, I still cannot invent any way how this could happen.
>
>Can you say what setsockopt()s were made on receiver socket? It looks
>like just fiddlined with SO_RCVBUF is not enough.
>
>Alexey
>
>
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-02 18:36 UTC (permalink / raw)
To: Ion Badulescu; +Cc: David S. Miller, linux-kernel, linux-net, netdev
In-Reply-To: <Pine.LNX.4.61.0509011845040.6083@guppy.limebrokerage.com>
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 normal ACKs acking those segments, note
ACK field is not the same.
> Five minutes later the TCP window is still at 2355,
....
> We are kind of stumped at this point, and it's proving to be a
> show-stopping bug for our purposes, especially over WAN links that have
> higher latency (for obvious reasons). Any kind of assistance would be
> greatly appreciated.
I still do not know how the value of 184 is possible in your case,
I would expect 730 as an absolute possible minumum. I see 9420 (2355*4).
Anyway, ignoring this puzzle, the following patch for 2.4 should help.
--- net/ipv4/tcp_input.c.orig 2003-02-20 20:38:39.000000000 +0300
+++ net/ipv4/tcp_input.c 2005-09-02 22:28:00.845952888 +0400
@@ -343,8 +343,6 @@
app_win -= tp->ack.rcv_mss;
app_win = max(app_win, 2U*tp->advmss);
- if (!ofo_win)
- tp->window_clamp = min(tp->window_clamp, app_win);
tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
}
}
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-02 17:32 UTC (permalink / raw)
To: Guillaume Autran
Cc: Alexey Kuznetsov, John Heffner, Ion Badulescu, David S. Miller,
linux-net, netdev
In-Reply-To: <431877EE.6010101@mrv.com>
Hello!
> Do you think this will also fix Ion's issue with small window size never
> going back up ?
I was wrong even about this one. That bad case, which I rememebered,
is not triggered here. And even if packet lengths and windows were modified
to trigger it, the effect would not be so pathological.
12:23:24.474506 IP 10.10.10.3.3560 > 10.10.10.2.3200: P 13323:14703(1380) ack 1 win 6144 <nop,nop,timestamp 3256371 268597947>
12:23:24.508950 IP 10.10.10.2.3200 > 10.10.10.3.3560: . ack 14703 win 14 <nop,nop,timestamp 268598804 3256371>
This value for window is OK, we adverised 1394, so we have to reply with 14.
But where is the ACK opening full window after receiver application
reads data from buffer? It is the puzzle. It looks like rcvbuf is still
full.
Now sender cannot send anything due to SWS avoidance.
12:23:29.362161 IP 10.10.10.3.3560 > 10.10.10.2.3200: . 14703:14717(14) ack 1 win 6144 <nop,nop,timestamp 3256380 268597947>
I interpret this as SWS avoidance override timer.
12:23:29.362791 IP 10.10.10.2.3200 > 10.10.10.3.3560: . ack 14717 win 14 <nop,nop,timestamp 268599289 3256380>
This is impossible. :-) Well, it is possible, if rcv_mss is 14. It is what
I thought, but it is impossible. :-)
Honestly, I still cannot invent any way how this could happen.
Can you say what setsockopt()s were made on receiver socket? It looks
like just fiddlined with SO_RCVBUF is not enough.
Alexey
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Guillaume Autran @ 2005-09-02 16:18 UTC (permalink / raw)
To: linux-net, netdev
In-Reply-To: <20050902154424.GA15060@yakov.inr.ac.ru>
Hi Alexey,
Do you think this will also fix Ion's issue with small window size never
going back up ?
Thanks
Guillaume.
Alexey Kuznetsov wrote:
>Hello!
>
>
>
>>Here are the dumps...
>>
>>
>
>I see. It has nothing to do with clamping. Indeed this is a very old bug.
>Frankly speaking I even was aware about this at some moment
>(so that if the sender was Linux it would not happen. It was fixed there. :-))
>
>With such small window sender is forced to send a tiny segment
>via SWS override timer and receiver is confused in believing this
>is sender's mss, so the result is broken SWS avoidance.
>
>I think you can cure it deleting the following lines:
>
> /* If PSH is not set, packet should be
> * full sized, provided peer TCP is not badly broken.
> * This observation (if it is correct 8)) allows
> * to handle super-low mtu links fairly.
> */
> (len >= TCP_MIN_MSS + sizeof(struct tcphdr) &&
> !(tcp_flag_word(skb->h.th)&TCP_REMNANT))) {
>
>
>in tcp_input.c:tcp_measure_rcv_mss() at receiver side.
>
>
>Alexey
>
>
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Ion Badulescu @ 2005-09-02 15:43 UTC (permalink / raw)
To: John Heffner; +Cc: David S. Miller, linux-net, linux-kernel, netdev
In-Reply-To: <002cb4586f9d008438e81da96e5cecd0@psc.edu>
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 large enough, then the clamped window should
> still end up big enough.
For what it's worth, running with a 512k receive buffer still caused the
clamping to occur, though it took longer than with the normal buffer size.
The window went down from a maximum of 12291 (times 2^4 due to window
scaling) to 3190 currently. That's still enough for our purposes, but I'll
keep monitoring it to see if it shrinks any further. It could be a viable
work-around for the time being.
Is this a bug, though, or a feature? :)
> Also, since you have "real time" data, a larger
> receive buffer should probably be adequate to eliminate this problem, since
> it only occurs when the receiving application falls behind for a while, and a
> bigger receive buffer allows it to fall behind more without triggering the
> window clamping.
Correct. I noticed too while experimenting that the clamping never occurs
if the application is fast enough to keep the socket buffer empty. It's
when data is allowed to accumulate in the buffer that the window shrinks,
and then it never grows back, as if a portion of the buffer got lost
permanently.
-Ion
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-02 15:11 UTC (permalink / raw)
To: John Heffner
Cc: Alexey Kuznetsov, Ion Badulescu, linux-kernel, David S. Miller,
linux-net, netdev
In-Reply-To: <4629cfbdf1af310d5c6cffd7178cff5b@psc.edu>
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 connections.
It can be removed.
Actually, right solution would be an attempt to calculate ratio
window/rcvbuf dynamically. It looked quite tricky, so it was not done.
Instead it is controlled with static sysctl sysctl_tcp_adv_win_scale.
It does not work sometimes f.e. when a device has larger link level overhead.
I think, this should be reconsidered.
> Why the distinction between
> in-order and out-of-order data? Because you expect in-order data to be
> a persistent case?
Overflow in in-order data is hard, we cannot drop data. Also, it means
that receiving application cannot hold to receive rate and we can shrink
window.
Out-of-order data are different: we can drop the segments if we are
in serious troubles and overflow there can be cured by expansion of window
to allow fast retransmit.
Alexey
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner @ 2005-09-02 14:48 UTC (permalink / raw)
To: lists; +Cc: David S. Miller, linux-net, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.61.0509021022230.6083@guppy.limebrokerage.com>
On Sep 2, 2005, at 10:33 AM, lists@limebrokerage.com 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 if
> that's simply because it has a _lot_ of memory now to leak before it
> starts eating up into the window size.
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 large enough, then the
clamped window should still end up big enough. Also, since you have
"real time" data, a larger receive buffer should probably be adequate
to eliminate this problem, since it only occurs when the receiving
application falls behind for a while, and a bigger receive buffer
allows it to fall behind more without triggering the window clamping.
-John
^ permalink raw reply
* 女の子のエロ教えます。
From: ネット流失 @ 2005-09-02 14:34 UTC (permalink / raw)
To: netdev
毎日更新ちゅーーう！！
** 現役女子○学生！ ネット流失モロ画像
http://hydorojet.com/gf/?76220190458024260
** 高画質萌えアニメ
http://hydorojet.com/gf/?76220190458024260
** 写メ画丸秘投稿写真
http://hydorojet.com/gf/?76220190458024260
** 薄毛 われめ拡大画像
http://hydorojet.com/gf/?76220190458024260
** 美少女グチョグチョ動画
http://hydorojet.com/gf/?76220190458024260
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: lists @ 2005-09-02 14:33 UTC (permalink / raw)
To: John Heffner; +Cc: David S. Miller, linux-net, linux-kernel, netdev
In-Reply-To: <6064b8272aa4562242eb60eb75c7cdae@psc.edu>
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 leak before it
starts eating up into the window size.
I also ran into some very strange packet loss problems that weren't
occurring yesterday; they only started occurring after I increased the
buffer size. Most strange. If they happen again, I'll make sure I capture
the flow to analyze it.
Anyway, that was just to see if I can do anything at all to mitigate the
problem. I'll try again with smaller buffers (4k 128k 256k) and see what
happens.
Thanks,
-Ion
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner @ 2005-09-02 14:16 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: Ion Badulescu, linux-kernel, David S. Miller, linux-net, netdev
In-Reply-To: <20050902134807.GB12617@yakov.inr.ac.ru>
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 an emergency
> measure.
> So, tcp collapses queue, when it is necessary, but it must reduce
> window
> as well.
Right.
I wonder if clamping the window though is too harsh. Maybe just
setting the rcv_ssthresh down is better? Why the distinction between
in-order and out-of-order data? Because you expect in-order data to be
a persistent case?
-John
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner @ 2005-09-02 14:11 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: Ion Badulescu, Guillaume Autran, linux-kernel, David S. Miller,
linux-net, netdev
In-Reply-To: <20050902135256.GC12617@yakov.inr.ac.ru>
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
> matter
> how hard network device or peer try to confuse it. :-)
You're right, that doesn't make sense...
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner @ 2005-09-02 14:10 UTC (permalink / raw)
To: lists; +Cc: David S. Miller, linux-net, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.61.0509020948350.6083@guppy.limebrokerage.com>
On Sep 2, 2005, at 10:05 AM, lists@limebrokerage.com 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 stream of
> full-size packets occassionally. It's just very unlikely they would
> occur at the start of the flow, as market data is very thin in the
> pre-market open hours.
The rcv_ssthresh growth can actually take place anywhere in the flow,
not just at the beginning.
>> But, that window clamping should fix the problem, as we recalculate
>> the window to advertise.
>
> Patches for testing are very much welcome...
Have you tried increasing the size of the receive buffer yet?
-John
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: lists @ 2005-09-02 14:05 UTC (permalink / raw)
To: David S. Miller; +Cc: jheffner, linux-net, linux-kernel, netdev
In-Reply-To: <20050901.232823.123760177.davem@davemloft.net>
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
> From: John Heffner <jheffner@psc.edu>
> 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 a connection to make a guess at how best to advertise its
>> window so as not to overflow the socket's memory bounds. Since you
>> start out with big segments then go to small ones, this is defeating
>> that mechanism. It's actually documented in the comments in
>> tcp_input.c. :)
>>
>> * The scheme does not work when sender sends good segments opening
>> * window and then starts to feed us spagetti. But it should work
>> * in common situations. Otherwise, we have to rely on queue collapsing.
>
> That's a strong possibility, good catch John.
That's possible, but see below.
> Although, I'm still not ruling out some box in the middle
> even though I consider it less likely than your theory.
There is no funky box in the middle, that much I can guarantee you.
I said yesterday that I don't have access to the sender. While that's true
for the flow I had captured in those dumps, I saw the same phenomenon
occur between two boxes I control fully. The sender is running Windows
2000, and is separated from the receiver by a single Catalyst 6500
switch/router (they are on different VLAN's) which doesn't do anything
fancy (I control the switch as well).
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 stream of full-size
packets occassionally. It's just very unlikely they would occur at the
start of the flow, as market data is very thin in the pre-market open hours.
> So you're suggesting that tcp_prune_queue() should do the:
>
> if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
> tcp_clamp_window(sk, tp);
>
> check after attempting to collapse the queue.
>
> But, that window clamping should fix the problem, as we recalculate
> the window to advertise.
Patches for testing are very much welcome...
Thanks,
-Ion
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-02 13:52 UTC (permalink / raw)
To: Guillaume Autran
Cc: John Heffner, Ion Badulescu, David S. Miller, linux-net,
linux-kernel, netdev
In-Reply-To: <43184D79.6040009@mrv.com>
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 it. :-)
Alexey
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Ion Badulescu @ 2005-09-02 13:48 UTC (permalink / raw)
To: Guillaume Autran
Cc: John Heffner, Ion Badulescu, David S. Miller, linux-net,
linux-kernel, netdev
In-Reply-To: <43184D79.6040009@mrv.com>
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 issue or is it more intermittent ?
I have no problem whatsoever reproducing it, at least with the kind of
traffic I described. I had 4 flows like that running yesterday, and all 4
had TCP window sizes smaller than 500 bytes on the receiver by mid-day.
-Ion
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-02 13:48 UTC (permalink / raw)
To: John Heffner
Cc: Ion Badulescu, David S. Miller, linux-net, linux-kernel, netdev
In-Reply-To: <2d02c76a84655d212634a91002b3eccd@psc.edu>
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 is necessary, but it must reduce window
as well.
Alexey
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Guillaume Autran @ 2005-09-02 13:02 UTC (permalink / raw)
To: John Heffner
Cc: Ion Badulescu, David S. Miller, linux-net, linux-kernel, netdev
In-Reply-To: <2d02c76a84655d212634a91002b3eccd@psc.edu>
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 regards,
Guillaume.
John Heffner wrote:
> 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 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 (there are no
>> lost packets and the tcpdump is taken on the receiver so there is no
>> packets/acks crossed in flight).
>
>
> 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 a connection to make a guess at how best to advertise its
> window so as not to overflow the socket's memory bounds. Since you
> start out with big segments then go to small ones, this is defeating
> that mechanism. It's actually documented in the comments in
> tcp_input.c. :)
>
> * The scheme does not work when sender sends good segments opening
> * window and then starts to feed us spagetti. But it should work
> * in common situations. Otherwise, we have to rely on queue collapsing.
>
> 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.) If the receiving
> application doesn't fall too far behind, it might help you to set a
> much larger receiver buffer.
>
> -John
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: David S. Miller @ 2005-09-02 6:28 UTC (permalink / raw)
To: jheffner; +Cc: lists, linux-net, linux-kernel, netdev
In-Reply-To: <2d02c76a84655d212634a91002b3eccd@psc.edu>
From: John Heffner <jheffner@psc.edu>
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 a connection to make a guess at how best to advertise its
> window so as not to overflow the socket's memory bounds. Since you
> start out with big segments then go to small ones, this is defeating
> that mechanism. It's actually documented in the comments in
> tcp_input.c. :)
>
> * The scheme does not work when sender sends good segments opening
> * window and then starts to feed us spagetti. But it should work
> * in common situations. Otherwise, we have to rely on queue collapsing.
That's a strong possibility, good catch John.
Although, I'm still not ruling out some box in the middle
even though I consider it less likely than your theory.
So you're suggesting that tcp_prune_queue() should do the:
if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
tcp_clamp_window(sk, tp);
check after attempting to collapse the queue.
But, that window clamping should fix the problem, as we recalculate
the window to advertise.
^ permalink raw reply
* Re: [PATCH 0/8] orinoco: Bringing in-sync with CVS
From: David Gibson @ 2005-09-02 5:57 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Orinoco Development List, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1125619233.24497.9.camel@dv>
On Thu, Sep 01, 2005 at 08:00:33PM -0400, Pavel Roskin wrote:
> Hello!
>
> Following 8 patches bring orinoco drivers in the kernel fully in-sync
> with the CVS repository at http://savannah.nongnu.org/projects/orinoco/
> ("for_linus" branch).
>
> The patches include 2 new front-end drivers: orinoco_nortel and
> spectrum_cs. They also remove EXPERIMENTAL designation of the PCI
> front-ends (PCI, PLX and TMD). The rest is pretty minor.
>
> I'm placing the patches to http://red-bean.com/proski/orinoco/
>
> Signed-off-by: Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>
All look good to me.
Acked-by: David Gibson <hermes-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner @ 2005-09-02 2:51 UTC (permalink / raw)
To: Ion Badulescu; +Cc: David S. Miller, linux-net, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.61.0509011845040.6083@guppy.limebrokerage.com>
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 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 (there are no lost
> packets and the tcpdump is taken on the receiver so there is no
> packets/acks crossed in flight).
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 a connection to make a guess at how best to advertise its
window so as not to overflow the socket's memory bounds. Since you
start out with big segments then go to small ones, this is defeating
that mechanism. It's actually documented in the comments in
tcp_input.c. :)
* The scheme does not work when sender sends good segments opening
* window and then starts to feed us spagetti. But it should work
* in common situations. Otherwise, we have to rely on queue collapsing.
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.) If the receiving
application doesn't fall too far behind, it might help you to set a
much larger receiver buffer.
-John
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox