[<prev] [next>] [day] [month] [year] [list]
Message-Id: <200802070149.45873@zmi.at>
Date: Thu, 7 Feb 2008 01:49:44 +0100
From: Michael Monnerie <michael.monnerie@...management.at>
To: Ralph Böhme <lists@...ported.de>
Cc: netatalk-admins@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Netatalk-admins] netatalk slow after system upgrade (possibly kernel problem?)
I received this e-mail, which could be the resolution to this problem. I
will test it with the customer tomorrow.
Is there a workaround possible from the Linux server, instead of
modifying all clients? As it runs with kernel 2.6.13, but not with
2.6.23, maybe some behaviour change via sysctl could help here.
On Mittwoch, 6. Februar 2008 Ralph Böhme wrote:
> Am 05.02.2008 um 16:26 schrieb Michael Monnerie:
> > Still, it runs quick within the VM
> > with kernel 2.6.13-15.15-smp from SUSE 10.0, but slow with more
> > recent kernels (I couldn't test every combination of course).
>
> Use the sniffer, Luke!
>
> If you find an ongoing sequence of ~5 packets sent by the server,
> ~200ms pause, client ACK, next turn, then you might me experiencing
> this:
>
> http://www.helios.de/support/ti.phtml?110
>
> Proposed solution:
> sysctl -w net.inet.tcp.delayed_ack=2 to be set on the client side.
> Note: the issue should be resolved with OS X 10.5.
>
> It seems as if /some/ server side TCP stacks don't like OS X 10.4
> delayed ACKs implementation.
>
> HTH,
> -Ralph
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0676/846 914 666 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: www.keyserver.net Key-ID: 1C1209B4
Download attachment "signature.asc " of type "application/pgp-signature" (195 bytes)
Powered by blists - more mailing lists