lkml.org 
[lkml]   [2004]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.0 NFS-server low to 0 performance
    On Sun, Jan 11, 2004 at 02:18:57PM +0100, Helge Hafting wrote:
    > On Sat, Jan 10, 2004 at 11:42:45PM +0100, Guennadi Liakhovetski wrote:
    > > The only my doubt was - yes, you upgrade the __server__, so, you look in
    > > Changes, upgrade all necessary stuff, or just upgrade blindly (as does
    > > happen sometimes, I believe) a distribution - and the server works, fine.
    > > What I find non-obvious, is that on updating the server you have to
    > > re-configure __clients__, see? Just think about a network somewhere in a
    >
    > If you upgrade the server and read "Changes", then a note in changes might
    > say that "you need to configure carefully or some clients could get in trouble."
    > (If the current "Changes" don't have that - post a documentation patch.)

    [This is more to Guennadi than Helge]

    I don't see why such a patch to "Changes" should be necessary. The
    problem is most definitely with the client hardware, and not the
    server software.

    The crux of this problem comes down to the SMC91C111 having only a
    small on-board packet buffer, which is capable of storing only about
    4 packets (both TX and RX). This means that if you receive 8 packets
    with high enough interrupt latency, you _will_ drop some of those
    packets.

    Note that this is independent of whether you're using DMA mode with
    the SMC91C111 - DMA mode only allows you to off load the packets from
    the chip faster once you've discovered you have a packet to off load
    via an interrupt.

    It won't be just NFS that's affected - eg, if you have 4kB NFS packets
    and several machines broadcast an ARP at the same time, you'll again
    run out of packet space on the SMC91C111. Does that mean you should
    somehow change the way ARP works?

    Sure, reducing the NFS packet size relieves the problem, but that's
    just a work around for the symptom and nothing more. It's exactly
    the same type of work around as switching the SMC91C111 to operate at
    10mbps only - both work by reducing the rate at which packets are
    received by the target, thereby offsetting the interrupt latency
    and packet unload times.

    Basically, the SMC91C111 is great for use on small, *well controlled*
    embedded networks, but anything else is asking for trouble.

    --
    Russell King
    Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
    maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
    2.6 Serial core
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:00    [W:0.027 / U:30.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site