netdev - Re: TCP slowdown in 2.6.25?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0804281826260.1888@wrl-59.cs.helsinki.fi>
Date:	Mon, 28 Apr 2008 18:48:12 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP slowdown in 2.6.25?

On Mon, 28 Apr 2008, Joakim Tjernlund wrote:

> On Mon, 2008-04-28 at 17:42 +0300, Ilpo Järvinen wrote:
> > On Mon, 28 Apr 2008, Joakim Tjernlund wrote:
> > > On Mon, 2008-04-28 at 14:12 +0200, Joakim Tjernlund wrote:
> > > > After upgrading from 2.6.23 to 2.6.25 I am seeing a big slow down on
> > > > our old www server. Stracing shows lots of EAGAIN but i not sure
> > > > these are relevant. I got no idea where to start looking so
> > > > I would appreciate some pointers. Perhaps this is a know issue?
> > > > 
> > > > CPU is a PowerPC, mpc8321, network driver ucc_geth
> > > 
> > > Some info:
> > > Even ftp transfers takes forever, but only in one direction: from the
> > > node with kernel 2.6.25 to some other host. Strace show me that
> > > write(2) hangs for long periods before succeeding to transmit 
> > > the data.

> > To some specific or "any" other host? How long is "long"?
> 
> Any host. A 1304632 bytes file takes about 110 seconds to transfer
> (12 Kbytes/sec)
>
> A quick capture with wireshark indicates that some sent packages from
> the node never reaches the host on the network.

Thanks, this is the important bit of info, TCP flow control limit seems 
just a consequence of that... ...Now we'll just have to figure out what is 
causing those losses.

Is there some middlebox on the route to that host?

-- 
 i.