From: "David S. Miller" <davem@redhat.com>
To: ak@suse.de
Cc: jordy@napster.com, linux-kernel@vger.kernel.org, kuznet@ms2.inr.ac.ru
Subject: Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Tue, 7 Nov 2000 01:57:46 -0800 [thread overview]
Message-ID: <200011070957.BAA03164@pizda.ninka.net> (raw)
In-Reply-To: <20001107104136.A5081@gruyere.muc.suse.de> (message from Andi Kleen on Tue, 7 Nov 2000 10:41:36 +0100)
In-Reply-To: <3A079127.47B2B14C@napster.com> <200011070533.VAA02179@pizda.ninka.net> <3A079D83.2B46A8FD@napster.com> <200011070603.WAA02292@pizda.ninka.net> <3A07A4B0.A7E9D62@napster.com> <200011070656.WAA02435@pizda.ninka.net> <3A07AC45.DCC961FF@napster.com> <200011070712.XAA02511@pizda.ninka.net> <3A07B01A.1E70EE20@napster.com> <200011070727.XAA02574@pizda.ninka.net> <20001107104136.A5081@gruyere.muc.suse.de>
Date: Tue, 7 Nov 2000 10:41:36 +0100
From: Andi Kleen <ak@suse.de>
I think such a theory would at least need verifying (e.g. by a
sniffer on the windows end that checks checksums or someone finding
the checksum failed counters windows probably maintains)
Sure.
BTW, note the pattern of the win98 logs, basically the whole
connection from the WIN98 side is:
repeat:
LINUX data(N) --> win98 DIFFERENT sequence number
LINUX data(N+1) --> win98 DIFFERENT sequence number
retimeout
LINUX data(N) --> win98 SAME sequence number
win98 ACK N --> LINUX
N++; goto repeat
And in all cases except the first data segment sent by Linux, the
sequence numbers are corrupted such that the original 536 byte payload
is reduced to a 534 byte payload.
Now one could argue it might be a bandwidth limiter, because the
first change in sequence numbers is:
22:34:36.069773 64.124.41.179.8888 > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF)
22:34:36.069837 64.124.41.179.8888 > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF)
They're changed, but lined up. However later we get stuff like:
22:34:39.245138 64.124.41.179.8888 > 209.179.194.175.1084: P 21:555(534) ack 44 win 5840 (DF)
22:34:39.245208 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1091(534) ack 56 win 5840 (DF)
Which don't even line up at all. Furthermore, if the checksums were
correct win98 should have ACK'd fully the <1:19> data packet and the
<19:553> one. Also for the non-contiguous cases win98 should have
sent an immediate ACK (and a SACK block indicating the non-contiguous
data received).
Now, I could see some buggy bandwidth limiter chopping up the sequence
numbers such that they aren't lined up occaisionally, but corrupting
all the TCP checksums as well? I find that hard to believe.
Well, if it is what's happening, I wouldn't expect such a company to
be making such products for long :-)
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-07 10:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-07 6:13 Jordan Mendelson
2000-11-07 2:17 ` Jordan Mendelson
2000-11-07 4:28 ` David S. Miller
2000-11-07 5:20 ` Jordan Mendelson
2000-11-07 5:33 ` David S. Miller
2000-11-07 6:03 ` David S. Miller
2000-11-07 6:44 ` Jordan Mendelson
2000-11-07 6:56 ` David S. Miller
2000-11-07 7:12 ` David S. Miller
2000-11-07 7:27 ` David S. Miller
2000-11-07 9:41 ` Andi Kleen
2000-11-07 9:57 ` David S. Miller [this message]
2000-11-07 7:32 ` Jordan Mendelson
2000-11-07 12:22 ` Alan Cox
2000-11-07 12:10 ` David S. Miller
2000-11-07 7:16 ` Jordan Mendelson
2000-11-07 9:42 ` Andi Kleen
2000-11-07 18:13 ` Jordan Mendelson
2000-11-07 9:38 ` Rogier Wolff
2000-11-07 9:58 ` David S. Miller
2000-11-07 10:36 ` Rogier Wolff
2000-11-07 6:59 ` David S. Miller
2000-11-07 7:14 ` David S. Miller
2000-11-07 7:16 ` Andi Kleen
2000-11-07 7:03 ` Andi Kleen
2000-11-07 22:43 ` Lincoln Dale
2000-11-07 9:35 ` Rogier Wolff
2000-11-07 10:00 ` David S. Miller
[not found] <3A076701.F437F88B@napster.com>
2000-11-07 3:44 ` Jordan Mendelson
2000-11-07 4:29 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200011070957.BAA03164@pizda.ninka.net \
--to=davem@redhat.com \
--cc=ak@suse.de \
--cc=jordy@napster.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®