| To: | Jordan Mendelson <jordy@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: 2.4 tcp very slow under certain circumstances (Re: netdev issues (3c905B)) |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Wed, 21 Feb 2001 15:52:37 -0800 (PST) |
| Cc: | ookhoi@xxxxxx, Vibol Hou <vibol@xxxxxxxx>, Linux-Kernel <linux-kernel@xxxxxxxxxxxxxxx>, sim@xxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <3A9453F4.993A9A74@xxxxxxxxxxx> |
| References: | <HDEBKHLDKIDOBMHPKDDKMEGDEFAA.vibol@xxxxxxxx> <20010221104723.C1714@humilis> <14995.40701.818777.181432@xxxxxxxxxxxxxxx> <3A9453F4.993A9A74@xxxxxxxxxxx> |
| Sender: | owner-netdev@xxxxxxxxxxx |
Jordan Mendelson writes: > Now, if it didn't have the side effect of dropping packets left and > right after ~4000 open connections (simultaneously), I could finally > move our production system to 2.4.x. There is no reason my patch should have this effect. All of this is what appears to be a bug in Windows TCP header compression, if the ID field of the IPv4 header does not change then it drops every other packet. The change I posted as-is, is unacceptable because it adds unnecessary cost to a fast path. The final change I actually use will likely involve using the TCP sequence numbers to calculate an "always changing" ID number in the IPv4 headers to placate these broken windows machines. Later, David S. Miller davem@xxxxxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 2.4 tcp very slow under certain circumstances (Re: netdev issues (3c905B)), Jordan Mendelson |
|---|---|
| Next by Date: | Re: 2.4 tcp very slow under certain circumstances (Re: netdev issues (3c905B)), Jordan Mendelson |
| Previous by Thread: | Re: 2.4 tcp very slow under certain circumstances (Re: netdev issues (3c905B)), Jordan Mendelson |
| Next by Thread: | Re: 2.4 tcp very slow under certain circumstances (Re: netdev issues (3c905B)), Jordan Mendelson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |