public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-kernel@vger.kernel.org
Subject: Re: Data sitting and remaining in Send-Q
Date: Mon, 24 Dec 2001 22:56:48 +0100	[thread overview]
Message-ID: <20011224225648.I2461@lug-owl.de> (raw)
In-Reply-To: <20011224211726.H2461@lug-owl.de> <1062462662.1009226676@[195.224.237.69]>
In-Reply-To: <1062462662.1009226676@[195.224.237.69]>

On Mon, 2001-12-24 20:44:37 -0000, Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>
wrote in message <1062462662.1009226676@[195.224.237.69]>:
> >That would give a different result: "functional TCP connections" or
> >"non-functional TCP connections". Mine are between that. If data gets
> >sent in small chunks, everything is fine, but if it's a larger
> >transfer (more than one ethernet frame may transport???), write()
> >stalls (or non-blocking write returns), but data is kept in
> >Send-Q rather than being sent down to the client.

Well, some testing done. I've written a small microserver bound to
port 1111/tcp via inetd:
--------------------------------------
#!/bin/sh

LEN="`cat /root/size`"

dd bs=$LEN if=/dev/zero count=1 2>/dev/null
sleep 1
exit 0
------------------------------------

I can control it's output by a file. It seems that I can always
transmit up to ~920 bytes at a time, but never more than 940.
All values in between these borders are more-or-less functional,
depending their size (smaller packets == high chance to reach client,
larger packets == small chance to reach destination).

> Just to check the completely obvious:
> 
> Difficult / impossible to tell without a tcpdump, but last time I
> saw something like this, one end was silently dropping packets
> exactly equal to the MTU size (or up to 3 bytes smaller), but
> transmitting all other packets (in this instance it was a bizarre
> 802.11 problem).

It's quite a problem to do tcpdumping on a host from which you
never can get more than ~920 bytes at a time, neither by ftp, nor
by ssh or telnet or whatever:-)

Well, I've tcpdumped now, and it seemy my old WaveSwitch is
to blame. The "bad" server actually transmits everything
(and also tries retransmits etc.), but that never leaves the
switch again... I've changed the switch port as well as the
cable. It seems the switch and that network card don't
like each other...

I've now replaced the network card, everything is fine now.

I've never seen a NIC failing partially, I've learned a lot
this evening...

Thank you very much (to all who send me notes) and have a nice
X-Mas...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

  parent reply	other threads:[~2001-12-24 21:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-24 17:01 Data sitting and remaining in Send-Q Jan-Benedict Glaw
2001-12-24 18:10 ` José Luis Domingo López
2001-12-24 19:00   ` Jan-Benedict Glaw
2001-12-24 19:38   ` Jan-Benedict Glaw
2001-12-24 20:09     ` Mr. James W. Laferriere
2001-12-24 20:17       ` Jan-Benedict Glaw
2001-12-24 20:44         ` Alex Bligh - linux-kernel
2001-12-24 21:34           ` Thorsten Kranzkowski
2001-12-24 21:58             ` Jan-Benedict Glaw
2001-12-24 21:56           ` Jan-Benedict Glaw [this message]
2001-12-25  0:43             ` Alex Bligh - linux-kernel

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=20011224225648.I2461@lug-owl.de \
    --to=jbglaw@lug-owl.de \
    --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