linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Helge Hafting <helgehaf@aitel.hist.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.0 NFS-server low to 0 performance
Date: Sun, 11 Jan 2004 13:53:09 +0000	[thread overview]
Message-ID: <20040111135309.F1931@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20040111131857.GA11246@hh.idb.hist.no>; from helgehaf@aitel.hist.no on Sun, Jan 11, 2004 at 02:18:57PM +0100

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

  reply	other threads:[~2004-01-11 13:53 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-06  0:46 2.6.0 NFS-server low to 0 performance Guennadi Liakhovetski
2004-01-07 13:36 ` Guennadi Liakhovetski
2004-01-07 22:30   ` bill davidsen
2004-01-08 12:48     ` Guennadi Liakhovetski
2004-01-07 17:49 ` Mike Fedyk
2004-01-07 18:13   ` Guennadi Liakhovetski
2004-01-07 18:19     ` Mike Fedyk
2004-01-07 19:06       ` Guennadi Liakhovetski
2004-01-09 10:08         ` Guennadi Liakhovetski
2004-01-09 18:00           ` Mike Fedyk
2004-01-10  0:38             ` Guennadi Liakhovetski
2004-01-10  1:38               ` Mike Fedyk
2004-01-10 11:10                 ` Guennadi Liakhovetski
2004-01-10 14:30                   ` Trond Myklebust
2004-01-10 20:04                     ` Guennadi Liakhovetski
2004-01-10 21:57                       ` Trond Myklebust
2004-01-10 22:14                         ` Mike Fedyk
2004-01-10 22:47                           ` Trond Myklebust
2004-01-10 22:42                         ` Guennadi Liakhovetski
2004-01-10 22:51                           ` Jesper Juhl
2004-01-11 13:18                           ` Helge Hafting
2004-01-11 13:53                             ` Russell King [this message]
2004-01-11 14:24                               ` Guennadi Liakhovetski
2004-01-15 11:38                               ` Pavel Machek
2004-01-12  5:06                     ` Bill Davidsen
2004-01-12 14:27                       ` Trond Myklebust
2004-01-12 15:12                         ` Trond Myklebust
2004-01-16  5:44                           ` Mike Fedyk
2004-01-16  6:05                             ` Trond Myklebust
2004-01-16  6:53                               ` Mike Fedyk
2004-01-10 22:34                   ` Mike Fedyk
2004-01-10 22:52                     ` Guennadi Liakhovetski
2004-01-10 22:57                       ` Mike Fedyk
2004-01-10 23:00                         ` Guennadi Liakhovetski
2004-01-08 21:42     ` Pavel Machek
2004-01-12 23:18       ` Guennadi Liakhovetski
2004-01-12 23:28         ` Jesper Juhl
2004-01-13  0:39         ` Pavel Machek
2004-01-14  3:00           ` Daniel Roesen
2004-01-14 18:16           ` Guennadi Liakhovetski
2004-01-13  1:55 ` Slow NFS performance over wireless! Roman Gaufman
2004-01-13  2:15   ` Trond Myklebust
2004-01-13 20:25   ` Joshua M. Thompson
2004-01-13 20:45     ` Trond Myklebust
2004-01-15  1:12       ` Miquel van Smoorenburg
     [not found]         ` <20040115013312.GO1594@srv-lnx2600.matchmail.com>
2004-01-15  2:04           ` Miquel van Smoorenburg
2004-01-15  2:35         ` Trond Myklebust
2004-01-15 19:00           ` Slowwwwwwwwwwww NFS read performance Trond Myklebust
2004-01-15 19:53             ` Ram Pai
2004-01-15 20:16               ` Trond Myklebust
2004-01-15 20:54                 ` Trond Myklebust
2004-01-18  6:04             ` Greg Fitzgerald
2004-01-18 17:55               ` Mike Fedyk
2004-01-16  0:52           ` Slow NFS performance [was: over wireless!] Miquel van Smoorenburg
     [not found] <1cpDr-5az-11@gated-at.bofh.it>
     [not found] ` <1csrv-Er-9@gated-at.bofh.it>
2004-01-10 16:08   ` 2.6.0 NFS-server low to 0 performance Andi Kleen
2004-01-10 16:19     ` Trond Myklebust
2004-01-12 14:40 James Pearson
2004-01-12 15:22 ` Trond Myklebust
2004-01-13 11:08   ` Muli Ben-Yehuda

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=20040111135309.F1931@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=g.liakhovetski@gmx.de \
    --cc=helgehaf@aitel.hist.no \
    --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;
as well as URLs for NNTP newsgroup(s).