lkml.org 
[lkml]   [2008]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: netatalk slow after system upgrade (possibly kernel problem?)
    Date
    (full quote below, because this message was in January)

    I did some new tests, see http://zmi.at/x/wire.delayack2.pcap
    Dump from SUSE10.3, Apple client had delayed ACK set to 2 with
    sysctl -w net.inet.tcp.delayed_ack=2, and also MacOS10.5 has this
    problem. It was suggested I could have this problem:
    http://www.helios.de/support/ti.phtml?110

    On the same hardware, I can start the old SUSE10.0 at the same time in
    parallel with the new SUSE10.3, both are virtual machines in VMware,
    and the old machine is always fast and the new one always slow. From
    the dump I would say it's the fault of MacOS - sometimes a very long
    delay before an ACK. But then again, it's fast when copying to the old
    SUSE linux box. Very strange.

    On Sonntag, 27. Januar 2008 Andrew Morton wrote:
    > (cc netdev)
    >
    > > On Fri, 25 Jan 2008 12:55:42 +0100 Michael Monnerie
    > > <michael.monnerie@it-management.at> wrote: Dear lists,
    > >
    > > I've been spending a LOT of time trying to find out where's the
    > > problem, but can't find it and therefore seek urgent help now. We
    > > have the following system:
    > >
    > > Server with VMware server
    > > -> VM running a webserver and netatalk
    > > -> 2 other VMs not related
    > >
    > > The VM with netatalk was SUSE 10.0 with kernel 2.6.13-15.15-smp
    > > (from SUSE), and things were pretty fun and quick. Then we upgraded
    > > to SUSE 10.2 and now 10.3, where everything EXCEPT netatalk runs
    > > perfect. Since this upgrade, Apple clients (MacOS X) now do READ
    > > very very slowly (about 512KB/s over the gigabit LAN), while
    > > writing to the server still is normal (>20MB/s). I've even retried
    > > with the newest kernel 2.6.23.13, tried different
    > > /proc/sys/net/ipv4/tcp_congestion_control (cubic, reno, bic, etc.)
    > > and nothing helps. I've then tried to install Samba and found that
    > > we have similar problems reading with it from MacOS clients. Now
    > > I'm pretty sure it should be something with the linux kernel, but I
    > > don't understand what.
    > >
    > > Here are the wireshark dumps in pcap format:
    > > http://zmi.at/x/atalk-write-fast.pcap
    > > -> you can see writing to the server (192.168.120.9) is normal and
    > > fast
    > >
    > > http://zmi.at/x/atalk-read-slow.pcap
    > > -> reading is horribly slow. Lots of "unknown", because of netatalk
    > > or what?
    > >
    > > http://zmi.at/x/unknown-atalk.pcap
    > > -> another dump while reading, you see "unknown" reads. I'm not
    > > sure if it's just wireshark not understanding the packets or
    > > netatalk.
    > >
    > > And trying with samba:
    > > http://zmi.at/x/smb-read-slow.pcap
    > > http://zmi.at/x/smb-write-quick.pcap
    > > you can see that it's also slow.
    > >
    > > Now why did it work with the old 2.6.13 kernel? I still have that
    > > old VM, and when I start it, it is always perfectly fast. Only
    > > newer versions are slow. Can somebody give me a hint please?
    >
    > It would be interesting if this could be repeated on bare hardware,
    > so we can eliminate the possibility that it is some weird interaction
    > with vmware.



    --
    // 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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2008-03-12 03:29    [W:2.975 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site